search

modelica / ModelicaStandardLibrary

Free (standard conforming) library to model mechanical (1D/3D), electrical (analog, digital, machines), magnetic, thermal, fluid, control systems and hierarchical state machines. Also numerical functions and functions for strings, files and streams are included.
https://doc.modelica.org
BSD 3-Clause "New" or "Revised" License
452 stars 165 forks source link

Release plan for MSL 3.2.2 #1867

Closed modelica-trac-importer closed 7 years ago

modelica-trac-importer commented 7 years ago

Reported by ahaumer on 18 Dec 2015 11:44 UTC In a web-/phone-conference today a smaller working group developed the release plan for MSl 3.2.2:

  1. Dec. 23, 2015: Feature Freeze. Trunk is tagged as MSL 3.2.2 Alpha.1

  2. All tool vendors should check MSL

  3. Fix remaining tickets for Milestone 3.2.2 (also documentation can still be improved)

  4. If new models of MSL 3.2.2 Alpha.1 have no meaningful continuous-time states, then the authors of these models have to provide meaningful variables as outputs on the top level, provided there are no or no meaningful continuous-time states (for example: “output Real noise_a = noise.a”). This change should be performed before the “freeze” (on Dec. 23, 2015) for: Magnetic.QuasiStatic.FundamentalWave (Anton Haumer, Christian Kral) Blocks.Examples.NoiseExamples (Martin Otter) Tables in ModelicaTest (Thomas Beutlich) If there are other authors of such new models, they should check this.

  5. Jan. 12, 2016: Trunk is tagged as MSL 3.2.2 Beta.1

  6. Contract: Generate reference results for MSL 3.2.1 with Dymola 2014 FD01 (the regression testing of MSL 3.2.1 was performed with this Dymola version).

  7. Contract: Regression testing of MSL 3.2.2 Beta.1 with Dymola 2016 FD01 with respect to reference results of MSL 3.2.1. This tests whether there is a regression of MSL 3.2.2 Beta.1 with respect to MSL 3.2.1 and at the same time, whether Dymola 2016 FD01 still produces the same results as Dymola 2014 FD01.

  8. Jan. 29, 2016: Contract: The simulations results of MSL 3.2.2 Beta.1 are provided as new reference results (including newly added models).

  9. Contract: A list of models that do not fulfill the regression tests are provided in a new ticket.

  10. The authors of these models have to fix the models or provide an explanation for the regression.

  11. All tool vendors should check MSL

  12. Feb. 19, 2016: A release candidate is provided (MSL 3.2.2 RC.1)

  13. Contract: Regression testing of MSL 3.2.2 RC.1 with Dymola 2016 FD01 with respect to reference results of MSL 3.2.1. If there are regression errors, it is checked whether all of them are explained in the ticket that this is correct. The simulation results are provided as new reference results of MSL 3.2.2.

  14. March 4, 2016: Electronic voting starts for this release by the MAP “Modelica Libraries” members.

  15. March 11, 2016: MSL 3.2.2 is released.

Leo Gall is proposed to provide a quote for the items marked as “contract”. The MA Board checks and decides whether this contract is given to Leo Gall. (Leo Gall made the last regression tests for MSL 3.2.1 as a contract; if an open call would be made, the release of MSL would be delayed by at least 2 months. How to organize this in the future, should be discussed at the next Modelica Design Meeting, March 4-6).

If there are issues, please comment in this ticket.

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

modelica-trac-importer commented 7 years ago

Modified by ahaumer on 18 Dec 2015 11:57 UTC

modelica-trac-importer commented 7 years ago

Comment by beutlich on 21 Dec 2015 10:03 UTC Leo, please find all comparisonSignals.txt of ModelicaTest.Tables attached in attachment:T1867_ModelicaTest.Tables.zip.

modelica-trac-importer commented 7 years ago

Modified by beutlich on 21 Dec 2015 15:13 UTC

modelica-trac-importer commented 7 years ago

Comment by beutlich on 23 Dec 2015 20:44 UTC Please note that the release notes of the MSL 3.2.1 maintenance branch should also be part of the MSL 3.2.2 trunk (release). See especially the documents DifferencesTo3.2.1+build.2.html, DifferencesTo3.2.1+build.3.html, ResolvedTracTickets-build-3.html and ResolvedTracTickets-build-4.html from the documentation of the maintenance branch.

modelica-trac-importer commented 7 years ago

Comment by jmattsson on 11 Jan 2016 14:42 UTC We are having some problems with the following new MSL models in JModelica.org:

We get the error message:

A when-guard is involved in an algebraic loop, consider breaking it using pre() expressions

for the equation:

    when u then
      entryTime = time;
    end when;

in pulse2m.twomPulse.timerPositive[3] (a Modelica.Blocks.Logical.Timer).

It is unclear to me if this indicates a problem in the model or a limitation in JModelica.org.

