Helmholtz EOS

[Yurlungur]

PR Summary

Preliminary work on implementing a Helmholtz EOS in singularity-eos

PR Checklist

• Adds a test for any bugs fixed. Adds tests for new features.
• Format your changes by using the make format command after configuring with cmake.
• Document any new features, update documentation for changes made.
• Make sure the copyright notice on any files you modified is up to date.
• After creating a pull request, note it in the CHANGELOG.md file
• If preparing for a new release, update the version in cmake.

[jhp-lanl]

I'm sure with a paper and some time I could decipher much of this, but as it stands I'm a bit concerned by all the short variable names flying around without context. Is there any way the variable names can be more descriptive?

[Yurlungur]

I'm sure with a paper and some time I could decipher much of this, but as it stands I'm a bit concerned by all the short variable names flying around without context. Is there any way the variable names can be more descriptive?

👍 I blindly copied this out of the reference implementation---I will add some documentation in sphinx as well as some comments pointing to the reference implementation an the paper. Would that be sufficient to clarify?

[jhp-lanl]

I'm sure with a paper and some time I could decipher much of this, but as it stands I'm a bit concerned by all the short variable names flying around without context. Is there any way the variable names can be more descriptive?

👍 I blindly copied this out of the reference implementation---I will add some documentation in sphinx as well as some comments pointing to the reference implementation an the paper. Would that be sufficient to clarify?

I think that will be helpful, but I just don't feel that reading the paper should be needed for the code review. Some basic comments to explain the general structure of the code and explanations for what blocks of variables are doing (or more descriptive variable names) will probably aid the review process.

[Yurlungur]

I think that will be helpful, but I just don't feel that reading the paper should be needed for the code review. Some basic comments to explain the general structure of the code and explanations for what blocks of variables are doing (or more descriptive variable names) will probably aid the review process.

I can do that. The variable names are, for the most part, meaningfully self consistent. I think some comments explaining the convention will clarify.

[AlexHls]

I added a Fortran interface, but I could not test it. Compiling (more precisely linking) my test program lead to quite a few error messages. I'm not sure if is because I forgot something in the interface or due to the issue described in #284 (given that the error message mentions several EOS is suspect the latter). I would need someone else to have a look at the interface to be sure.

[AlexHls]

(This part is for archival purposes, i.e. that there is a reference somewhere that we thoroughly tested the implementation against a reference implementation)

Testing

Table interpolation

• Tested a 100x100 grid of (rho, T) values covering the table range, avoiding the edges.
• Compared all relevant quantities that singularity-eos computes against a reference implementation (Fig 1).
• The tests here do not consider Coulomb corrections as the cutoff is handled differently in the reference implementation (i.e. it just cuts the corrections off at a certain point, whereas we implement a butterworth filter to achieve a smooth transition)
• A Figure is included to illustrate the effects of Coulomb corrections (Fig. 2). One can see that once the parameter space approaches the cut-off region, the difference between the implementations becomes substantial.

Figure 1

Figure 2

Root finding

The root finding is checked rather through a self-consistency check than a comparison against a reference implementation. We did compare it against the reference implementation, however, due to the different root finding algorithms and slightly different bounding mechanisms this comparison is rather difficult to interpret.

Here we test self-consistency by going 'full circle', i.e. we calculate the internal energy through the table interpolation
$$e_{int} = eos(\rho, T)$$ which is used as input for the root find: $$T_{new} = eos(\rho, e_{int})$$.
This new temperature should be identical with the input temperature; all other quantities will be computed from this quantity. As long as $T_{new}$ is correct the other quantities will be computed correctly as long as the table interpolation itself works correctly.

Fig 3. shows the difference between the original value and the value obtained from the root find without an initial guess for the temperature. It can be seen that the root find struggles in the low temperature - low density region. But once a sensible initial guess is provided (which it realistically will be in a production scenario) the root find works much better (see Fig 4).

(Both Figures also show $e_{int,new} = eos(\rho, T_{new})$ vs $e_{int}$ to illustrate that once the correct temperature is obtained, other quantities will be computed correctly.)

Figure 3.

Figure 4.

[Yurlungur]

The fortran + C++ backend looks correct. It's also not necessarily needed for the astrophysical EOS's unless desired.

@dholladay00 does this look right to you?

[Yurlungur]

I'm not sure why either test would work---you weren't testing on device, because you had normal for loops for the test code, not portableFor loops. I've fixed it, and tests now run on device.

[Yurlungur]

From my perspective, this is ready to go. @mauneyc-LANL are you happy with the current cmake?

[jhp-lanl]

I requested changes but I'll just approve for now since I don't want to hold anything up if I'm not around

[mauneyc-LANL]

Only one issue to address, everything else looks ok.

Misread the code, changes not needed

[Yurlungur]

Triggered tests on re-git. Merging after they pass.