#5512 closed defect (fixed)
Problem with arrayed parameters in NF
Reported by: | crupp@… | Owned by: | perost |
---|---|---|---|
Priority: | critical | Milestone: | 1.16.0 |
Component: | New Instantiation | Version: | v1.14.0-dev-nightly |
Keywords: | Cc: |
Description
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.
Attachments (2)
Change History (14)
Changed 5 years ago by crupp@…
Changed 5 years ago by crupp@…
comment:1 Changed 5 years ago by crupp@…
comment:2 Changed 5 years ago by anonymous
Forgot to add that I'm using the new frontend with -d=newInst.
comment:3 Changed 5 years ago by casella
Probably related to #5493
comment:4 follow-up: ↓ 6 Changed 5 years ago by 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.
comment:5 Changed 5 years ago by 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;
comment:6 in reply to: ↑ 4 ; follow-ups: ↓ 7 ↓ 8 Changed 5 years ago by 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?
comment:7 in reply to: ↑ 6 Changed 5 years ago by 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.
comment:8 in reply to: ↑ 6 Changed 5 years ago by 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.
comment:9 Changed 5 years ago by 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.
comment:10 Changed 4 years ago by casella
- Milestone changed from 1.14.0 to 1.16.0
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
comment:11 Changed 4 years ago by perost
- Resolution set to fixed
- Status changed from new to closed
Fixed in 4cf73067.
comment:12 Changed 4 years ago by casella
Backported to 1.14.0 and 1.15.0
Oops, ignore the second attachment. It is the same as the first. User error.