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

Catastrophic cancellation in PadeDelay1 #4409

Open
henrikt-ma opened this issue May 31, 2024 · 2 comments
Open

Catastrophic cancellation in PadeDelay1 #4409

henrikt-ma opened this issue May 31, 2024 · 2 comments
Labels
L: Blocks Issue addresses Modelica.Blocks

Comments

@henrikt-ma
Copy link
Contributor

This concerns a potential issue with the example ModelicaTest.Blocks.PadeDelay1.

In System Modeler, der(padeDelay1.x[1] is computed using the following expression:

der(padeDelay1.x[1]) = padeDelay1.a1[10] * padeDelay1.x[10] + padeDelay1.a1[9] * padeDelay1.x[9] + padeDelay1.a1[8] * padeDelay1.x[8] + padeDelay1.a1[7] * padeDelay1.x[7] + padeDelay1.a1[6] * padeDelay1.x[6] + padeDelay1.a1[5] * padeDelay1.x[5] + padeDelay1.a1[4] * padeDelay1.x[4] + padeDelay1.a1[3] * padeDelay1.x[3] + padeDelay1.a1[1] * padeDelay1.x[1] + padeDelay1.a1[2] * padeDelay1.x[2] + padeDelay1.b11 * padeDelay1.u

The first time this is evaluated, all terms are zero except the first and the last one. The first one is -6.5472907499999936e+17, while the last one is 6.5472907499999936e+17, which leads to completely catastrophic cancellation. We happen to get away with it on all platforms except one, but the catastrophic cancellation as such exists on all platforms.

Is it System Modeler which is not smart enough about handling the PadeDelay equations, or is the catastrophic cancellation happening in other tools as well?

On a side note, if I enable balance in the PadeDelay, the simulation runs fine, but I haven't investigated whether this is thanks to actually eliminating the catastrophic cancellation.

@henrikt-ma henrikt-ma added the L: Blocks Issue addresses Modelica.Blocks label May 31, 2024
@HansOlsson
Copy link
Contributor

Well, the question is really whether cancellation happens in the model - and the answer is that it does:

We know that der(x[1]) starts at 0, and the formula for computing it involves a1[10]*x[10].

Without balancing x[10] starts at 0.1, and a1[10] is -6.5e18, so obviously there must be cancellation.
With balancing x[10] start at 25.6 and a1[10] is -5.67 (all a1-coefficients are between -550 and -3.26 and abs(x[i])<1600), so the cancellation is avoided.

What isn't clear is whether this cancellation is really problematic or not, as without balancing der(x[1]) goes smoothly up to 1e16, and still the output looks the same as with balancing.

As an example modifying the unbalanced model to set x[1].start=1e14 barely modifies the Padé output indicating that the model is robust with regards to the errors in that term (when using 64-bit floating point numbers), and thus having a non-zero derivative for it doesn't seem that problematic.

To me the obvious improvement would be to make balance the default, but that isn't backwards compatible.

Note that if we were to increase n=18 then the unbalanced model seems to hang with Dymola; whereas the balanced model even runs (slowly) with n=30.

@henrikt-ma
Copy link
Contributor Author

What isn't clear is whether this cancellation is really problematic or not, as without balancing der(x[1]) goes smoothly up to 1e16, and still the output looks the same as with balancing.

On the affected platform, we get garbage in the order of 1e2 in the derivative, which appears to be enough to make the error control effectively hang the simulation. On the other platforms, we happen to get an exact 0.0 instead of the noise, and integration completes in no time.

To me the obvious improvement would be to make balance the default, but that isn't backwards compatible.

I suppose the backward incompatibility would be easy to accept if the change is considered a bugfix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
L: Blocks Issue addresses Modelica.Blocks
Projects
None yet
Development

No branches or pull requests

2 participants