Simulation of HeatExchangerSimulation fails

[modelica-trac-importer]

Reported by anonymous on 10 Aug 2015 11:04 UTC
Dymola 2016 fails on Modelica.Fluid.Examples.HeatExchanger.HeatExchangerSimulation of new MSL 3.2.1+build.3 with cyclic parameter bindings and conflicting start values.

Translation of Modelica.Fluid.Examples.HeatExchanger.HeatExchangerSimulation:

The parameter bindings 
HEX.pipe_1.flowModel.m_flow_nominal = (if system.use_eps_Re then system.m_flow_nominal else 100.0*HEX.pipe_1.flowModel.m_flow_small);
HEX.pipe_1.flowModel.m_flow_small = (if system.use_eps_Re then system.eps_m_flow*HEX.pipe_1.flowModel.m_flow_nominal else system.m_flow_small);
are cyclic and that is illegal.

The parameter bindings 
HEX.pipe_2.flowModel.m_flow_small = (if system.use_eps_Re then system.eps_m_flow*HEX.pipe_2.flowModel.m_flow_nominal else system.m_flow_small);
HEX.pipe_2.flowModel.m_flow_nominal = (if system.use_eps_Re then system.m_flow_nominal else 100.0*HEX.pipe_2.flowModel.m_flow_small);
are cyclic and that is illegal.

The DAE has 3731 scalar unknowns and 3731 scalar equations.

Statistics

Original Model
Number of components: 277
Variables: 2315
Constants: 56 (56 scalars)
Parameters: 345 (624 scalars)
Unknowns: 1914 (3735 scalars)
Differentiated variables: 180 scalars
Equations: 902
Nontrivial: 612

Translated Model
Constants: 1194 scalars
Free parameters: 33 scalars
Parameter depending: 265 scalars
Continuous time states: 100 scalars
Time-varying variables: 1125 scalars
Alias variables: 1798 scalars
Number of mixed real/discrete systems of equations: 0
Sizes of linear systems of equations: {2, 3, 2, 3, 2, 3, 2, 3, 2, 3, 2, 3, 2, 2, 2, 2, 2, 2, 3, 2, 2, 3, 2, 2, 3, 2, 3, 2, 3, 2, 3, 2, 3, 2, 2, 3, 2, 2, 3, 2, 2, 3, 2, 3, 2, 2, 2, 2, 2, 2, 2, 2, 3, 2, 3, 3, 3, 3, 2, 2, 3, 3, 3, 2, 3, 2, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3}
Sizes after manipulation of the linear systems: {0, 2, 0, 2, 0, 2, 0, 2, 0, 2, 0, 2, 0, 0, 0, 0, 0, 0, 2, 0, 0, 2, 0, 0, 2, 0, 2, 0, 2, 0, 2, 0, 2, 0, 0, 2, 0, 0, 2, 0, 0, 2, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 2, 0, 2, 2, 2, 2, 0, 0, 2, 2, 2, 0, 2, 0, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2}
Sizes of nonlinear systems of equations: { }
Sizes after manipulation of the nonlinear systems: { }
Number of numerical Jacobians: 0

Initialization problem
Sizes of linear systems of equations: {2, 2, 2, 2}
Sizes after manipulation of the linear systems: {0, 0, 0, 0}
Sizes of nonlinear systems of equations: {724}
Sizes after manipulation of the nonlinear systems: {160}
Number of numerical Jacobians: 1

Selected continuous time states

