Improve the performace of BackendDAEUtil.sortGlobalKnownVarsInDAE with the NF

[Francesco Casella]

Please check this ​Hudson report

These two consecutive lines show up:

Notification: Performance of postOpt setEvaluationStage (simulation): time 0.1457/114.5, allocations: 59.96 MB / 34 GB, free: 0.5601 GB / 1.417 GB
Notification: Performance of Backend: time 66.65/181.2, allocations: 12.95 GB / 46.95 GB, free: 0.5146 GB / 1.479 GB

At the end of the (supposed) last step of backend, 114.5 seconds have elapsed, but then additional 66.65 seconds are reported as "Performance of Backend" bringing the total to 181.2 seconds. It's not clear to me what happens in this additional minute of elaboration.

[Francesco Casella]

It seems like there is some additional activity carried out by daeMode that is not reported as such.

Please

• report explicitly what that is,
• make sure it scales properly, because this extra time scales as O(N²) for the DistributionSystemModelica model

[Willi Braun]

It's basically a hidden initialization task, that sorts all parameter binding equations in the
correct order: BackendDAEUtil.sortGlobalKnownVarsInDAE.
Added in execStat in 2913ed0/OMCompiler to associate the passed time with the corresponding activity.

[Willi Braun]

For some reason this is only a performance issue with -d=newInst in ​Hundson Report daeMode.

Also I'm not able to run this model local with the new instantiation, since I get the following error:

"Notification: From here:
[omc/NFModelicaBuiltin.mo:40:1-42:19:writable] Error: An element with name ExternalObject is already declared in this scope.
Error processing file: TestSuite.Electrical.DistributionSystemDC.ScaledExperiments.DistributionSystemModelica.mos
Notification: From here:
[omc/NFModelicaBuiltin.mo:40:1-42:19:writable] Error: An element with name ExternalObject is already declared in this scope.
Notification: From here:
[omc/NFModelicaBuiltin.mo:40:1-42:19:writable] Error: An element with name ExternalObject is already declared in this scope.

@perost Do you have an idea?

[Per Östlund]

Replying to wbraun:

@perost Do you have an idea?

It seems to happen when setting -d=newInst twice, e.g. by running a script containing setCommandLineOptions("-d=newInst") with omc -d=newInst. It's because I changed the NF to define ExternalObject in ModelicaBuiltin, but FBuiltin.getInitialFunctions adds it as a special predefined type before loading ModelicaBuiltin. Unless my fix breaks something it should be fixed when Hudson is finished with my PR.

[Willi Braun]

Ah, indeed, I did not noticed that I used setCommandLineOptions("-d=newInst").
Thanks!

[Francesco Casella]

I confirm that the performance scaling issue only shows up with the NF.

I flattened an N = 2, M = 2 model with the old and new FE and compared them. Apparently , the only difference is in the following statements:

Old FE

  parameter Real primary[1].T(quantity = "ThermodynamicTemperature", unit = "K", displayUnit = "degC", min = 0.0, start = 288.15, nominal = 300.0) = primary[1].T_ref "Fixed device temperature if useHeatPort = false";
  parameter Real primary[2].T(quantity = "ThermodynamicTemperature", unit = "K", displayUnit = "degC", min = 0.0, start = 288.15, nominal = 300.0) = primary[2].T_ref "Fixed device temperature if useHeatPort = false";
  parameter Real secondary[1,1].T(quantity = "ThermodynamicTemperature", unit = "K", displayUnit = "degC", min = 0.0, start = 288.15, nominal = 300.0) = secondary[1,1].T_ref "Fixed device temperature if useHeatPort = false";
  parameter Real secondary[1,2].T(quantity = "ThermodynamicTemperature", unit = "K", displayUnit = "degC", min = 0.0, start = 288.15, nominal = 300.0) = secondary[1,2].T_ref "Fixed device temperature if useHeatPort = false";
  parameter Real secondary[2,1].T(quantity = "ThermodynamicTemperature", unit = "K", displayUnit = "degC", min = 0.0, start = 288.15, nominal = 300.0) = secondary[2,1].T_ref "Fixed device temperature if useHeatPort = false";
  parameter Real secondary[2,2].T(quantity = "ThermodynamicTemperature", unit = "K", displayUnit = "degC", min = 0.0, start = 288.15, nominal = 300.0) = secondary[2,2].T_ref "Fixed device temperature if useHeatPort = false";
  parameter Real load[1,1].T(quantity = "ThermodynamicTemperature", unit = "K", displayUnit = "degC", min = 0.0, start = 288.15, nominal = 300.0) = load[1,1].T_ref "Fixed device temperature if useHeatPort = false";
  parameter Real load[1,2].T(quantity = "ThermodynamicTemperature", unit = "K", displayUnit = "degC", min = 0.0, start = 288.15, nominal = 300.0) = load[1,2].T_ref "Fixed device temperature if useHeatPort = false";
  parameter Real load[2,2].T(quantity = "ThermodynamicTemperature", unit = "K", displayUnit = "degC", min = 0.0, start = 288.15, nominal = 300.0) = load[2,2].T_ref "Fixed device temperature if useHeatPort = false";

