Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Bug in PTE Solver and Several Code Quality Improvements #383

Merged
merged 72 commits into from
Jul 23, 2024

Conversation

jhp-lanl
Copy link
Collaborator

@jhp-lanl jhp-lanl commented Jun 27, 2024

PR Summary

This PR is dependent on #382

This PR makes a few main changes:

  • The previous ScaleDx algorithm was written assuming that only one guard (small volume fraction, small temperature, minimum density, etc.) would activate at once. I believe I'm running into a test case where multiple guards are activating so they end up overwriting each other.
    Actually, since the newly-shrunk scale is used in each successive if block, they have the effect of only decreasing scale. I'll add a comment to this effect.
  • Materials that didn't participate in the PTE solver had their energies set to zero with the volumes untouched. This PR changes this so that non-participating materials are assumed to be at the cell density, which determines their densities and energies. This also slightly changes the volume available for the PTE materials, reflected in a different volume fraction sum.
  • I also added some comments to the line search algorithm and simplified the logic slightly by removing what appeared to be a superfluous else block.
  • Fixed two bugs in the the rho-T PTE solver ScaleDx function. First, there were missing parentheses. Second, the logic was incorrect when the volume fraction of a material has already exceeded the imposed maximum. This maximum occurs at the minimum pressure on the EOS, effectively guarding against the EOS entering unphysical (thermodynamically unstable) states. However, it's possible for this maximum to change as the temperature guess changes such that an old volume fraction is above this maximum. In that case, the logic of the function was increasing the step to get back into the physical regime, but possibly at the cost of violating other checks.
  • Adds a test for a difficult PTE state. It was failing to converge but now succeeds.
  • Improves descriptiveness of assert statements to identify the function they are in. This isn't strictly necessary since the line number is given, but it makes debugging a bit faster.
  • The TestUpdate() function has been changed so that it's a bit more clear when it's also updating the state versus when it's supposed to cache the previous state.

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.
  • LANL employees: make sure tests pass both on the github CI and on the Darwin CI

If preparing for a new release, in addition please check the following:

  • N/A Update the version in cmake.
  • N/A Move the changes in the CHANGELOG.md file under a new header for the new release, and reset the categories.

@jhp-lanl jhp-lanl marked this pull request as draft June 27, 2024 19:13
@jhp-lanl
Copy link
Collaborator Author

jhp-lanl commented Jul 2, 2024

I'm still getting negative volume fractions despite the fact that I believe the code should be catching this. I'll add a unit test here shortly that should demonstrate this and then work on whatever fix is needed to prevent this.

@jhp-lanl
Copy link
Collaborator Author

I think I got all the bugs worked out with running the test on device.