modelica-trac-importer commented 7 years ago

Comment by beutlich on 11 Jan 2016 15:06 UTC This is what SimulationX issues

Error In Modelica.Electrical.PowerConverters.Examples.ACDC.RectifierBridge2mPulse.HalfControlledBridge2mPulse
The conditions:
(if _pulse2m.twomPulse.timerPositive._b_4 then not _pre__pulse2m.twomPulse.timerPositive._b_4 else false)
(if _pulse2m.twomPulse.timerPositive._b_3 then not _pre__pulse2m.twomPulse.timerPositive._b_3 else false)
(if _pulse2m.twomPulse.timerPositive._b then not _pre__pulse2m.twomPulse.timerPositive._b else false)
 of the following when-clauses depends on the unknowns of the same algebraic loop:
when(if _pulse2m.twomPulse.timerPositive._b_4 then not _pre__pulse2m.twomPulse.timerPositive._b_4 else false)then
    pulse2m.twomPulse.timerPositive.entryTime[3]=time;
end when;
when(if _pulse2m.twomPulse.timerPositive._b_3 then not _pre__pulse2m.twomPulse.timerPositive._b_3 else false)then
    pulse2m.twomPulse.timerPositive.entryTime[2]=time;
end when;
when(if _pulse2m.twomPulse.timerPositive._b then not _pre__pulse2m.twomPulse.timerPositive._b else false)then
    pulse2m.twomPulse.timerPositive.entryTime[1]=time;
end when;
You may be able to cut the dependency by using "pre(...)" around the references in the when-condition.
Message: Modelica.WhenConditionDependsFromLoop

Warning In Modelica.Electrical.PowerConverters.Examples.ACDC.RectifierBridge2mPulse.HalfControlledBridge2mPulse
The following when-clauses are part of an algebraic loop. They are evaluated more than once because of the solution algorithm:
when if _pulse2m.twomPulse.timerPositive._b then not _pre__pulse2m.twomPulse.timerPositive._b else false then
    pulse2m.twomPulse.timerPositive.entryTime[1]=time;
end when;
when if _pulse2m.twomPulse.timerPositive._b_3 then not _pre__pulse2m.twomPulse.timerPositive._b_3 else false then
    pulse2m.twomPulse.timerPositive.entryTime[2]=time;
end when;
when if _pulse2m.twomPulse.timerPositive._b_4 then not _pre__pulse2m.twomPulse.timerPositive._b_4 else false then
    pulse2m.twomPulse.timerPositive.entryTime[3]=time;
end when;.
Message: Modelica.WhenInAlgebraicLoop
modelica-trac-importer commented 7 years ago

Comment by ahaumer on 12 Jan 2016 15:57 UTC Please have look at #1876: The new formulation of the limiter-block did break the model! The example works fine with the old limiter-block.

modelica-trac-importer commented 7 years ago

Comment by otter on 12 Jan 2016 17:53 UTC Replying to [comment:5 jmattsson]:

We are having some problems with the following new MSL models in JModelica.org: * HalfControlledBridge2mPulse * ThyristorBridge2mPulse_R * ThyristorBridge2mPulse_RL * ThyristorBridge2mPulse_RLV * ThyristorBridge2mPulse_RLV_Characteristic within Modelica.Electrical.PowerConverters.Examples.ACDC.RectifierBridge2mPulse.

...

Sorry, this is fixed in 576b8f6dc58be31baf47be9ceb83da8752f6aa5a by correcting an error in Limiter, VariableLimiter and DeadZone that was introduced when improving these components (the "simplified" argument of the homotopy operator was wrongly referencing y instead of u). instead of u).

modelica-trac-importer commented 7 years ago

Comment by otter on 12 Jan 2016 18:22 UTC Replying to [comment:4 beutlich]:

Please note that the release notes of the MSL 3.2.1 maintenance branch should also be part of the MSL 3.2.2 trunk (release). See especially the documents DifferencesTo3.2.1+build.2.html, DifferencesTo3.2.1+build.3.html, ResolvedTracTickets-build-3.html and ResolvedTracTickets-build-4.html from the documentation of the maintenance branch.

Fixed in fb39c3eb96d4cf3ac903c3541c86cf990342adb2: Added the "ResolvedTracTickets" of 3.2.1 build.3 and build.4 and copied also the descriptions of the release notes from these releases into the release notes of 3.2.2. I will make one diff between 3.2.2 and 3.2.1 build.2 as the very last action (it makes no sense to include the diffs from build.3/.4).

modelica-trac-importer commented 7 years ago

Comment by otter on 13 Jan 2016 11:22 UTC Check of Modelica and ModelicaTest with Dymola 2016 FD01 with pedantic flag is now successfull. There are a few uncritical warnings in Modelica. Additionally, the following errors have been fixed: 1e8952cb1967802a9b058cc71c1a1799e67269f6, b4b6ce3de7ed0128170b45bf974b04648c53fc8a, 5e715ef83bc9f47da0ce07014c117e9fb5b51027, c2f9a65c2b540803540c89d862e15f8793fd99f8, d9c73e74074abf4a1d7d3211a9536610c3ab416c, dc4431be6b4c1dd6026d23c58863323182e1db39

modelica-trac-importer commented 7 years ago

Comment by beutlich on 13 Jan 2016 14:10 UTC Should Complex and ModelicaServices also be updated to v3.2.2?

modelica-trac-importer commented 7 years ago

Comment by hansolsson on 13 Jan 2016 15:37 UTC On one hand ModelicaServices version number was recently changed from 1.2 to 3.2.1 – which strongly suggests that we wanted them synchronized, and it uses Modelica (with a specific version)– so in that way there is a dependency. (Complex doesn’t use MSL on the other hand.)

-- On the other hand it is a bit more complex since ModelicaServices should be provided by vendors which mean that any version inconsistency could cause additional problems. However, that seems like a generic problem and I don’t see that upgrading or not upgrading will influence that (after giving it some thought).

To solve that problem what I would propose (at some point) is to add an annotation like: target=”Dymola” to ModelicaServices. Obviously we can handle that specific case with a vendor-specific annotation – but the point is to add target=”Generic” or target=”SomeOtherVendor” to the other ones so that Dymola will avoid loading them, and that requires standardizing the annotation in some form. But it seems de-coupled from upgrading or not upgrading. -- So in conclusion it seems cleanest to upgrade both to 3.2.2.

modelica-trac-importer commented 7 years ago

Comment by dietmarw on 14 Jan 2016 11:35 UTC I found this warning but can not say if it is a bug or a tool issue: #1879

modelica-trac-importer commented 7 years ago

Comment by otter on 15 Jan 2016 08:09 UTC Replying to [comment:11 beutlich]:

Should Complex and ModelicaServices also be updated to v3.2.2?

Replying to [comment:12 hansolsson]:

... So in conclusion it seems cleanest to upgrade both to 3.2.2.

Changed version numbers of Complex, ModelicaServices, and ModelicaReference to 3.2.2 in afc473cbe088aab0dbe067c32b1a4da2c0986132 and 6b49e9b9d7487916196dc24e6dc87676b03bc6dc

Replying to [comment:13 dietmarw]:

I found this warning but can not say if it is a bug or a tool issue: #1879

As sketched in #1879, this is uncritical (and the tool should not print this warning).

modelica-trac-importer commented 7 years ago

Comment by beutlich on 15 Jan 2016 08:37 UTC I needed to reopen #1258 again after testing for #1880. Let's hope that

modelica-trac-importer commented 7 years ago

Comment by otter on 15 Jan 2016 09:51 UTC Run Dymola 2016 FD01 with "Check with Simulation" on Modelica and ModelicaTest.

Critical issues:

Uncritical issues:

modelica-trac-importer commented 7 years ago

Comment by otter on 15 Jan 2016 10:21 UTC Replying to [comment:16 otter]:

...

Critical issues:

  • Modelica.Mechanics.Rotational.Examples.GenerationOfFMUs This model does not translate in Dymola 2016 FD01, but translates and simulates in Dymola 2016. The error message is "Failed to reduce the DAE index". I reported this to DS (seems to be a Dymola problem, and for MSL 3.2.2 testing, a failure of this model in Dymola should be ignored).

Reopened ticket #1523 since the fix in this ticket has the effect that GenerationOfFMUs fails.

modelica-trac-importer commented 7 years ago

Comment by jmattsson on 15 Jan 2016 10:23 UTC Replying to [comment:8 otter]:

Replying to [comment:5 jmattsson]:

We are having some problems with the following new MSL models in JModelica.org: * HalfControlledBridge2mPulse * ThyristorBridge2mPulse_R * ThyristorBridge2mPulse_RL * ThyristorBridge2mPulse_RLV * ThyristorBridge2mPulse_RLV_Characteristic within Modelica.Electrical.PowerConverters.Examples.ACDC.RectifierBridge2mPulse. ...

Sorry, this is fixed in 576b8f6dc58be31baf47be9ceb83da8752f6aa5a by correcting an error in Limiter, VariableLimiter and DeadZone that was introduced when improving these components (the "simplified" argument of the homotopy operator was wrongly referencing y instead of u). instead of u).

We still get the same errors. (Sorry for the delay - it took a while for all the changes to get through our regression testing system.)

Replying to [comment:16 otter]:

These Modelica models have (by purpose) overspecified, but consistent, initialization definitions. Dymola seems to not (yet) support the handling of such systems.

JModelica.org also gives errors for all the models in your last bullet, and the fact that they all but one of the names end in "FullInitialInconsistent" hints that the tools are probably correct. See #1591.

