VODE steps fail if the state is not valid #350
Conversation
integration/VODE/vode_type.H
Outdated
| // in any integration step. | ||
| const Real vode_increase_change_factor = 2.0_rt; | ||
| const Real vode_decrease_change_factor = 0.5_rt; | ||
| const Real vode_change_factor_X_threshold = 1.0e-6_rt; |
There was a problem hiding this comment.
I think vode_change_factor_X_threshold should be max(1.e-6, atol_spec)
There was a problem hiding this comment.
Maybe I should make it just atol_spec?
|
can you update the CHANGES.md? |
|
all tests pass: http://groot.astro.sunysb.edu/Microphysics/test-suite/gfortran/2020-07-20-001/index.html |
As far as I can tell, this doesn't affect normal burns, it just affects burns that would have failed anyway with (say) X > 1. By construction, we didn't have this in the suite, because all our burns in the suite pass :-) |
|
okay, I'm happy with this one the CHANGES.md is updated |
Done |
Commit 9d3ddb1 added intentional failure modes to the VODE integrator to prevent VODE from giving us a state where the integrator believed it was successful but the state was not physically valid. Specifically, we checked on T < 0 and X < -0.01 or X > 1.01. Although this gave us the opportunity to then retry the burn, retries are expensive and we'd like to avoid them if possible (#106). One way we can significantly mitigate this is by preventing these failure modes from occurring at the end of each step rather than only at the end of the burn. We can then rely on the integrator's built-in step retry mechanism (which decreases dt or changes the integration order).
I chose to use the same failure modes as the one at the end of the burn. Additionally, I added a failure mode if any X changes by more than a factor of 2. The abundance never changes that much in a single step in a typical burn, but I have witnessed some extreme cases where the abundance floors in a single integration step and VODE doesn't reject the update. (I am not sure why.)