Code generation fails for 10 MultiBody examples and more after latest BackEnd changes

[Rüdiger Franke]

Today the Cpp runtime failed to generate a simulator for 10 MultiBody examples from MSL 3.2.1. See e.g.

Modelica.Mechanics.MultiBody.Examples.Elementary.SpringWithMass

It appears that the information about array dims is missing in daeExpBinary (file CodegenCppCommon.tpl).

Moreover the nonlinear solver failed for Modelica.Fluid.Examples.InverseParameterization that had just been fixed yesterday in MSL.

Also some tests have been deactivated to get the backend changes into the main repository, including Cpp FMU generation and PumpingSystem -- the startup logo of OMEdit.

I wonder if it is justified to break so many things in the main repository. This is critical for users like us who want to stay tuned with recent additions.

[Rüdiger Franke]

It is even more critical for contributors like us -- where can one contribute if the main repository is broken?

[Adrian Pop]

Sorry about this. I talked with Lennart and we decided that he should commit his split of the backend transformations for simulation and initialization as he was waiting with it for a while now and is really needed. We knew that some models in the testsuite fail but only a few.
We didn't know the impact it would have on the CPP runtime.

Hopefully this will get fixed very soon.

[Lennart Ochel]

Sorry for the inconvenience. I gave notice about that in the last OpenModelica developer meeting. I also mentioned there that it could cause some regressions. I work hard on fixing the issues ASAP. The good thing about it is that my changes improve also the cpp runtime.
BTW: I Don't agree that there are many issues left. I worked several weeks on fixing a lot of issues before I pushed the changes.

[Lennart Ochel]

Replying to rfranke:

It is even more critical for contributors like us -- where can one contribute if the main repository is broken?

You could fork the latest stable version and work on that until we have a new stable version.

[Rüdiger Franke]

There seem two issues with the failed MultiBody tests, see e.g. Modelica.Mechanics.MultiBody.Examples.Elementary.SpringWithMass. One is a missing implementation for array casts. The second issue is that daeExpBinary doesn't match

   case MUL_MATRIX_PRODUCT(ty=T_ARRAY(dims=dims))

See CodegenCppCommon.tpl, line 2291. The C runtime just uses

   case MUL_MATRIX_PRODUCT(__)

Why does ty=T_ARRAY(dims=dims) not match?

[Adrian Pop]

@rfranke, i guess is not T_ARRAY in there but something else?

[Rüdiger Franke]

But what could be there?

The operation at hand is:

$TMP_54 = (*Real[3, 4]*)({{$STATESET1.A[1,1], $STATESET1.A[1,2], $STATESET1.A[1,3], $STATESET1.A[1,4]}, {$STATESET1.A[2,1], $STATESET1.A[2,2], $STATESET1.A[2,3], $STATESET1.A[2,4]}, {$STATESET1.A[3,1], $STATESET1.A[3,2], $STATESET1.A[3,3], $STATESET1.A[3,4]}}) * {body.Q[4], body.Q[3], body.Q[2], body.Q[1]}

Meaning the binary operation multiplies Real[3,4] with Real[4], resulting in Real[3]. Isn't that T_ARRAY?

Hudson is currently checking an implementation for cast_array. The remaining issue is that the not matching T_ARRAY results in the Cpp code:

  _$TMP_54.assign(daeExpBinary:ERR);

This should be:

  StatArrayDim1<double, 3> tmp29;
  multiply_array<double>(tmp27, tmp28, tmp29);  
  _$TMP_54.assign(tmp29);

But for this one needs to know the dimensionality of 1 and ideally also the size of 3. This is why T_ARRAY should match.

Alternatively, avoiding any sizing and maybe also resulting in faster code:

  multiply_array<double>(tmp27, tmp28, _$TMP_54);  

But can daeExpBinary know that the result will be assigned afterwards, in order to avoid the creating of a temporary array tmp29?

[Adrian Pop]

One needs to print what's in there as it might be wrong. I'll have a look myself.

[Rüdiger Franke]

It's T_REAL!??

[Adrian Pop]

It seems so as the code generated was:

void SpringWithMassInitialize::initEquation_57()
{
  ....
  double tmp27; // scalar
  cast_int_array_to_double(&tmp26, &tmp27); // used as array
  ....
}

The types of expressions left and right seems to be OK but the type inside the operator is wrong.

[Adrian Pop]

The type issues should be fixed in: d78c1bfa80e52f9fca8f58b116517a5bd5551d47/OMCompiler.
Added test for it in:
52d2ee5090879e5187686ff7b3d0070ea4398822/OpenModelica-testsuite.
I'll start the coverage job to see where we are now.

[Rüdiger Franke]

That was it. Having thought into daeExpBinary, it appeared appropriate to clean it up in 1dff76a87c9266e809fa7ecaa63b7138c4da43fe/OMCompiler.

[Martin Sjölund]

Milestone renamed

[Martin Sjölund]

Milestone renamed