Opened 6 years ago

Last modified 3 years ago

#5328 new defect

ODE solver behaves erratically in two MultiBody examples with dynamic state selection

Reported by: Francesco Casella Owned by: Karim Adbdelhak
Priority: blocker Milestone: 1.19.0
Component: Run-time Version: v1.14.0-dev-nightly
Keywords: Cc: Andreas Heuermann, Lennart Ochel

Description

Steps to reproduce:

  • set -d=newInst,stateselection
  • simulate Modelica.Mechanics.MultiBody.Examples.Elementary.SpringDamperSystem

The simulation terminates successfully, but the solver statistics and the fairly long simulation time point to some issue with the solver

solver: dassl
53347 steps taken
139199 calls of functionODE
76637 evaluations of jacobian
  394 error test failures
25259 convergence test failures
4.2913s time of jacobian evaluation

Most importantly, if you cross-check body1.w_a[3] and its derivative, they are definitely not consistent with each other until about time = 2.4; afterwards, they seem more in synch with each other, at first sight.

This is strange, because the state selection includes body1.w_a[3] as a state, so the relationship among the two should be derivative/integral, with a relative tolerance of less than 1e-6. If you reduce the tolerance to 1e-7, the shape of the state curve changes, but it remains inconsistent with the derivative during the first two and a half seconds.

Maybe the indication of the state selection is incorrect, and what I am seeing is a wrongly computed dummy derivative. The reported state selection is the expected one, maybe the solver is doing something else in the background.

This problem does not show up if the old frontend is used to flatten the model, and I am currently investigating what is the difference among the two. Nevertheless, this kind of things should never happen anyway.

Change History (20)

comment:1 by Francesco Casella, 6 years ago

When #5332 is resolved, this issue will probably be resolved automatically. Yet, it would be worth understanding how it is possible that a non-dummy state derivative is so blatantly different from the slope of the corresponding state trajectory, because this issue may pop up in other models.

comment:2 by Martin Sjölund, 6 years ago

#5332 was resolved: how are the results now?

in reply to:  2 comment:3 by Francesco Casella, 6 years ago

Cc: Andreas Heuermann Lennart Ochel added
Priority: criticalblocker

Replying to sjoelund.se:

#5332 was resolved: how are the results now?

Unfortunatly, they are exactly the same, so the problem is not the same as the one in #5332.

Lennart, Karim, Andreas, would you mind having a look? This is also necessary to get MSL 3.2.3 100% working.

Version 0, edited 6 years ago by Francesco Casella (next)

comment:4 by Francesco Casella, 6 years ago

Summary: ODE solver behaves erratically in one MuliBody exampleODE solver behaves erratically in two MuliBody examples (issue with state selection?)

comment:5 by Francesco Casella, 6 years ago

Summary: ODE solver behaves erratically in two MuliBody examples (issue with state selection?)ODE solver behaves erratically in two MultiBody examples (issue with state selection?)

comment:6 by Lennart Ochel, 5 years ago

The dynamic behaviour is identical for the old and new frontend. The problem might be related to dynamic state selection. This is currently under further investigation.

comment:7 by Francesco Casella, 5 years ago

Any progress on this issue? Should we reschedule it to 2.0.0?

comment:8 by Francesco Casella, 5 years ago

The situation has gotten slightly worse after the last commits. With the latest nightly, the statistics now read:

solver: dassl
76030 steps taken
195615 calls of functionODE
110064 evaluations of jacobian
  621 error test failures
36280 convergence test failures
The simulation finished successfully.

comment:9 by Francesco Casella, 5 years ago

Additionally, if I turn on -d=bltdump, OMEdit crashes

comment:10 by Francesco Casella, 5 years ago

I also checked the state selection against Dymola. The state selection is exactly the same: same statically selected states, same dynamic state selection set, same selection of actual dynamic states during simulation: body1.Q[1], body1.Q[2], body1.Q[3].

comment:11 by Francesco Casella, 5 years ago

Maybe something's wrong with the Jacobian (numerical or symbolical, I don't know), since there is a convergence failure every two steps, and there are more evaluations of jacobians than steps, which is very unusual.

@Karim, can you please check that?

comment:12 by Francesco Casella, 5 years ago

Milestone: 1.14.01.15.0

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2.

This issue, previously marked as blocker for 1.14.0, is rescheduled to 1.15.0

comment:13 by Francesco Casella, 5 years ago

Summary: ODE solver behaves erratically in two MultiBody examples (issue with state selection?)ODE solver behaves erratically in two MultiBody examples (issue with symbolic Jacobian?)

comment:14 by Francesco Casella, 4 years ago

Milestone: 1.15.01.16.0

Release 1.15.0 was scrapped, because replaceable support eventually turned out to be more easily implemented in 1.16.0. Hence, all 1.15.0 tickets are rescheduled to 1.16.0

comment:15 by Francesco Casella, 4 years ago

Summary: ODE solver behaves erratically in two MultiBody examples (issue with symbolic Jacobian?)ODE solver behaves erratically in two MultiBody examples with dynamic state selection

comment:16 by Francesco Casella, 4 years ago

@Karim, maybe you want to have a second look at this.

In both cases, we have a rigid body suspended by a spring, which requires to use the internal state variables of the rigid body, in particular the quaternions for the orientation, with a dynamic state selection.

The initial conditions are such that the body mostly oscillates vertically, but also has a bit of initial angular momentum that makes it oscillate slightly around its horizontal axis and eventually to slightly swivel like a pendulum. This motion is caught in a completely wrong way by the dummy derivatives, resulting in an exponential amplification of the motion which is completely unphysical.

I'm not sure what you should check exacly to spot where the error is. Maybe comparing the solution with Dymola's will give some hints.

comment:17 by Francesco Casella, 4 years ago

Milestone: 1.16.01.17.0

Retargeted to 1.17.0 after 1.16.0 release

comment:18 by Francesco Casella, 4 years ago

Milestone: 1.17.01.18.0

Rescheduled to 1.18.0

comment:19 by Francesco Casella, 3 years ago

Milestone: 1.18.0

Ticket retargeted after milestone closed

comment:20 by Francesco Casella, 3 years ago

Milestone: 1.19.0

1.18.0 blocker tickets moved to 1.19.0

Note: See TracTickets for help on using tickets.