Statically selected continuous time states
HEX.pipe_1.mediums[1].p
HEX.pipe_1.mediums[1].T
HEX.pipe_1.mediums[2].p
HEX.pipe_1.mediums[2].T
HEX.pipe_1.mediums[3].p
HEX.pipe_1.mediums[3].T
HEX.pipe_1.mediums[4].p
HEX.pipe_1.mediums[4].T
HEX.pipe_1.mediums[5].p
HEX.pipe_1.mediums[5].T
HEX.pipe_1.mediums[6].p
HEX.pipe_1.mediums[6].T
HEX.pipe_1.mediums[7].p
HEX.pipe_1.mediums[7].T
HEX.pipe_1.mediums[8].p
HEX.pipe_1.mediums[8].T
HEX.pipe_1.mediums[9].p
HEX.pipe_1.mediums[9].T
HEX.pipe_1.mediums[10].p
HEX.pipe_1.mediums[10].T
HEX.pipe_1.mediums[11].p
HEX.pipe_1.mediums[11].T
HEX.pipe_1.mediums[12].p
HEX.pipe_1.mediums[12].T
HEX.pipe_1.mediums[13].p
HEX.pipe_1.mediums[13].T
HEX.pipe_1.mediums[14].p
HEX.pipe_1.mediums[14].T
HEX.pipe_1.mediums[15].p
HEX.pipe_1.mediums[15].T
HEX.pipe_1.mediums[16].p
HEX.pipe_1.mediums[16].T
HEX.pipe_1.mediums[17].p
HEX.pipe_1.mediums[17].T
HEX.pipe_1.mediums[18].p
HEX.pipe_1.mediums[18].T
HEX.pipe_1.mediums[19].p
HEX.pipe_1.mediums[19].T
HEX.pipe_1.mediums[20].p
HEX.pipe_1.mediums[20].T
HEX.pipe_2.mediums[1].p
HEX.pipe_2.mediums[1].T
HEX.pipe_2.mediums[2].p
HEX.pipe_2.mediums[2].T
HEX.pipe_2.mediums[3].p
HEX.pipe_2.mediums[3].T
HEX.pipe_2.mediums[4].p
HEX.pipe_2.mediums[4].T
HEX.pipe_2.mediums[5].p
HEX.pipe_2.mediums[5].T
HEX.pipe_2.mediums[6].p
HEX.pipe_2.mediums[6].T
HEX.pipe_2.mediums[7].p
HEX.pipe_2.mediums[7].T
HEX.pipe_2.mediums[8].p
HEX.pipe_2.mediums[8].T
HEX.pipe_2.mediums[9].p
HEX.pipe_2.mediums[9].T
HEX.pipe_2.mediums[10].p
HEX.pipe_2.mediums[10].T
HEX.pipe_2.mediums[11].p
HEX.pipe_2.mediums[11].T
HEX.pipe_2.mediums[12].p
HEX.pipe_2.mediums[12].T
HEX.pipe_2.mediums[13].p
HEX.pipe_2.mediums[13].T
HEX.pipe_2.mediums[14].p
HEX.pipe_2.mediums[14].T
HEX.pipe_2.mediums[15].p
HEX.pipe_2.mediums[15].T
HEX.pipe_2.mediums[16].p
HEX.pipe_2.mediums[16].T
HEX.pipe_2.mediums[17].p
HEX.pipe_2.mediums[17].T
HEX.pipe_2.mediums[18].p
HEX.pipe_2.mediums[18].T
HEX.pipe_2.mediums[19].p
HEX.pipe_2.mediums[19].T
HEX.pipe_2.mediums[20].p
HEX.pipe_2.mediums[20].T
HEX.wall.T[1]
HEX.wall.T[2]
HEX.wall.T[3]
HEX.wall.T[4]
HEX.wall.T[5]
HEX.wall.T[6]
HEX.wall.T[7]
HEX.wall.T[8]
HEX.wall.T[9]
HEX.wall.T[10]
HEX.wall.T[11]
HEX.wall.T[12]
HEX.wall.T[13]
HEX.wall.T[14]
HEX.wall.T[15]
HEX.wall.T[16]
HEX.wall.T[17]
HEX.wall.T[18]
HEX.wall.T[19]
HEX.wall.T[20]

Conflicting start values

A set of alias variables having conflicting start values of the same precedence
0.2, the start value of HEX.pipe_1.m_flows[21] given as 0.2.
0.2, the start value of HEX.pipe_1.flowModel.m_flows[20] given as 0.2.

A set of alias variables having conflicting start values of the same precedence
5000000.0, the start value of massFlowRate1.ports[1].p given as 5000000.0.
101325.0, the start value of HEX.pipe_1.mediums[1].p given as HEX.pipe_1.ps_start[1].

A set of alias variables having conflicting start values of the same precedence
5000000.0, the start value of massFlowRate2.ports[1].p given as 5000000.0.
101325.0, the start value of HEX.pipe_2.mediums[20].p given as HEX.pipe_2.ps_start[20].

A set of alias variables having conflicting start values of the same precedence
5000000.0, the start value of massFlowRate1.ports[1].p given as 5000000.0.
101325.0, the start value of HEX.pipe_1.mediums[1].p given as HEX.pipe_1.ps_start[1].

A set of alias variables having conflicting start values of the same precedence
5000000.0, the start value of massFlowRate2.ports[1].p given as 5000000.0.
101325.0, the start value of HEX.pipe_2.mediums[20].p given as HEX.pipe_2.ps_start[20].

A set of alias variables having conflicting start values of the same precedence
5000000.0, the start value of massFlowRate1.ports[1].p given as 5000000.0.
101325.0, the start value of HEX.pipe_1.mediums[1].p given as HEX.pipe_1.ps_start[1].

A set of alias variables having conflicting start values of the same precedence
5000000.0, the start value of massFlowRate2.ports[1].p given as 5000000.0.
101325.0, the start value of HEX.pipe_2.mediums[20].p given as HEX.pipe_2.ps_start[20].

A set of alias variables having conflicting start values of the same precedence
5000000.0, the start value of massFlowRate1.ports[1].p given as 5000000.0.
101325.0, the start value of HEX.pipe_1.mediums[1].p given as HEX.pipe_1.ps_start[1].

A set of alias variables having conflicting start values of the same precedence
5000000.0, the start value of massFlowRate2.ports[1].p given as 5000000.0.
101325.0, the start value of HEX.pipe_2.mediums[20].p given as HEX.pipe_2.ps_start[20].

A set of alias variables having conflicting start values of the same precedence
5000000.0, the start value of massFlowRate1.ports[1].p given as 5000000.0.
101325.0, the start value of HEX.pipe_1.mediums[1].p given as HEX.pipe_1.ps_start[1].

A set of alias variables having conflicting start values of the same precedence
5000000.0, the start value of massFlowRate2.ports[1].p given as 5000000.0.
101325.0, the start value of HEX.pipe_2.mediums[20].p given as HEX.pipe_2.ps_start[20].

A set of alias variables having conflicting start values of the same precedence
5000000.0, the start value of massFlowRate1.ports[1].p given as 5000000.0.
101325.0, the start value of HEX.pipe_1.mediums[1].p given as HEX.pipe_1.ps_start[1].

A set of alias variables having conflicting start values of the same precedence
5000000.0, the start value of massFlowRate2.ports[1].p given as 5000000.0.
101325.0, the start value of HEX.pipe_2.mediums[20].p given as HEX.pipe_2.ps_start[20].

A set of alias variables having conflicting start values of the same precedence
5000000.0, the start value of massFlowRate1.ports[1].p given as 5000000.0.
101325.0, the start value of HEX.pipe_1.mediums[1].p given as HEX.pipe_1.ps_start[1].

A set of alias variables having conflicting start values of the same precedence
5000000.0, the start value of massFlowRate2.ports[1].p given as 5000000.0.
101325.0, the start value of HEX.pipe_2.mediums[20].p given as HEX.pipe_2.ps_start[20].

A set of alias variables having conflicting start values of the same precedence
101325.0, the start value of HEX.pipe_1.mediums[1].p given as HEX.pipe_1.ps_start[1].
5000000.0, the start value of massFlowRate1.ports[1].p given as 5000000.0.

A set of alias variables having conflicting start values of the same precedence
101325.0, the start value of HEX.pipe_2.mediums[20].p given as HEX.pipe_2.ps_start[20].
5000000.0, the start value of massFlowRate2.ports[1].p given as 5000000.0.