New FE:

  parameter Real primary[1].T(quantity = "ThermodynamicTemperature", unit = "K", displayUnit = "degC", min = 0.0, start = 288.15, nominal = 300.0) = primary.T_ref "Fixed device temperature if useHeatPort = false";
  parameter Real primary[2].T(quantity = "ThermodynamicTemperature", unit = "K", displayUnit = "degC", min = 0.0, start = 288.15, nominal = 300.0) = primary.T_ref "Fixed device temperature if useHeatPort = false";
  parameter Real secondary[1,1].T(quantity = "ThermodynamicTemperature", unit = "K", displayUnit = "degC", min = 0.0, start = 288.15, nominal = 300.0) = secondary.T_ref "Fixed device temperature if useHeatPort = false";
  parameter Real secondary[1,2].T(quantity = "ThermodynamicTemperature", unit = "K", displayUnit = "degC", min = 0.0, start = 288.15, nominal = 300.0) = secondary.T_ref "Fixed device temperature if useHeatPort = false";
  parameter Real secondary[2,1].T(quantity = "ThermodynamicTemperature", unit = "K", displayUnit = "degC", min = 0.0, start = 288.15, nominal = 300.0) = secondary.T_ref "Fixed device temperature if useHeatPort = false";
  parameter Real secondary[2,2].T(quantity = "ThermodynamicTemperature", unit = "K", displayUnit = "degC", min = 0.0, start = 288.15, nominal = 300.0) = secondary.T_ref "Fixed device temperature if useHeatPort = false";
  parameter Real load[1,1].T(quantity = "ThermodynamicTemperature", unit = "K", displayUnit = "degC", min = 0.0, start = 288.15, nominal = 300.0) = load.T_ref "Fixed device temperature if useHeatPort = false";
  parameter Real load[1,2].T(quantity = "ThermodynamicTemperature", unit = "K", displayUnit = "degC", min = 0.0, start = 288.15, nominal = 300.0) = load.T_ref "Fixed device temperature if useHeatPort = false";
  parameter Real load[2,1].T(quantity = "ThermodynamicTemperature", unit = "K", displayUnit = "degC", min = 0.0, start = 288.15, nominal = 300.0) = load.T_ref "Fixed device temperature if useHeatPort = false";
  parameter Real load[2,2].T(quantity = "ThermodynamicTemperature", unit = "K", displayUnit = "degC", min = 0.0, start = 288.15, nominal = 300.0) = load.T_ref "Fixed device temperature if useHeatPort = false";

In fact, it is weird that the model can be process at all with the NF, since statements such as

parameter Real load[2,2].T = load.T_ref

have a scalar on the left-hand side and an NxM array on the right-hand side, so they seem incorrect to me from a typing point of view. But maybe the back-end can handle this, only it takes O(N*M) more time to do so, hence the quadratic scaling.

Also by looking at the output of dumpdaelow, it seems this is the only difference.

@perost, could you please have a look at this issue?

[Per Östlund]

Replying to casella:

In fact, it is weird that the model can be process at all with the NF, since statements such as

parameter Real load[2,2].T = load.T_ref

have a scalar on the left-hand side and an NxM array on the right-hand side, so they seem incorrect to me from a typing point of view.

It's actually not weird at all, because the NF does type checking on load.T = load.T_ref. It then fails to correctly subscript the binding when scalarizing the component during the last stages of the NF, so it's the same issue as #4859.

[Per Östlund]

Fixed (embarrassingly easily) in 027dfa4. The bindings are now prefixed properly, and the performance issue in the backend is gone.