Fix assertions

[tobolar]

This PR especially

1. fixes senseless assertions like

   assert( body.r_0[2] - body.r_0[2] < tol ...);
   

   (so comparing the variable body.r_0[2] to itself).

   Fixing this, the assertion is triggered for tol=1e-4. So I additionally changed the intialization prismatic1.a(..., start=9-world.g) to have more precise value.

   Note: for ModelicaTest.MultiBody.Forces.Spring, this PR changes values of reference signals prismatic1.s and prismatic1.v over time. So regression check could be broken => reference signals shall be recalculated/re-generated.

   No such behaviour expected for ModelicaTest.MultiBody.Forces.Spring2.

2. Fixes missing absolute differences like abs(x - y) for assertions.

3. Separate tolerances to different physical quantities

4. SI units for tolerances

Refs #4193

[HansOlsson]

Apart from the previous proposal to have two different tolerances (rtol and vtol) there's another issue with the test:

It is still a one-sided test!

[tobolar]

@MartinOtter As I fixed the assert-clause below, it was triggered. So I changed prismatic1.a.start to far more precise value to fulfill the assertion. If this was not originally intended in the test model, then some other estimation shall be taken. But the original start=-0.81 is too hight.

[HansOlsson]

I was a bit lost here. Having -0.81 as a magic number is weird, changing it to 9-world.g just seems like magic!
After some thinking and translating the model in Dymola I got that the model has the following parameters:

parameter Modelica.Units.SI.TranslationalSpringConstant spring_c=10
  "Spring constant";
parameter Modelica.Units.SI.Length spring_s_unstretched=0.1
  "Unstretched spring length";
parameter Modelica.Units.SI.Position prismatic_s_start=-1
  "Relative distance between frame_a and frame_b";
parameter Modelica.Units.SI.Mass m=1;

Adding them where appropriate allows us to write:
a(fixed=true, start=spring_c*(-prismatic_s_start-spring_s_unstretched)/m - world.g)

I don't know if there is an intuitive explanation for the formula, but at least it seems to reduce the magic (and not only does it work, it's also unit-correct).

[tobolar]

@HansOlsson Perfect, I like it! (Why didn't I just think of that.)

The question remains - was it an intention to cause the difference for the assert? Or is that precise value just fine now?

[HansOlsson]

I think the actual value is just fine now - but I would prefer replacing the magic 9 by a non-magic formula as described above. I don't think the assert was supposed to trigger.

I believe the history of the model went something like this:

1. Original model with code added in some order:
   • Originally g was 9.81 (something like that was common when I was in school, I think we used 9.82 in Lund - but Munich is south of here).
   • Based on that value for g and the spring as given above the start-value was given as 9-g and evaluated, where 9 corresponds to spring_c*(-prismatic_s_start-spring_s_unstretched)/m.
   • A non-working assert was added, it didn't trigger so it was assumed to work!
2. Then g was replaced by the official 9.8065, but since the assert was broken it wasn't detected.
3. And here the assert is being corrected.

[tobolar]

I have adapted your suggestion introducing a final parameter for s.start (prismatic_s_start itself is not a parameter) in b118bb6.

P.S. To me g being 9.82 sounds like from another universe. ^^

[HansOlsson]

As indicated I think that the Spring-formula now looks too much like magic.

[HansOlsson]

Looking good

[henrikt-ma]

May I ask why the parameter is made final, but not making the modifications using it final?

[tobolar]

No particular reason for this. I just didn't touch the modifiers. The parameter itself is final just to retain its value.