[newchem-cpp] transcribe calc_grain_size_increment_species_1d

[ChristopherBignamini]

This PR requires some additional work to fix a numerical issue which occurs in a call with j=k=0 and first iteration of i-loop (j=k=1 in Fortran), when coef3 is equal to zero. I temporarily added a line to skip the cubic equation solution in this case and we need to find a final fix.

[ChristopherBignamini]

pre-commit.ci autofix

[brittonsmith]

@ChristopherBignamini, I'm not able to push to your branch to update this PR. Can you merge in the latest changes to newchem-cpp and update this? While you are at it, can you do the same for PR #519 and #520?

[ChristopherBignamini]

@brittonsmith sure, done! The failure with Pygrackle test suite is due to the missing gold-standard-nccv8 tag

[brittonsmith]

@brittonsmith sure, done! The failure with Pygrackle test suite is due to the missing gold-standard-nccv8 tag

Oops, thought I pushed that. I've done it now and restarted the tests.

[brittonsmith]

@ChristopherBignamini, @mabruzzo I've take a closer look at the failed tests and the differences are significant for most of the ionic and molecular species, but even the dust temperature is different from the first iteration. I think we'll need a closer look here.

[ChristopherBignamini]

@brittonsmith @mabruzzo it could be my fault, there is a TODO in calc_grain_size_increment_species_1d concerning a manual assignment of the first element of drsp for a specific entry of input the indexes: I added that assignment when I was comparing the numerical values of the various steps with the Fortran version and I found a discrepancy due to that first element, most likely because of the different handling of NaN between C++ and Fortran. By manually setting to zero that element in both the C++ and Fortran versions of the subroutine the numerical results were identical. I tried now to remove that assignment and re-run the pygrackle suite: it still fails but I'm not sure the errors are now acceptable. My apologies.

[brittonsmith]

@ChristopherBignamini, ok the agreement is much better now, on the level of what I see for PRs #519 and #520. I think this would be acceptable for merging.

[mabruzzo]

I started to look this over. I hope to circle back and finish up later today, but I wanted to post what I had so far.

I feel pretty strongly that we should rename alsp_data to kappa_data. You can totally feel free to punt on renaming all of the other variables (maybe open an issue to record some of those renaming ideas?)