Drift in ModelicaTest.MultiBody.Joints.JointUSP2 with different interval setting

[maltelenz]

In System Modeler we have a default of 2000 intervals. When we simulate ModelicaTest.MultiBody.Joints.JointUSP2 we get this result:

base is the reference from MAPLib, out is the result from System Modeler.

If we force the same interval as the reference used, we get the same result as the reference.

To me, this indicates that the experiment annotation in the model needs an Interval setting.

Edit: This is not a new issue, we have just ignored it in our testing for past versions of MSL (by forcing the same interval setting as the reference). As such, I would not consider this a blocker for 4.1.0.

[HansOlsson]

Ideally the solution should not depend on the interval (but only on the model and tolerance).

Investigating in Dymola shows that it is more complicated:

• If you use 10x more intervals and also tighten the tolerance a factor of 10 (???), the solution overlaps the default solution.
• If you use 10x more intervals and don't tighten the tolerance you get something close to the other result up to 3.26 s. However, then the big problem occurs - the simulation practically stops due to a repeated assertion: abs(jointUSP.prismatic.k1a)>1e-10. If you look at the solution that seems to occur twice before that (0.68 s and 1.97 s); it is just that it is missed.

I believe that:

• The failure is consistent with the documentation of JointUSP; i.e., parallel axis leading to a singularity.
• The drift and failure have the same underlying cause - the solution diverges after 0.68 s when it was close to a singularity. In the acceleration you can see really weird behavior at 1.97 s (the second singularity).

When messing around I got this - the main part is that k1a>1e-10 is not satisfied:

What isn't 100% clear to me is whether this is physically correct - i.e., whether such a configuration of joints is that problematic. But either the underlying model needs an overhaul to handle it, or the test-case should avoid such cases. However, in neither case do I find it a blocker - either it will require large re-design or it is just a bad test-case.