A set of alias variables having conflicting start values of the same precedence
5000000.0, the start value of massFlowRate1.ports[1].p given as 5000000.0.
101325.0, the start value of HEX.pipe_1.mediums[1].p given as HEX.pipe_1.ps_start[1].

A set of alias variables having conflicting start values of the same precedence
5000000.0, the start value of massFlowRate2.ports[1].p given as 5000000.0.
101325.0, the start value of HEX.pipe_2.mediums[20].p given as HEX.pipe_2.ps_start[20].

A set of alias variables having conflicting start values of the same precedence
5000000.0, the start value of massFlowRate1.ports[1].p given as 5000000.0.
101325.0, the start value of HEX.pipe_1.mediums[1].p given as HEX.pipe_1.ps_start[1].

A set of alias variables having conflicting start values of the same precedence
5000000.0, the start value of massFlowRate2.ports[1].p given as 5000000.0.
101325.0, the start value of HEX.pipe_2.mediums[20].p given as HEX.pipe_2.ps_start[20].

A set of alias variables having conflicting start values of the same precedence
101325.0, the start value of HEX.pipe_1.mediums[1].p given as HEX.pipe_1.ps_start[1].
5000000.0, the start value of massFlowRate1.ports[1].p given as 5000000.0.

A set of alias variables having conflicting start values of the same precedence
101325.0, the start value of HEX.pipe_2.mediums[20].p given as HEX.pipe_2.ps_start[20].
5000000.0, the start value of massFlowRate2.ports[1].p given as 5000000.0.

Error detected when generating code.

Translation aborted.

ERROR: 3 errors were found

---

Migrated-From: https://trac.modelica.org/Modelica/ticket/1758

[modelica-trac-importer]

Comment by dietmarw on 10 Aug 2015 15:17 UTC
I can confirm this and it is rather worrying that actually the pedantic check finds the following models that fail with Dymola 2016 for the same reason:

Simulations failed for:
Modelica.Mechanics.MultiBody.Examples.Loops.Fourbar2
Modelica.Fluid.Examples.PumpingSystem
Modelica.Fluid.Examples.HeatingSystem
Modelica.Fluid.Examples.DrumBoiler.DrumBoiler
Modelica.Fluid.Examples.Tanks.ThreeTanks
Modelica.Fluid.Examples.Tanks.TanksWithOverflow
Modelica.Fluid.Examples.Tanks.EmptyTanks
Modelica.Fluid.Examples.ControlledTankSystem.ControlledTanks
Modelica.Fluid.Examples.AST_BatchPlant.BatchPlant_StandardWater
Modelica.Fluid.Examples.AST_BatchPlant.Test.OneTank
Modelica.Fluid.Examples.AST_BatchPlant.Test.TwoTanks
Modelica.Fluid.Examples.AST_BatchPlant.Test.TankWithEmptyingPipe1
Modelica.Fluid.Examples.AST_BatchPlant.Test.TankWithEmptyingPipe2
Modelica.Fluid.Examples.AST_BatchPlant.Test.TanksWithEmptyingPipe1
Modelica.Fluid.Examples.AST_BatchPlant.Test.TanksWithEmptyingPipe2
Modelica.Fluid.Examples.IncompressibleFluidNetwork
Modelica.Fluid.Examples.BranchingDynamicPipes
Modelica.Fluid.Examples.NonCircularPipes
Modelica.Fluid.Examples.HeatExchanger.HeatExchangerSimulation
Modelica.Fluid.Examples.TraceSubstances.RoomCO2
Modelica.Fluid.Examples.TraceSubstances.RoomCO2WithControls
Modelica.Fluid.Examples.InverseParameterization

This raises the question what "check" was actually done with Dymola 2016 (as stated in the release notes) and really needs to be fixed as quickly as possible. Are there any Test logs available from when the original test of build.3 is documented?

[modelica-trac-importer]

Modified by dietmarw on 10 Aug 2015 15:22 UTC

[modelica-trac-importer]

