Enumerated types causing errors

[klenk@…]

When I attempt to simulate the model Test.SimpleEngine_pass from the attached file, I get the follow error. This model works with omc r21000, but does not work with the latest nightly version of omc r21957. I see similar errors in all of my models that use enumerated types.

Warning: The initial conditions are not fully specified. Use +d=initialization for more information.
Error: Error building simulator. Build log: clang -fPIC -I"/usr/include/omc/c" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o G18802.o G18802.c
clang -fPIC -I"/usr/include/omc/c" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o G18802_functions.o G18802_functions.c
clang -fPIC -I"/usr/include/omc/c" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o G18802_records.o G18802_records.c
clang -fPIC -I"/usr/include/omc/c" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o G18802_01exo.o G18802_01exo.c
clang -fPIC -I"/usr/include/omc/c" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -c -o G18802_02nls.o G18802_02nls.c
G18802_02nls.c:50:43: error: no member named 'nominal' in 'struct INTEGER_ATTRIBUTE'

nlsData->nominal[i] = $P$ATTRIBUTE$PReq.nominal;

~

G18802_02nls.c:70:43: error: no member named 'nominal' in 'struct INTEGER_ATTRIBUTE'

nlsData->nominal[i] = $P$ATTRIBUTE$PReq.nominal;

~

2 errors generated.
make: * [G18802_02nls.o] Error 1

[Lennart Ochel]

Yes, you are right. The models worked in r21000 because no nonlinear systems are generated. Now, there are some nonlinear systems with enumeration types as iteration variables. That’s a bit strange and sounds not that wise. Probably, there should be no such nonlinear systems.

[Lennart Ochel]

I did some analysis and figured out that the issue was introduced in r21426.

[Lennart Ochel]

I get your models working again, by partially reverting the changes from r21426:

Compiler/BackEnd/ExpressionSolve.mo

@@ -96 +96 @@
     local
       DAE.Exp rhs,lhs,res,e1,e2,e3,crexp;
       DAE.ComponentRef cr,cr1;
-      list<DAE.Statement> asserts,asserts1;
+      list<DAE.Statement> asserts,asserts1,asserts2;
 /*
     case(_,_,_,_) // FOR DEBBUGING...
       equation
@@ -115 +115 @@
       then
         (res,asserts);
 
+    case (_,DAE.IFEXP(e1,e2,e3),_,_)
+      equation
+        (lhs,asserts) = solve_work(inExp1,e2,inExp3,linearExps);
+        (rhs,asserts1) = solve_work(inExp1,e3,inExp3,linearExps);
+        (res,_) = ExpressionSimplify.simplify1(DAE.IFEXP(e1,lhs,rhs));
+        asserts2 = listAppend(asserts,asserts1);
+      then
+        (res,asserts2);
+
+    case (DAE.IFEXP(e1,e2,e3),_,_,_)
+      equation
+        (lhs,asserts) = solve_work(e2,inExp2,inExp3,linearExps);
+        (rhs,asserts1) = solve_work(e3,inExp2,inExp3,linearExps);
+        (res,_) = ExpressionSimplify.simplify1(DAE.IFEXP(e1,lhs,rhs));
+        asserts2 = listAppend(asserts,asserts1);
+      then
+        (res,asserts2);
+
     // solving linear equation system using newton iteration ( converges directly )
     case (_,_,DAE.CREF(componentRef = _),_)
       equation

I will check it in if this will not break any test from the test suite.

[Lennart Ochel]

Vitalij, is there any good reason for the changes I reverted with r21963? Otherwise, this is fixed with that r21963. :-)

[Lennart Ochel]

I added the tests from SimpleEngine.mo to the test suite in r21964.

[Vitalij Ruge]

Lennart,

you can try
e.g.

model foo
  Real y1;
equation
  2*y1+time = (if y1 < 0.5 then y1 + 3 else y1 + 5);
end foo;

bevor and after you changes.

After you commit we get the wrong soulution

  RELATIONHYSTERESIS(tmp1, $Py1, 0.5, 0, Less);
  $Py1 = (tmp1?(3.0 - time):(5.0 - time)); //y1 = f(y1) 

[Lennart Ochel]

Well, in that case your fix from r21426 was not good enough ;-). I still consider this ticket as fixed and you should try to find a better fix for your model above.
BTW: Please, add a test to the test suite once it is working.

[Vitalij Ruge]

The solution of SimpleEngine.mo is wrong!

 Req = if Req == Test.SimpleEngine_pass.Requirement.success or (-the_model_under_test.damper1.w_rel) > desired_velocity then Test.SimpleEngine_pass.Requirement.success else Test.SimpleEngine_pass.Requirement.unknown

We get as solution the Req = f(Req), which is still a nonlinear loop and not the soultion, because left and right side depennds on Req.
My fix worked for this good enough!

[Lennart Ochel]

Okay, Vitalij is right. Your model worked in accident and the solution was wrong. Now it generates the correct algebraic loop that is a bit tricky to solve. Nevertheless, there should be no code generation issue.

I reverted the previous commit in r21966 and added the foo test instead of the SimpleEngine test.

[Bill Janssen]

This was bothering us in Friday's nightly build. r21946.

Why is there no code generation issue? Integer variables do not have an attribute called "nominal". Yet code is being generated that references this attribute.

[Lennart Ochel]

Sorry, I expressed myself badly:
The nonlinear equation from your model is not supported by OpenModelica (and probably most other Modelica Tools as well). The reason is that it needs to have an integer (or enumeration) variable as iteration variable.
Anyway, the code generation should not fail in this strange manner. A solution would be to cache those systems during the symbolic transformation and before doing code generation at all. There we could introduce a traceable error message.

If there will be support for such systems can wbraun tell you. That's why I put him in to this discussion.

I am not sure what you want to model. But you can break the loop using the pre-operator like the following:

  equation
    if pre(Req) == Requirement.success or the_model_under_test.inertia1.w > desired_velocity then
      Req = Requirement.success;
    else
      Req = Requirement.unknown;
    end if;
  end SimpleEngine_fail;

If this fits still your requirement, it would solve your issues.

[Martin Sjölund]

Well... A non-linear system with enumeration types should be generated as a mixed discrete/continuous nonlinear system. Not a regular nonlinear system. And just as we do for Integers in a mixed system, an error message should be generated saying we only support Boolean mixed systems.

I guess anyway.

[Lennart Ochel]

If there is support for boolean systems, it should be easy to extend the approach to support (small) enumerations as well.