modelica-trac-importer commented 7 years ago

Comment by beutlich on 15 Jan 2016 11:12 UTC There are currently three open MSL 3.2.2 tickets on ModelicaMatIO: #1258, #1880 and #1881. I will fix them (all in one go) within the next week(s).

modelica-trac-importer commented 7 years ago

Comment by beutlich on 15 Jan 2016 13:30 UTC Replying to [comment:19 beutlich]:

There are currently three open MSL 3.2.2 tickets on ModelicaMatIO: #1258, #1880 and #1881. I will fix them (all in one go) within the next week(s).

Fixed by 7ae3b0dae92a4b717580a0e58791c80db9a26205 and d24b63c0f7f404969ed92475aa30b06d32fda741.

modelica-trac-importer commented 7 years ago

Comment by otter on 15 Jan 2016 13:41 UTC Replying to [comment:17 otter]:

Replying to [comment:16 otter]:

...

Critical issues:

  • Modelica.Mechanics.Rotational.Examples.GenerationOfFMUs This model does not translate in Dymola 2016 FD01, but translates and simulates in Dymola 2016. The error message is "Failed to reduce the DAE index". I reported this to DS (seems to be a Dymola problem, and for MSL 3.2.2 testing, a failure of this model in Dymola should be ignored).

Reopened ticket #1523 since the fix in this ticket has the effect that GenerationOfFMUs fails.

Fixed in 807dfa2ebd10e728f97e712fe28f48b90eb9e970 (however, model will still fail in Dymola 2016 FD01, but hopefully not in future Dymola versions).

modelica-trac-importer commented 7 years ago

Comment by otter on 15 Jan 2016 15:01 UTC I would suggest to release MSL 3.2.2 Beta.1 on Sunday evening (Jan. 17) or Monday morning (Jan. 18).

According to my understanding, the only open issue is comment:18 from Jesper Mattsson that some models do not simulate in JModelica.org. Currently, there is not enough information available to figure out the reason. Note, after the fix of the Limiter block, these models simulate in Dymola 2016 FD01 and in OpenModelica 1.9.4 dev. (in OpenModelica there are warnings "maximal number of iteration reached but no root found", but simulation is successful; this might indicate that there is still an issue). In case there is a suggestion to rewrite the Limiter block so that it is easier supported by tools, we can do this also after Beta.1 is released. The advantage is that regression testing of Beta.1 can be started next week. Note, the models that do not simulate in JModelica have not been present in 3.2.1 and therefore regression testing is not influenced by them.

The other reported issues are resolved:

modelica-trac-importer commented 7 years ago

Comment by jmattsson on 15 Jan 2016 15:31 UTC I agree.

I will look into the problem in the meantime.

modelica-trac-importer commented 7 years ago

Comment by jmattsson on 18 Jan 2016 19:07 UTC As far as I can see, the equation in Limiter that was fixed in 576b8f6dc58be31baf47be9ceb83da8752f6aa5a wasn't involved at all in the algebraic loop reported by JModelica.org (since homotopy support is still experimental in JModelica.org, default is to only use actual-expression). Also, it looks to me like the error given by SimulationX (comment:6) is the same as the one given by JModelica.org.

Replying to [comment:6 beutlich]:

This is what SimulationX issues

Could you please test again with SimulationX after 576b8f6dc58be31baf47be9ceb83da8752f6aa5a?

These 13 equations (after transformations) form the smallest of the algebraic loops containing the when guard in question:

pulse2m.twomPulse.positiveThreshold[3].y = pulse2m.twomPulse.v[3] > pulse2m.twomPulse.positiveThreshold[3].threshold;
when pulse2m.twomPulse.positiveThreshold[3].y then 
    pulse2m.twomPulse.timerPositive[3].entryTime = time;
end when;
pulse2m.twomPulse.greaterPositive[3].u1 = if pulse2m.twomPulse.positiveThreshold[3].y then time - pulse2m.twomPulse.timerPositive[3].entryTime else 0.0;
pulse2m.fire_p[3] = pulse2m.twomPulse.greaterPositive[3].u1 > pulse2m.twomPulse.greaterPositive[3].u2;
rectifier.andCondition_p[3].y = pulse2m.fire_p[3] and rectifier.andCondition_p[1].u2;
rectifier.thyristor_p.idealThyristor[3].off = rectifier.thyristor_p.idealThyristor[3].s < 0 or pre(rectifier.thyristor_p.idealThyristor[3].off) and not rectifier.andCondition_p[3].y;
rectifier.thyristor_p.idealThyristor[3].v = rectifier.thyristor_p.idealThyristor[3].s * (if rectifier.thyristor_p.idealThyristor[3].off then 1 else rectifier.thyristor_p.idealThyristor[3].Ron) + rectifier.thyristor_p.idealThyristor[3].Vknee;
rectifier.thyristor_p.i[3] = rectifier.thyristor_p.idealThyristor[3].s * (if rectifier.thyristor_p.idealThyristor[3].off then rectifier.thyristor_p.idealThyristor[3].Goff else 1) + rectifier.thyristor_p.idealThyristor[3].Goff * rectifier.thyristor_p.idealThyristor[3].Vknee;
- rectifier.iAC[3] + (- rectifier.diode_n.i[3]) + rectifier.thyristor_p.i[3] = 0;
rectifier.iAC[1] + rectifier.iAC[2] + rectifier.iAC[3] + ground.p.i = 0;
multiStarResistance.resistor.v[1] = multiStarResistance.resistor.resistor[1].R_actual * ground.p.i;
sineVoltage.sineVoltage[3].v = rectifier.vAC[3] - multiStarResistance.resistor.v[1];
pulse2m.twomPulse.v[3] = rectifier.vAC[3] - rectifier.vAC[2];