Comment by leo.gall on 10 Aug 2015 16:17 UTC
This is no new problem. If pedantic mode is disabled, the model works without problems.
Unfortunately it hasn't been escalated and fixed for the new build.

The same error message exists in:

• Dymola 2016 + MSL 3.2.1+build.2
• Dymola 2014 FD01 + MSL 3.2.1+build.2

Regression tests focused on finding differences to MSL 3.2.1+build.2, these are documented in #1681 (based on MSL v3.2.1+build.3-rc1 Dymola 2014 FD01). Models have been simulated in Dymola 2014 FD01 with Advanced.PedanticModelica := false. This was obviously a bad idea, the next regression test should be performed with Advanced.PedanticModelica := true. For comparing simulation results it was good enough.

I do not know, if library officers or tool vendors ran checks / pedantic checks before release.

[modelica-trac-importer]

Comment by dietmarw on 11 Aug 2015 06:34 UTC
I forgot to mention that for the build.2 release it was taken care that the all errors also of pedantic check (at the time) were fixed. See #799. That was supposed to be the standard for any release.

[modelica-trac-importer]

Comment by leo.gall on 11 Aug 2015 06:44 UTC
Replying to [comment:4 dietmarw]:

I forgot to mention that for the build.2 release it was taken care that the all errors also of pedantic check (at the time) were fixed. See #799. That was supposed to be the standard for any release.

I agree, this should be the standard.

For #799, probably Dymola 2014 was used.
I tried MSL 3.2.1+build.3 in Dymola 2014: Pedantic check didn't mention the problem reported in this ticket (that's why it hasn't been fixed recognized for the initial release of MSL 3.2.1). So, as pedantic check gets updated with newer versions of Dymola, the results have to be re-evaluated.

[modelica-trac-importer]

Comment by dietmarw on 11 Aug 2015 06:59 UTC
Well yes but the release notes explicitly state it was tested using Dymola 2016.

[modelica-trac-importer]

Comment by anonymous on 11 Aug 2015 07:05 UTC
Replying to [comment:3 leo.gall]:

The same error message exists in:

• Dymola 2016 + MSL 3.2.1+build.2
• Dymola 2014 FD01 + MSL 3.2.1+build.2

That is not exactly true.

1. Dymola 2014 FD01 with MSL 3.2.1+build.2 in non-pedantic mode does not raise warnings about conflicting start values of Fourbar2 or HeatExchangerSimulation.
2. Dymola 2016 with both MSL 3.2.1+build.2 and MSL 3.2.1+build.3 in non-pedantic mode raises a warning about conflicting start values of HeatExchangerSimulation.
3. Dymola 2016 with MSL 3.2.1+build.3 in non-pedantic mode raises a warning about conflicting start values of Fourbar2.
   Thus when checking build.3 with Dymola 2016 these conflicting start values that now again violate Complete definition of initialisation of executable models #799 should have been discovered.

[modelica-trac-importer]

Comment by leo.gall on 11 Aug 2015 07:23 UTC
We have to find out which tests have been performed in Dymola 2016 (by tool vendor or MAP-LIB).

The goal of MA regression testing was to prevent unwanted changes in simulation results. Therefore, Dymola 2014 FD01 was used in order to not change to many variables at once (simulator version, library version).

I totally agree, that there should be a final release check in the newest simulator versions (by tool vendors or library officers). If this was not done, the release notes would be wrong and we clearly have to improve the release process.

[modelica-trac-importer]

Comment by hansolsson on 17 Aug 2015 08:15 UTC
I believe I can understand why this slipped by: the test with Dymola 2016 was done with Pedantic=false; and warnings were not considered blocking.

The e-mail sent after the testing was clear on that:
"
It has been checked with Dymola 2016.

(Without enabling Pedantic flag. Dymola 2016 FD01 should pass it also with Pedantic=true.)

The only issues found are reported for ModelicaTest in https://trac.modelica.org/Modelica/ticket/1740 "

