LLNL
[BUG] CVODE attempts an "infinite" step when constraints are enabled, then fails unrecoverably
Current Behavior:
When solving a large system of ODEs that has non-negative constraints enabled, CVode will try to find a new stepsize after constraint checking fails. On several occasions, I have observed it trying an "infinite" step (of order 1e+308), which naturally fails unrecoverably, and the solver terminates with an error. This even happens if a maximum stepsize is set explicitly.
Expected Behavior:
With a set maximum stepsize, I would expect that setting to take precedence no matter what. Even without it, an infinite stepsize is obviously unreasonable and bound to fail.
Steps To Reproduce:
I do not currently have a MWE (apologies for that), and, while the behavior is deterministic for a particular build, small changes to the actual values used in the problem can actually sidestep the issue entirely. I'm not sure if this is a bug somewhere in my code, which I cannot currently share, but I have tracked the source of the infinity to the line referenced below and the behavior of N_VMinQuotient as specified in the documentation.
Environment:
- SUNDIALS version: 7.2.1
- OS: Kubuntu 24.04
- Compiler: Clang 20.0.0
Anything else:
I believe the issue stems from this line of code. Because N_VMinQuotient should return SUN_BIG_REAL if there are no nonzero denominators, and because all the subsequent operations take the maximum value of eta, the problematic value will always be chosen and an infinite stepsize is attempted, even when a maximum stepsize is explicitly set with CVodeSetMaxStep. I haven't yet figured out what the absence of nonzero denominators means, though.
@emprice Thanks for reporting this problem. I've modified one of our examples using inequality constraints and was able to reproduce similar behavior where the step size is increased rather than cut when a constraint violation is found. This occurs when the predictor and corrector both produce states that do not satisfy the inequality constraint. There are a couple ways to address this. I'll discuss this we the rest of the team and update this issue when I've added a fix.