The variables bound to each equation are (in the same order):

pulse2m.twomPulse.positiveThreshold[3].y
pulse2m.twomPulse.timerPositive[3].entryTime
pulse2m.twomPulse.greaterPositive[3].u1
pulse2m.fire_p[3]
rectifier.andCondition_p[3].y
rectifier.thyristor_p.idealThyristor[3].off
rectifier.thyristor_p.idealThyristor[3].s
rectifier.thyristor_p.i[3]
rectifier.iAC[3]
ground.p.i
multiStarResistance.resistor.v[1]
rectifier.vAC[3]
pulse2m.twomPulse.v[3]
modelica-trac-importer commented 7 years ago

Comment by hansolsson on 19 Jan 2016 08:38 UTC Replying to [comment:24 jmattsson]:

As far as I can see, the equation in Limiter that was fixed in 576b8f6dc58be31baf47be9ceb83da8752f6aa5a wasn't involved at all in the algebraic loop reported by JModelica.org (since homotopy support is still experimental in JModelica.org, default is to only use actual-expression). Also, it looks to me like the error given by SimulationX (comment:6) is the same as the one given by JModelica.org.

...

The variables bound to each equation are (in the same order):

...

ground.p.i

As far as I can see the difference in Dymola we figure out that ground.p.i is zero and substituting that breaks the algebraic loop. (This simplification is not directly related to the work on un-grounded electrical circuits.)

It may seem a bit excessive to require this simplification in order to avoid loops when using these new components.

modelica-trac-importer commented 7 years ago

Comment by jmattsson on 19 Jan 2016 09:31 UTC Replying to [comment:25 hansolsson]:

As far as I can see the difference in Dymola we figure out that ground.p.i is zero and substituting that breaks the algebraic loop. (This simplification is not directly related to the work on un-grounded electrical circuits.)

I see. That would solve it, yes.

I can see that you could deduce that from:

 rectifier.thyristor_p.i[1] + rectifier.thyristor_p.i[2] + rectifier.thyristor_p.i[3] + (- der(meanCurrent.x)) = 0;
 - rectifier.diode_n.i[1] + (- rectifier.diode_n.i[2]) + (- rectifier.diode_n.i[3]) + der(meanCurrent.x) = 0;
 - rectifier.iAC[1] + (- rectifier.diode_n.i[1]) + rectifier.thyristor_p.i[1] = 0;
 - rectifier.iAC[2] + (- rectifier.diode_n.i[2]) + rectifier.thyristor_p.i[2] = 0;
 - rectifier.iAC[3] + (- rectifier.diode_n.i[3]) + rectifier.thyristor_p.i[3] = 0;
 rectifier.iAC[1] + rectifier.iAC[2] + rectifier.iAC[3] + ground.p.i = 0;

since that gives:

sum(rectifier.thyristor_p.i[:]) = sum(rectifier.diode_n.i[:])
sum(rectifier.iAC[:]) = sum(rectifier.thyristor_p.i[:]) - sum(rectifier.diode_n.i[:])

and that in turn gives:

sum(rectifier.iAC[:]) = 0
ground.p.i = 0

I agree that it seems a bit much to require that simplification from all tools.

modelica-trac-importer commented 7 years ago

Comment by otter on 22 Jan 2016 21:18 UTC Replying to [comment:8 otter]:

Replying to [comment:5 jmattsson]:

We are having some problems with the following new MSL models in JModelica.org: * HalfControlledBridge2mPulse * ThyristorBridge2mPulse_R * ThyristorBridge2mPulse_RL * ThyristorBridge2mPulse_RLV * ThyristorBridge2mPulse_RLV_Characteristic within Modelica.Electrical.PowerConverters.Examples.ACDC.RectifierBridge2mPulse. ...

Fixed in 57b08695f02ceafa3dd40c1596876f35385a972f by:

