Cyclically dependent constants or parameters ?

[dr.christian.kral@…]

Please consider the following package

package TestPackage
  record Rec
    Real a=1;
    Real b;
  end Rec;

  model TestRec1
    parameter TestPackage.Rec rec(b = 2 * a);
    parameter Real a = rec.a;
  end TestRec1;

  model TestRec2
    parameter TestPackage.Rec rec(b = 2 * rec.a);
    parameter Real a = rec.a;
  end TestRec2;
end TestPackage;

In my opinion the implementation of TestRec1 and TestRec2 are identical, since a = rec.a in both cases.

Check of TestRec1

Cyclically dependent constants or parameters found in scope TestPackage.TestRec1: {a,rec}.
Error occurred while flattening model TestPackage.TestRec1

Check of TestRec2

Check of TestPackage.TestRec2 completed successfully.

I suppose this is a bug

OMEdit 1.13.0~dev-7-g5ab8668
Connected to OpenModelica 1.13.0~dev-126-g1311439
Linux Mint 18.2 64bit

[anonymous]

IMO bounding are called equations, but in reality are assignments.
This justifies the difference in the two cases.

[Martin Sjölund]

Perhaps there is something slightly wrong in the check in TestRec1: a references rec (which includes rec.a and rec.b), and if rec.b then has a binding referencing a, it has a dependency on rec.b as well. I guess the dependency is too strict and needs a special case for when the binding references rec.a without using subscripts.

@perost: -d=newInst handles TestRec1, but only if the members are changed to parameter. Seems to be something wrong in the new instantiation that should be looked at before it's too late.

[Per Östlund]

Replying to sjoelund.se:

@perost: -d=newInst handles TestRec1, but only if the members are changed to parameter. Seems to be something wrong in the new instantiation that should be looked at before it's too late.

It's no big deal, I just haven't implemented propagation of attributes yet. I started implementing that last week, but got distracted by other things.

The new instantiation also doesn't actually check for cyclically dependent constants and parameter yet either, but in the new instantiation it's trivial to do it correctly. The check in the old instantiation will probably never work correctly for all cases though, so I think the best we can do until the new instantiation is ready is to simply add a flag to allow disabling the error. I can do that later today.

[Martin Sjölund]

Replying to perost:

so I think the best we can do until the new instantiation is ready is to simply add a flag to allow disabling the error. I can do that later today.

A flag to turn it into a warning, I assume? (And making the error say that this flag can be used to turn it into a warning?)

[Per Östlund]

Replying to sjoelund.se:

Replying to perost:

so I think the best we can do until the new instantiation is ready is to simply add a flag to allow disabling the error. I can do that later today.

A flag to turn it into a warning, I assume? (And making the error say that this flag can be used to turn it into a warning?)

Yes, but I need to check whether it actually works though. The instantiation depends on the check to sort the components, so it might still fail to instantiate the model I guess.

[Per Östlund]

I've added a flag -d=ignoreCycles now and updated the error message to reference it, and the models in the ticket seems to work fine with it. I'm currently pushing it in to the 1.12 maintenance branch too, so it should hopefully be part of the upcoming 1.12 release.

Since it's unlikely that this will be fixed properly in the current instantiation and it doesn't yet work as is in the new I'm leaving the ticket open but reassigning it to the new instantiation.

[Per Östlund]

This seems to work just fine with the new instantiation now.

[Francesco Casella]

Will be the default behaviour in 2.0.0, for the time being you need -d=newInst