From my perspective that was important - so that a new library could be downloaded and used in that version. The problem with cycles was detected, but not seen as a library problem at that time (see below). I don't recall the issue with start-values and will have to look at it again.
Added: I have analyzed it a bit - and the problem is not that severe as far as I can see. Basically the different start-values seems to be different guess-values for the initialization, i.e. the choice may influence the simulation result whereas different choices for states (as previously reported and corrected) will influence the simulation result. It's not ideal - but less problematic.

However, the situation regarding cyclic bindings was worse that I thought:
The problem for this model was first reported in October 2013 in https://trac.modelica.org/Modelica/ticket/1320
and was resolved in December 2013.
MSL 3.2.1 should be based on Modelica Spec 3.2r2 released in July 2013, which does not allow parameters with Evaluate=true to break cycles.

[modelica-trac-importer]

Comment by hansolsson on 17 Aug 2015 12:43 UTC
Replying to [comment:1 dietmarw]:

I can confirm this and it is rather worrying that actually the pedantic check finds the following models that fail with Dymola 2016 for the same reason:

I have now looked once more at them. Note that they only fail if pedantic checks are enabled.

The following are due to problems with cyclic parameter bindings which cannot be corrected with Modelica 3.2r2 semantics as far as I can see:
Modelica.Fluid.Examples.PumpingSystem
Modelica.Fluid.Examples.HeatingSystem
Modelica.Fluid.Examples.Tanks.ThreeTanks
Modelica.Fluid.Examples.Tanks.TanksWithOverflow
Modelica.Fluid.Examples.Tanks.EmptyTanks
Modelica.Fluid.Examples.ControlledTankSystem.ControlledTanks
Modelica.Fluid.Examples.AST_BatchPlant.BatchPlant_StandardWater (and all other AST_BatchPlant)
Modelica.Fluid.Examples.IncompressibleFluidNetwork
Modelica.Fluid.Examples.BranchingDynamicPipes
Modelica.Fluid.Examples.NonCircularPipes
Modelica.Fluid.Examples.HeatExchanger.HeatExchangerSimulation
Modelica.Fluid.Examples.TraceSubstances.RoomCO2
Modelica.Fluid.Examples.TraceSubstances.RoomCO2WithControls
Modelica.Fluid.Examples.InverseParameterization

Since this problem also occurred in previous builds of MSL 3.2.1 I cannot see that we can correct it in MSL 3.2.1 without introducing incompatibilities for users. The best we could do would be to document the issue, unless we want to create a 3.2r3 specification just to correct this.

The following are start-value warnings that are non-blocking for the release of MSL:
Modelica.Mechanics.MultiBody.Examples.Loops.Fourbar2: No issue
Modelica.Fluid.Examples.HeatingSystem: Conflicting start values have no impact for this simulation
Modelica.Fluid.Examples.DrumBoiler.DrumBoiler: Conflicting start values have no impact for this simulation
Modelica.Fluid.Examples.AST_BatchPlant.BatchPlant_StandardWater (but not others in AST): Conflicting start values have no impact for this simulation
Modelica.Fluid.Examples.IncompressibleFluidNetwork: Conflicting start values have no impact for this simulation
Modelica.Fluid.Examples.BranchingDynamicPipes: Conflicting start values have no impact for this simulation
Modelica.Fluid.Examples.NonCircularPipes: No issue
Modelica.Fluid.Examples.HeatExchanger.HeatExchangerSimulation: No issue
Modelica.Fluid.Examples.TraceSubstances.RoomCO2: No issue
Modelica.Fluid.Examples.TraceSubstances.RoomCO2WithControls: No issue
The non-issue are so minor that we will no longer report them at all.

The reason they are non-blocking for the release of MSL is that none of them concern conflicting start-values for continuous state variables. There also seems to be other issues these diagnostics: the same error occurs more than once. Obviously we have worked on improving the diagnostics for future Dymola releases.

[modelica-trac-importer]

Comment by fcasella on 24 Sep 2015 12:45 UTC
The text of MS 3.2r2 says, 4.4.3.