Please check, whether these models simulate now in JModelica and SimulationX.

modelica-trac-importer commented 7 years ago

Comment by otter on 24 Jan 2016 20:14 UTC Fixed #1886 (impure functions) in 9675059d9b73520eca614086ffe3412d3acb49ad

CheckWithSimulation with Dymola 2017 dev.4 gives one error on

ModelicaTest.Fluid.TestExamplesVariants.BranchingDynamicPipes_MomentumSteadyState
ERROR: Failed to solve non-linear system using Newton solver.

There are also the following uncritical failures (due to overdetermined initial equations):

ModelicaTest.Translational.TestOverdeterminedInitial.TwoMassesEquationsFullInitialInconsistent
ModelicaTest.Translational.TestOverdeterminedInitial.TwoMassesFullInitialInconsistent
ModelicaTest.OverdeterminedInitialization.Fluid.TwoVolumesEquationsFullInitialInconsistent
ModelicaTest.OverdeterminedInitialization.Fluid.TwoVolumesEquationsFullSteadyStateMassAndEnergy
ModelicaTest.OverdeterminedInitialization.Fluid.TwoVolumesFullInitialInconsistent
ModelicaTest.OverdeterminedInitialization.Mechanical.TwoMassesEquationsFullInitialInconsistent
ModelicaTest.OverdeterminedInitialization.Mechanical.TwoMassesFullInitialInconsistent
modelica-trac-importer commented 7 years ago

Comment by otter on 24 Jan 2016 20:24 UTC

CheckWithSimulation with Dymola 2017 dev.4 gives one error on

ModelicaTest.Fluid.TestExamplesVariants.BranchingDynamicPipes_MomentumSteadyState
ERROR: Failed to solve non-linear system using Newton solver.

This fails also in Dymola 2016 FD01 (at time = 2.23 s the nonlinear solver fails). Furthermore, there is a warning about conflicting start values during initalization

The iteration variable pipe3.state_b.p has been selected to have the guess value pipe2.ps_start[5].
However, the start value has been selected from a set of alias variables having conflicting start values of the same precedence.
100000.0, the start value of pipe3.state_b.p given as 100000.0.
120000.0, the start value of pipe2.mediums[5].p given as pipe2.ps_start[5].

The iteration variable pipe1.state_b.p has been selected to have the guess value pipe2.ps_start[1].
However, the start value has been selected from a set of alias variables having conflicting start values of the same precedence.
100000.0, the start value of pipe1.state_b.p given as 100000.0.
130000.0, the start value of pipe2.mediums[1].p given as pipe2.ps_start[1].
modelica-trac-importer commented 7 years ago

Comment by otter on 24 Jan 2016 20:30 UTC CheckWithSimulation with Dymola 2017 dev1 on Modelica (in trunk) is successful (no errors)

modelica-trac-importer commented 7 years ago

Comment by jmattsson on 25 Jan 2016 09:15 UTC Replying to [comment:27 otter]:

Fixed in 57b08695f02ceafa3dd40c1596876f35385a972f by: ... Please check, whether these models simulate now in JModelica and SimulationX.

That solved it for JModelica.org.

Replying to [comment:28 otter]:

There are also the following uncritical failures (due to overdetermined initial equations):

One of our developers have previously examined the ones that have names ending with "InitialInconsistent" and came to the conclusion that they have inconsistently overspecified initial conditions, as the names suggest, and should thus fail to translate. I'd say we should move them to ModelicaCompliance - see #1591.

modelica-trac-importer commented 7 years ago

Comment by leo.gall on 26 Jan 2016 08:21 UTC I updated the reference results for Modelica and ModelicaTest based on MSL 3.2.1+build.4. Dymola 2014 FD01 has been used, in order to avoid changes introduced by a different tool version. Added some new results for Modelica examples, due to missing experiment annotations in MSL 3.2.1+build.2.

See r9004 and MA file server.

Access info: https://svn.modelica.org/projects/RegressionTesting/AccessInfo/read-access

On the file server, I moved the old files from "trunk" to "tags/v3.2.1+build.2.release". Otherwise it wouldn't be clear on which MSL version the results are based on.

In SVN, there is only one "trunk" folder, i.e. the latest reference files. Otherwise the file size of SVN checkouts would grow very large.

These files will be used for release tests of MSL 3.2.2. If you find any issues, please contact me or open a separate feedback ticket.

modelica-trac-importer commented 7 years ago

Comment by msasena on 26 Jan 2016 18:12 UTC It looks like there are still 3 models that include Tolerance in their experiment annotations, but not StopTime:

We could really use the StopTime values in order to automate some testing, or at the very least explicitly state how long the expected simulation test should run.

modelica-trac-importer commented 7 years ago

Comment by hubertus on 28 Jan 2016 20:34 UTC Replying to [comment:29 otter]:

CheckWithSimulation with Dymola 2017 dev.4 gives one error on


ModelicaTest.Fluid.TestExamplesVariants.BranchingDynamicPipes_MomentumSteadyState
ERROR: Failed to solve non-linear system using Newton solver.
}}}

This fails also in Dymola 2016 FD01 (at time = 2.23 s the nonlinear solver fails). Furthermore, there is a warning about conflicting start values during initalization {{{ The iteration variable pipe3.state_b.p has been selected to have the guess value pipe2.ps_start[5]. However, the start value has been selected from a set of alias variables having conflicting start values of the same precedence. 100000.0, the start value of pipe3.state_b.p given as 100000.0. 120000.0, the start value of pipe2.mediums[5].p given as pipe2.ps_start[5].

The iteration variable pipe1.state_b.p has been selected to have the guess value pipe2.ps_start[1]. However, the start value has been selected from a set of alias variables having conflicting start values of the same precedence. 100000.0, the start value of pipe1.state_b.p given as 100000.0. 130000.0, the start value of pipe2.mediums[1].p given as pipe2.ps_start[1].

I think we have two issues here

In summary, I would decide how to handle this depending on the results from other tools than Dymola.

modelica-trac-importer commented 7 years ago

Comment by jmattsson on 29 Jan 2016 10:07 UTC Replying to [comment:34 hubertus]:

What are the results with other tools (OpenModelica, JModelica, SimulationX)?

JModelica.org selects the start values from pipe2.mediums[5].p & pipe2.mediums[1].p, and successfully simulates the model.

To determine how we select between the two alternatives, I'd need to examine it more. I suspect that the reason is that we do not select the same variables to keep from the alias set as Dymola, and the start value of the selected variable is given precedence when they are set at the same levels.

modelica-trac-importer commented 7 years ago

Comment by hansolsson on 29 Jan 2016 15:51 UTC ModelicaTest.Fluid.TestExamplesVariants.BranchingDynamicPipes_MomentumSteadyState simulates in Dymola if you tighten the tolerance quite a bit.

I have not yet fully investigated the reason for the problem: the model equations are re-evaluated at a point in time - and the second time the non-linear system has significantly different "inputs" and fails. One possibility is that the model is very sensitive and the model is evaluated for slightly different values, but it could also be something else.

The warning for conflicting start-value can be ignored and has been removed, and does not seem related to the simulation problem.

modelica-trac-importer commented 7 years ago

Comment by hansolsson on 29 Jan 2016 16:07 UTC Added a minor ticket for the tables-handling #1899 - it is not necessary for the beta.

modelica-trac-importer commented 7 years ago

Comment by hubertus on 29 Jan 2016 16:18 UTC Regarding ModelicaTest.Fluid.TestExamplesVariants.BranchingDynamicPipes_MomentumSteadyState:

My suspicion is that the model is numerically very sensitive, and should maybe be cleaned up/changed for the future, but it should not block the release, we could simply update the tolerance for Dymola. I opened a ticket with Milestone MSL next minor release and assigned it to Francesco for investigating this test. (#1900)

modelica-trac-importer commented 7 years ago

Comment by hansolsson on 5 Feb 2016 17:18 UTC While looking for my tickets I found #1747 which we also might consider for this release - depending on the resolution. The issue is an inconsistency between the HTML-recommendations and the HTML-code - and we could resolve it by weakening the recommendation.

modelica-trac-importer commented 7 years ago

Comment by beutlich on 9 Feb 2016 14:49 UTC Currently I am blocked in the beta testing since v3.2.2+build.0-beta.2 did not properly fix #1886. Can we expect a new beta release any time soon because of comment 26 of #1886 and 95896032cff5e5cb0b980c07d0f80f9aa9fd94e0 or should I wait for the RC which is planned on Feb. 19th?

modelica-trac-importer commented 7 years ago

Comment by msasena on 16 Feb 2016 00:41 UTC The LMS Amesim compiler found several "warnings" related to equality comparison of Real variables. For example, there are lines like if (d_vap <> d_liq) or if abs(m) <= tol or fb == 0.0. I suspect most other tools just ignore the warnings, like we do. However, it might be nice to clean up as many of them as we can before the v3.2.2 release. This is most likely just a partial list...

Functions that use == comparisons on Real variables:

Functions that use <> comparisons on Real variables:

modelica-trac-importer commented 7 years ago

Comment by sjoelund.se on 16 Feb 2016 05:49 UTC @msasena, Modelica spec says:

In relations of the form v1 == v2 or v1 <> v2, v1 or v2 shall, unless used in a function, not be a subtype of Real.

So they are allowed in these places.

modelica-trac-importer commented 7 years ago

Comment by dietmarw on 17 Feb 2016 11:51 UTC I just noticed that it is probably a good idea to hold regression testing until a new beta is generated. Otherwise it has to be done (and paid) all over again. Also the RC deadline definitely needs shifting because we first need a "stable" beta release on which tools can base their feedback.

modelica-trac-importer commented 7 years ago

Comment by hansolsson on 18 Feb 2016 10:39 UTC Replying to [comment:42 sjoelund.se]:

@msasena, Modelica spec says:

In relations of the form v1 == v2 or v1 <> v2, v1 or v2 shall, unless used in a function, not be a subtype of Real.

So they are allowed in these places.

I agree. However, even if equality tests are allowed in functions, it is preferable to avoid them for several reasons (including automatic differentiation). Clarified: Thus if the tests are necessary (as seems to be the case) they are ok.

modelica-trac-importer commented 7 years ago

Comment by hansolsson on 18 Feb 2016 11:16 UTC Replying to [comment:40 beutlich]:

Currently I am blocked in the beta testing since v3.2.2+build.0-beta.2 did not properly fix #1886. Can we expect a new beta release any time soon because of comment 26 of #1886 and 95896032cff5e5cb0b980c07d0f80f9aa9fd94e0 or should I wait for the RC which is planned on Feb. 19th?

Can you propose a change that corrects this?

As I understand it the problem is whether 'print' and 'writeMatrixToFile' should be marked as impure, since tools cannot optimize away the calls in Modelica_Requirements.

However, those functions weren't marked as impure in MSL 3.2.1 - and thus it seems odd that they are now blocking.

One possibility would be to clarify the specification to also limit the optimizations inside impure functions (not only of impure function calls), i.e. requiring that print("") calls in the impure function are kept, even if print is "pure" - and then it suffices to update Modelica_Requirements (as is already done).

I believe that would make intuitive sense for users, and not require any change to MSL.

Replying to [comment:43 dietmarw]:

I just noticed that it is probably a good idea to hold regression testing until a new beta is generated. Otherwise it has to be done (and paid) all over again. Also the RC deadline definitely needs shifting because we first need a "stable" beta release on which tools can base their feedback.

I don't see that we need to shift the RC deadline yet.

Part of the beta feedback is that we need to resolve the pure-handling for a few functions in some way. That shouldn't block beta feedback for the rest of the library.

However, we clearly need to resolve this problem.

modelica-trac-importer commented 7 years ago

Comment by beutlich on 18 Feb 2016 11:36 UTC I do not see an RC tomorrow if there are 4 open issues (#1886, #1890, #1899 and #1911) that still require discussion.

modelica-trac-importer commented 7 years ago

Comment by hansolsson on 18 Feb 2016 12:41 UTC Replying to [comment:46 beutlich]:

I do not see an RC tomorrow if there are 4 open issues (#1886, #1890, #1899 and #1911) that still require discussion.

Well, by saying that we aren't too late 'yet' was to push us to actually discuss those topics as soon as possible (and possibly also #1747 ).

1886 We need some decision. One idea that I proposed above was to limit optimizations in impure functions - which would leave MSL unchanged.

1899 I don't fully see what needs to be discussed for this release (some parts can be discussed later). Can you clarify the unclear points?

1890 It seems the problem is how we adapt the libraries to fit multiple tools. I am unclear whether there is a blocking problem - or if the solution is just "inelegant".

1911 We can just delay - stating that it is a new feature after feature-freeze.

modelica-trac-importer commented 7 years ago

Comment by beutlich on 18 Feb 2016 13:07 UTC

modelica-trac-importer commented 7 years ago

Comment by hansolsson on 18 Feb 2016 16:10 UTC Replying to [comment:48 beutlich]:

* #1899: Not yet clear to me if t_min/t_max should change from fixed-false-parameters to fixed parameters with declaration equation dependening on the ext. object by completely removing the initial algorithm.

To me either variant will work.

* #1890: The current solution is far away from being elegant. I'd like to see it reverted and know why Dymola fails on the more elegant solutions as proposed by [comment 4 of #1890 Toni] or me.

I investigated and it was due to the definition of complex sum; which should be improved. (Regardless of whether we then use matrixVectorProduct or m*v).

My point with not moving the schedule 'yet' was exactly to make us focus our attention on solving these issues.

modelica-trac-importer commented 7 years ago

Comment by jmattsson on 18 Feb 2016 17:40 UTC Replying to [comment:46 beutlich]:

I do not see an RC tomorrow if there are 4 open issues (#1886, #1890, #1899 and #1911) that still require discussion.

It looks to me like we need another beta once the issues are resolved. There have been 30 revisions since beta 2 was tagged, 12 with commit messages that seem like bug fixes.

Since we are trying to move towards a more structured release process, we should stick to that process. If a release candidate has code changes compared to the preceding beta, then what is the distinction between a beta and a release candidate? Also, what is the main goal of the process changes - more confidence in the quality of released versions, or a more predictable release schedule?