Problem with arrayed parameters in NF

[crupp@…]

The attached model produces the following translation error:

[2] 10:12:43 Translation Error
[C:/dev/OM64bit/OMCompiler/Compiler/NFFrontEnd/NFCeval.mo: 888:9-888:67]: Internal error NFCeval.evalBinaryMul failed to evaluate ‘0.0174532925199433 * {90.0, 180.0, 270.0, 360.0}‘

Yet, it is still allowed to proceed to compilation and ultimately fails after compile-time errors. The errors indicate a problem with converting the array instantiation of the hub_angle parameter for the arrayed model stage3[N] (see inside model Stage2).

Some notes of interest:
-The whole array is passed to a single parameter value (i.e., array->real) as seen in the model instantiation
parameter Real stage1.stage2.stage3[4].fixedRotation1.angles[3](quantity = "Angle", unit = "deg") = {0.0, 90.0, 180.0, 270.0} "Rotation angles around the axes defined in 'sequence'";}
-The incorrect instantiation does not affect stage3[1], only indices 2-4
-The model is allowed to write out and compile despite having a translation error
-If the limiter1 block in TopModel is removed then the model still throws a translation error and the instantiation is still wrong, but it compiles and simulates successfully (this is bizzare)

It seems like there are multiple problems here: array instantiation, getting to compile stage despite translation error, and the strange influence of the limiter1 block.

[crupp@…]

Oops, ignore the second attachment. It is the same as the first. User error.

[anonymous]

Forgot to add that I'm using the new frontend with -d=newInst.

[casella]

Probably related to #5493

[crupp@…]

I have new information on this bug. It is still an issue as of a recent .

It seems that the issue may be related using a function to change the units in a final parameter. The 0.0174532925199433 factor comes from the function Modelica.SIunits.Conversions.from_deg (i.e., pi/180). This function is used within the model Modelica.Mechanics.MultiBody.Parts.FixedRotation in the final parameter R_rel:

final parameter Frames.Orientation R_rel=if rotationType == Types.RotationTypes.RotationAxis
       then Frames.planarRotation(
        Modelica.Math.Vectors.normalizeWithAssert(n),
        Cv.from_deg(angle),
        0) else if rotationType == Types.RotationTypes.TwoAxesVectors then
      Frames.from_nxy(n_x, n_y) else Frames.axesRotations(
        sequence,
        Cv.from_deg(angles),
        zeros(3)) "Fixed rotation object from frame_a to frame_b";

It seems like the final modifier may be the key to this bug. Perhaps the parameter is finalized too early?

Also, there are no records involved in this model, so I don't think it is related to #5493.

[crupp@…]

Here is a simpler model that reproduces the error.

model evalBinaryMul_bug
  parameter Integer N = 4;

  arm[N] arm1(hub_angle = array(i*90.0 for i in 1:N));
    
  model arm
    parameter Real hub_angle;
    Modelica.Mechanics.MultiBody.Parts.FixedRotation fixedRotation1(angle = hub_angle, n = {0, 1, 0}, r = {1, 0, 0});
  end arm;

end evalBinaryMul_bug;

[casella]

Replying to crupp@…:

Also, there are no records involved in this model, so I don't think it is related to #5493.

Well, Frames.Orientation is indeed a record and, as you pointed out in comment:4, it seems to be involved in the issue.

@perost, can you please comment on this? Is this example working already on your branch?

[perost]

Replying to casella:

Replying to crupp@…:

Also, there are no records involved in this model, so I don't think it is related to #5493.

Well, Frames.Orientation is indeed a record and, as you pointed out in comment:4, it seems to be involved in the issue.

@perost, can you please comment on this? Is this example working already on your branch?

No, it's currently failing with a weird NFCeval.evalBuiltinAbs got invalid arguments (0.0) error. I'll have to take a look at it when I have some time.

[crupp@…]

Replying to casella:

Replying to crupp@…:

Also, there are no records involved in this model, so I don't think it is related to #5493.

Well, Frames.Orientation is indeed a record and, as you pointed out in comment:4, it seems to be involved in the issue.

@perost, can you please comment on this? Is this example working already on your branch?

Oops. Yes, you are right. Not sure why I was thinking otherwise. Nevertheless, I hope the additional information helps fix the bug.

[crupp@…]

Here are some other details I've found through testing. Consider the following where I've marked which lines are required to fail. It seems to be a very specific set of conditions.

model evalBinaryMul_bug_v2
  parameter Integer N = 4;
  sub1[N] S1(p0 = array(i*90.0 for i in 1:N));  // Fails
//  sub2[N] S2(p1 = array(i*90.0 for i in 1:N));  // OK
  
  record rec
    Real value;
  end rec;
  
  function func
    input Real x;
    output rec y;
  algorithm
    y.value := 1.0*x;  // Fails
//    y.value := x;  // OK
  end func;
    
  model sub1
    parameter Real p0;
    sub2 S2(p1=p0);
  end sub1;
    
  model sub2
    parameter Real p1;
    final parameter rec p2 = func(p1);  // Fails
//  parameter rec p2 = func(p1);  // OK
//  final parameter rec p2(value=p1); // OK
  end sub2;

end evalBinaryMul_bug_v2;

Fail conditions:
-It does require the use of records.
-The record parameter must be final and be evaluated via a function (see model sub2).
-Given the above, the function must multiply the input by a constant (see function func).
-Given the above, the array must be passed two layers deep. Passing directly to the sub2 model containing the final parameter works (see top of example).

I hope this helps narrow down the problem.

[casella]

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2. This issue is rescheduled to 1.16.0

[perost]

Fixed in 4cf73067.

[casella]

Backported to 1.14.0 and 1.15.0