Front-end fails to lookup component references in modifications

[rfranke]

See e.g. PowerSystems.Examples.Spot.DrivesAC3ph.SM_ctrlAv. The model has the parameter record member sm_ctrl.motor.par.f_nom that is initialized from system.f_nom. The frontend generates:

  final parameter Real sm_ctrl.motor.par.f_nom(quantity = "Frequency", unit = "Hz")
    = sm_ctrl.motor.par.system.f_nom "nominal frequency";

[rfranke]

The error message has changed after more replaceable model instances have been changed to replaceable classes. It reads now:

"[PowerSystems/PowerSystems/AC3ph/Drives.mo:237:13-237:42:writable] Error: Variable motor.par.pp not found in scope PowerSystems.AC3ph.Drives.SM_ctrl$sm_ctrl.
Error: Error occurred while flattening model PowerSystems.Examples.Spot.DrivesAC3ph.SM_ctrlAv

It's the same kind of error though: lookup of class modifiers.

[adrpo]

In the previous library PowerSystems 0.4.0 this model works fine.

Using the PowerSystem latest the problem is with the eager evaluation that we have in the front-end. As you can see here:

model SM_ctrl  "Synchronous machine, current-control" 
  ...
  replaceable model Motor = PowerSystems.AC3ph.Machines.Synchron3rd_pm_ctrl
    (final w_el_ini = w_ini * motor.par.pp) "syn motor, current controlled";
  Motor motor "syn motor, current controlled";
  ...

you have Motor class has a modification depending on motor instance who has Motor at type.

The OM compiler will try to instantiate the motor instance to lookup motor.par.pp when instantiating class Motor but for that it needs to instantiate class Motor and you got a recursive dependency here.

We should support this via some sort of lazy evaluation but I'm not sure if this is good practice for modeling.

[rfranke]

The diagnostics in comment:3 describes the status of comment:1. This resulted from the mechanical introduction of replaceable model types. I agree that it is strange to modify a replaced type with a member of an instance of it.

The current trunk removes these recursive dependencies, see:

​https://github.com/modelica/PowerSystems/commit/89ec43788411352908c202c6a02ed8c0a48de72b

We are back to the original error message opening this ticket: The model has an outer system and assigns system.f_nom to sm_ctrl.motor.par.f_nom. The frontend introduces the variable sm_ctrl.motor.par.system.f_nom.

[adrpo]

@rfranke: this is definitely a bug I can fix, it seems to have issues with finding the inner system so it does the prefixing when it shouldn't. I'll look into it a bit now.

[adrpo]

Ok, I found the bug, we're checking for existing outer component references and we cannot find them in this case because the code is stupid, probably written by me a long time ago :)
The component reference we have is sm_ctrl.motor.par.system.f_nom and the existing outer component references we have are:

outer sm_ctrl.motor.system -> inner system
outer sm_ctrl.inverter.system -> inner sytem
outer sm_ctrl.system -> inner sytem

The sm_ctrl.motor.par.system.f_nom should match sm_ctrl.motor.system but it doesn't because we use ComponentReference.crefPrefixOf(outer, fullCref) have par in there. If we cannot match we should remove par, motor, etc down the hierarchy and try again.

[adrpo]

Fixed in 2acba86d/OMCompiler, test added in ee21b31/OpenModelica-testsuite. We'll see in the morning how PowerSystems will improve.

[adrpo]

@rfranke maybe we should open another ticket with the issues from comment:3.

[rfranke]

Let's see if the issue from comment:3 hurds anywhere. I didn't find a clarification in the Modelica spec if this shall work.

[adrpo]

It is already used in MSL transformers as far as I know. There you have a mutually recursive transformer data with some other component if I remember correctly. But the spec doesn't say anything about lazy evaluation is somehow implied.

[adrpo]

I ran a PowerSystems coverage on dev:
Before:
BuildModel Results: 70/107 succeeded
Simulation Results: 66/107 succeeded
After:
BuildModel Results: 80/107 succeeded
Simulation Results: 73/107 succeeded
​https://dev.openmodelica.org/libraries/PowerSystems/BuildModelRecursive.html

[adrpo]

Hm, I think the fix needs to be re-implemented to be faster. I'll look into it tomorrow.
I have a model that has about two times slower compilation time.

Before:
real    3m42.329s
user    6m31.637s
sys     0m4.996s
After:
real    6m25.601s
user    14m9.035s
sys     0m5.291s

[adrpo]

Improved speed quite a bit in e2726c6/OMCompiler:

real    2m54.314s
user    5m15.888s
sys     0m3.760s

[sjoelund.se]

Milestone deleted