The binding equations for parameters and constants in the translated model must be
acyclic after flattening.

According to this, the cyclic dependencies should be looked for after flattening, and if that is done, there is in fact no dependency at all in the cited example models, as one of the two potentially involved binding equations is changed to a specific numerical value by a modifier when instantiating the components. So, there is really no issue about this in MSL 3.2.1.

There might be problems when checking the class alone, as both default bindings are still presente, and this is covered by the improvements of MS 3.3r1 by evaluating the boolean parameters, but this is outside the scope of this ticket.

As to the conflicting start values, first of all this concept has been introduced in Modelica 3.3, so it doesn't apply for MSL 3.2.1. Besides, the text of section 8.6.2 by no means implies that having conflicting start attributes on aliases with the same priority is by any means illegal - in fact the suggested procedure is non-normative. A warning might be issued, but this is definitely not an error.

[modelica-trac-importer]

Comment by hansolsson on 24 Sep 2015 13:03 UTC
Replying to [comment:11 fcasella]:

The text of MS 3.2r2 says, 4.4.3.

The binding equations for parameters and constants in the translated model must be
acyclic after flattening.

According to this, the cyclic dependencies should be looked for after flattening, and if that is done, there is in fact no dependency at all in the cited example models, as one of the two potentially involved binding equations is changed to a specific numerical value by a modifier when instantiating the components. So, there is really no issue about this in MSL 3.2.1.

Flattening just resolves modifiers and names; it does not evaluate parameters as is needed here. That was why #1320 was needed.

The reason for having the restriction after flattening is that someone can use:

model A
  parameter Integer nm=size(M,1);
  parameter Real M[:]=zeros(nm);
end A;
A a(nm=2);
A a2(M={1,2});

(or likely using it in a better way).

As to the conflicting start values, first of all this concept has been introduced in Modelica 3.3, so it doesn't apply for MSL 3.2.1. Besides, the text of section 8.6.2 by no means implies that having conflicting start attributes on aliases with the same priority is by any means illegal - in fact the suggested procedure is non-normative. A warning might be issued, but this is definitely not an error.

I agree that there is no issue for the start-values.
(And we have improved the diagnostics for the coming Dymola release.)

[modelica-trac-importer]

Comment by fcasella on 24 Sep 2015 13:26 UTC
You are right, my previous comment resolves the issue for the temperature/enthalpy parameters with cross-references, but it leaves open the one involving m_flow_nominal and m_flow_small. I'll look more into it.

[modelica-trac-importer]

Comment by fcasella on 24 Sep 2015 21:06 UTC
We looked more carefully into the issue. It involves Modelica.Fluid.Pipes.BaseClasses.FlowModels.DetailedPipeFlow, which contains the following default bindings.

m_flow_small =
 (if system.use_eps_Re 
  then system.eps_m_flow*m_flow_nominal
  else system.m_flow_small);
m_flow_nominal =
  (if system.use_eps_Re
   then system.m_flow_nominal
   else 100.0*m_flow_small);

As no modifiers are applied to these parameters when the model is instantiated in those examples, there is a potential circular dependency, if one just looks at the incidence matrix.

However, if one looks carefully, conditions are mutually exclusive, so in fact there is never any circular dependency to be worried about. A tool could determine this easily by applying the rules defined in MS 3.3r1, i.e., evaluating use_eps_Re and then applying symbolic simplification, but we can't rely on a later version of the language for MSL 3.2.1.

Anyway, by careful analysis we know there is actually no cyclic dependency here, so the model can never lead to implicit equations to determine parameters, and there will be no problem at all generating the code. The rule of MS 3.2r2 (The binding equations for parameters and constants in the translated model must be acyclic after flattening) indeed applies here, though tools usually do not employ sophisticated enough techniques to detect this.

It is impossible to change the source code to eliminate the problem at the root, unless we introduce a backwards-incompatible change in the library. As many other libraries (including the Buildings library, which has a large user base) depend on this component, and the consequences of such a change might be significantly bad, we think we have a very strong argument in favour of not doing so.

The conclusion after discussion at the 87th Design Meeting in Velizy is to keep this code in MSL 3.2.1 and add the following text to the release notes:

The model Modelica.Fluid.Pipes.BaseClasses.FlowModels.DetailedPipeFlow contains two
parameter binding equations for the parameters m_flow_small and m_flow_nominal which
might seem cyclically dependent, based on a pure incidence analysis. A more careful
analysis reveals that there is actually no cyclic dependency, so the model is
legal. Furthermore, as soon as the parameter system.use_eps_Re is evaluated after
flattening due to the Evaluate = true annotation, also the structural cyclic
dependency disappears.

[modelica-trac-importer]

Modified by fcasella on 24 Sep 2015 21:07 UTC

[modelica-trac-importer]

Comment by beutlich on 24 Sep 2015 21:55 UTC
Thanks for clarification.

Should we Keep the ticket open as long as it is not in the release notes?

[modelica-trac-importer]

Comment by fcasella on 24 Sep 2015 23:09 UTC
Sure, sorry, I forgot about that. Toni can close it when the release notes are updated.

[modelica-trac-importer]

Modified by fcasella on 24 Sep 2015 23:10 UTC

[modelica-trac-importer]

Comment by otter on 28 Sep 2015 11:32 UTC
Fixed in 0e51d82 (maintenance branch) by documenting this decision in the release notes of build 4 in the following way:

Ticket #1758 states that simulation of Modelica.Fluid.Examples.HeatingSystem fails in Dymola 2016 if option "pedantic mode for checking Modelica semantics" is set. This issue was not fixed in the library due to the following reasons:

The Modelica.Fluid library uses a particular pattern to define some parameters resulting in a cyclic dependency of parameters if only incident information is taken into account. According to Modelica Specification 3.2 revision 2 this is not allowed (and therefore Dymola 2016 correctly reports errors if the pedantic flag is set). In ticket #1320 this issue was resolved for Modelica Specification 3.3 revision 1 by allowing cyclic parameter definitions if the cycles disappear when evaluating parameters that have annotation Evaluate=true. Modelica.Fluid is correct with respect to Modelica Specification 3.3 revision 1. Changing the Modelica.Fluid library for build 4 so that no cyclic parameter dependencies would be present anymore would (a) result in a non-backwards compatible change and (b) make the usage of Modelica.Fluid less convenient. For this reason Modelica.Fluid is not changed. (Practically, this means for example that the pedantic flag in Dymola 2016 needs to be switched off, when using the Modelica.Fluid library in version 3.2.1 build 4 and any previous version).

[modelica-trac-importer]

Modified by otter on 28 Sep 2015 11:54 UTC

[modelica-trac-importer]

Changelog modified by otter on 28 Sep 2015 11:54 UTC
Explained in the release notes of build 4, why Modelica.Fluid is not changed (and pedantic flag should not be activated with Dymola 2016)

[modelica-trac-importer]

Comment by fcasella on 28 Sep 2015 13:02 UTC
Replying to [comment:19 otter]:

Fixed in 0e51d82 (maintenance branch) by documenting this decision in the release notes of build 4 in the following way:

Ticket #1758 states that simulation of Modelica.Fluid.Examples.HeatingSystem fails in Dymola 2016 if option "pedantic mode for checking Modelica semantics" is set. This issue was not fixed in the library due to the following reasons:

The Modelica.Fluid library uses a particular pattern to define some parameters resulting in a cyclic dependency of parameters if only incident information is taken into account. According to Modelica Specification 3.2 revision 2 this is not allowed (and therefore Dymola 2016 correctly reports errors if the pedantic flag is set).

For the record, the Modelica Specification 3.2 revision 2 only requires that the translated model must be acyclic, but it doesn't say that this should be checked with incidence information only. So, IMHO the model is perfectly legal according to the specification, as it never leads to cyclical dependencies for any value of the parameters. It is just a tool issue if this is not detected properly.