The test should be a good platform to add tests that used to break the PTE solver (or still do while we're figuring out a solution). And it can be a bit of a template for using the new ports-of-call features for allocating on device without having to mess with lots of Kokkos views and #IFDEF statements.

test/CMakeLists.txt Outdated Show resolved Hide resolved
…CMakeLists and other '*_USE_*' or '*_BUILD_*' variables are in the main project
@dholladay00
Copy link
Collaborator

great work @jhp-lanl! This not only fixes a long-standing bug in the solver, but it uses the latest best practices for portability and adds improvements to the configure/build system. In addition, this provides a tool to explore problematic PTE inputs separate from the context of a host code!

Assuming this passes CI and pending review by those that understand the physics better than I, this is ready! 👍

@jhp-lanl
Copy link
Collaborator Author

Assuming this passes CI and pending review by those that understand the physics better than I, this is ready! 👍

I think I'm still having some issues with the CI on gitlab unfortunately. I thought I had fixed these issues on my build when executing on device, but I'll keep working to reproduce

Copy link
Collaborator

@Yurlungur Yurlungur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this, @jhp-lanl having unit tests here is a big improvement. As is the nasty bugs you caught. I still want @pdmullen and @jdolence 's eyes on this. But I'm happy with this. I also ran this branch through riot and ran some strenuous test problems, which still look good.

singularity-eos/closure/mixed_cell_models.hpp Show resolved Hide resolved
Asum *= uscale / Tnorm;
rhoBsum /= Tnorm;
PORTABLE_REQUIRE(rhoBsum > 0., "Non-positive energy density");
PORTABLE_REQUIRE(rhoBsum > 0., "Non-positive Ideal PTE energy density guess");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this only for ideal gas? Because non-ideal gas EOS's can have non-positive energies and it's totally expected/fine.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The next line is

Tideal = uscale / rhoBsum / Tnorm;

This would imply a negative temperature guess, so no, this code cannot admit a negative energy density. I think this is probably part of why it's not useful outside of gas mixtures.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah ok. I just want to make sure this is only used for ideal gas, as tabulated EOSs definitely support negative energy.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep! I think this is a good reason not to use this guess for tabular EOS. You could also imagine a reacting system where the reaction products is represented by a shifted ideal gas with a negative energy. I think this guess isn't really used, but I figured it might be good to put guardrails on it.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function is called in the Init for PTESolverRhoU which I believe is supposed to handle non-ideal EOS.

Notice that TryIdealPTE is commented out from PTESolverRhoT with the following comment:

    // Leave this in for now, but comment out because I'm not sure it's a good idea
    // TryIdealPTE(this);
    // Set the current guess for the equilibrium temperature.  Note that this is already
    // scaled.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I unresolved this conversation because I was concerned that PTESolverRhoU now no longer works for non-ideal EOS wherein u can be less than 0. Any thoughts here?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest that we floor the energy/temperature inside the solver, as it's only used for guesses

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I unresolved this conversation because I was concerned that PTESolverRhoU now no longer works for non-ideal EOS wherein u can be less than 0. Any thoughts here?

If PTESolverRhoU relies on a negative temperature guess, I'd argue that it never worked for non-ideal EOS that can have negative energies and that the guess infrastructure should be re-worked for that solver.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I misread the above. I forgot that TryIdealPTE() is separate from GetIdealPTE(). So these error checks being located in GetIdealPTE() is a mistake since TryIdealPTE() will check the results of GetIdealPTE() and see if the results are sane.

Even though these changes are highlighted just because I changed the message and not because they were added here, I'll move them to the TryIdealPTE() function.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I ended up getting rid of all the GetIdealPTE asserts and instead I added a check in TryIdealPTE() to make sure the temperature guess is actually positive.

singularity-eos/closure/mixed_cell_models.hpp Show resolved Hide resolved
@dholladay00
Copy link
Collaborator

Thanks for this, @jhp-lanl having unit tests here is a big improvement. As is the nasty bugs you caught. I still want @pdmullen and @jdolence 's eyes on this. But I'm happy with this. I also ran this branch through riot and ran some strenuous test problems, which still look good.

@Yurlungur: Jeff (@jhp-lanl) and I discussed the timeline for this PR. Given the timeline for a release into EAP, we are planning on merging this no later than EOD Monday and beginning the release process immediately following. This gives some, but not much time for review but we really can't wait any longer than that. If fixes are needed beyond what is caught on Monday, they will need to go in after the release.

@Yurlungur
Copy link
Collaborator

Thanks for this, @jhp-lanl having unit tests here is a big improvement. As is the nasty bugs you caught. I still want @pdmullen and @jdolence 's eyes on this. But I'm happy with this. I also ran this branch through riot and ran some strenuous test problems, which still look good.

@Yurlungur: Jeff (@jhp-lanl) and I discussed the timeline for this PR. Given the timeline for a release into EAP, we are planning on merging this no later than EOD Monday and beginning the release process immediately following. This gives some, but not much time for review but we really can't wait any longer than that. If fixes are needed beyond what is caught on Monday, they will need to go in after the release.

Yes understood. I believe @pdmullen at least plans to review Monday. We shouldn't wait for @jdolence .

@dholladay00
Copy link
Collaborator

Thanks for this, @jhp-lanl having unit tests here is a big improvement. As is the nasty bugs you caught. I still want @pdmullen and @jdolence 's eyes on this. But I'm happy with this. I also ran this branch through riot and ran some strenuous test problems, which still look good.

@Yurlungur: Jeff (@jhp-lanl) and I discussed the timeline for this PR. Given the timeline for a release into EAP, we are planning on merging this no later than EOD Monday and beginning the release process immediately following. This gives some, but not much time for review but we really can't wait any longer than that. If fixes are needed beyond what is caught on Monday, they will need to go in after the release.

Yes understood. I believe @pdmullen at least plans to review Monday. We shouldn't wait for @jdolence .

@Yurlungur I'd really like @jdolence's eyes on it as some point for a sanity check if at all possible, even if it's after the merge. Sometimes the original author has knowledge that is hard to obtain by reading alone.

@jhp-lanl
Copy link
Collaborator Author

Thanks for this, @jhp-lanl having unit tests here is a big improvement. As is the nasty bugs you caught. I still want @pdmullen and @jdolence 's eyes on this. But I'm happy with this. I also ran this branch through riot and ran some strenuous test problems, which still look good.

@Yurlungur: Jeff (@jhp-lanl) and I discussed the timeline for this PR. Given the timeline for a release into EAP, we are planning on merging this no later than EOD Monday and beginning the release process immediately following. This gives some, but not much time for review but we really can't wait any longer than that. If fixes are needed beyond what is caught on Monday, they will need to go in after the release.

That said, I still need to fix the CI. I'll work on that this afternoon.

@Yurlungur
Copy link
Collaborator

@Yurlungur I'd really like @jdolence's eyes on it as some point for a sanity check if at all possible, even if it's after the merge. Sometimes the original author has knowledge that is hard to obtain by reading alone.

I agree. My concern is I don't know when I will be able to get him to look. We were visiting him in Ann Arbor this week and I asked him to look, though. So there's hope.

@jhp-lanl
Copy link
Collaborator Author

@Yurlungur I'd really like @jdolence's eyes on it as some point for a sanity check if at all possible, even if it's after the merge. Sometimes the original author has knowledge that is hard to obtain by reading alone.

I agree. My concern is I don't know when I will be able to get him to look. We were visiting him in Ann Arbor this week and I asked him to look, though. So there's hope.

I think his input will be valuable whenever we receive it.

@jhp-lanl
Copy link
Collaborator Author

That said, I still need to fix the CI. I'll work on that this afternoon.

CI Fixed! Array was out of bounds, and I just bit the bullet and enabled proxy variables for all my terminal sessions rather than limiting them to interactive ones.

sesame2spiner/examples/unit_tests/copper.dat Outdated Show resolved Hide resolved
singularity-eos/closure/mixed_cell_models.hpp Show resolved Hide resolved
Asum *= uscale / Tnorm;
rhoBsum /= Tnorm;
PORTABLE_REQUIRE(rhoBsum > 0., "Non-positive energy density");
PORTABLE_REQUIRE(rhoBsum > 0., "Non-positive Ideal PTE energy density guess");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function is called in the Init for PTESolverRhoU which I believe is supposed to handle non-ideal EOS.

Notice that TryIdealPTE is commented out from PTESolverRhoT with the following comment:

    // Leave this in for now, but comment out because I'm not sure it's a good idea
    // TryIdealPTE(this);
    // Set the current guess for the equilibrium temperature.  Note that this is already
    // scaled.

singularity-eos/closure/mixed_cell_models.hpp Show resolved Hide resolved
@jhp-lanl
Copy link
Collaborator Author

I think this is ready to go now

@Yurlungur
Copy link
Collaborator

👍 Merge when ready

@jhp-lanl
Copy link
Collaborator Author

Merging... @dholladay00 I think we're ready for a release

@jhp-lanl jhp-lanl merged commit f5e52ba into main Jul 23, 2024
5 checks passed
@jhp-lanl jhp-lanl deleted the jhp/robust_pte branch July 23, 2024 16:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Robustness Ensures that existing features work as intended
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants