You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some expressions in dwdp that involve DiracDeltas may become NaN when evaluated for DiracDelta(0). DiracDelta(0) is currently implemented as DBL_MAX, not infinity. Therefore, a * DiracDelta(0) is finite for a in [-1, 1].
For the Bertozzi_PNAS2020 model, we have something like a * DiracDelta(0) * b, which is non-finite if a is outside [-1, 1], even if a * b would be in [-1, 1] (in this specific case, a*b == 0). Reordering the multiplicands fixes that problem.
Not sure how to handle that robustly. In this case, just moving the DiracDelta as far to the right as possible fixes the issue. However, in other situations it might be beneficial if a DiracDelta(x != 0) occurs further left.
Any thoughts?
The text was updated successfully, but these errors were encountered:
How do we end up with Dirac deltas in dwdp in the first place? Sounds like something with event parsing went awry. Having briefly looked at the model it looks like it's coming from those piecewise functions, which should be processed by
* Substitute non-time-dependent Heavisides
* Substitute inside the expanded expression, otherwise not all substitution targets are found
ClosesAMICI-dev#2231
Encountered the following problem with https://github.com/Benchmarking-Initiative/Benchmark-Models-PEtab/tree/d7c52f90b15ca83a3d3f832f08989f1448fbd01e/Benchmark-Models/Bertozzi_PNAS2020:
Some expressions in dwdp that involve DiracDeltas may become NaN when evaluated for DiracDelta(0). DiracDelta(0) is currently implemented as DBL_MAX, not infinity. Therefore,
a * DiracDelta(0)
is finite fora
in [-1, 1].For the Bertozzi_PNAS2020 model, we have something like
a * DiracDelta(0) * b
, which is non-finite ifa
is outside [-1, 1], even ifa * b
would be in [-1, 1] (in this specific case, a*b == 0). Reordering the multiplicands fixes that problem.Not sure how to handle that robustly. In this case, just moving the DiracDelta as far to the right as possible fixes the issue. However, in other situations it might be beneficial if a DiracDelta(x != 0) occurs further left.
Any thoughts?
The text was updated successfully, but these errors were encountered: