Problem with Incompressible Media in MSL trunk

[Rüdiger Franke]

The example Modelica.Fluid.Examples.IncompressibleFluidNetwork runs flawlessly with MSL 3.2.1. With MSL trunk the simulations run forever with both:

• MSL_trunk: alarm clock
• MSL_trunk_cpp: Killed

The Fluid example is identical in both versions of MSL. The problem might be caused by the used medium Glycol47. Moreover the frontend appears to pre-evaluate less things in the frontend when testing MSL trunk, compared to testing MSL 3.2.1.

The Cpp runtime additionally fails to solve the simple Modelica.Media.Examples.Tests.MediaTestModels.Incompressible.Glycol47.

Moreover the trunk version of Modelica.Media.Incompressible.Examples.TestGlycol produces an error due to unknown ‘poly_Cp’ in both runtimes.

Any idea?

[Adrian Pop]

The component "poly_Cp" is a package constant that we need to evaluate and we can't.
That's why it ends up in the code but has no value. This is a known problem that I'm working to fix.

[Rüdiger Franke]

The use of poly_Cp fails particularily in Modelica.Media.Incompressible.TableBased.s_T that only accesses some elements of the vector.

It appears to work in other functions of the medium, like Modelica.Media.Incompressible.TableBased.h_T.

The value of the package constant is defined through a least squares calculation. It should not be re-calculated during each evaluation of a medium function.

Is this a case for pre-evaluation by the frontend, because all involved variables are constant?

[Adrian Pop]

Yes. It should be calculated by the front-end to a value but somehow it fails to do that.

[Martin Sjölund]

Moved to new milestone 1.9.4

[Martin Sjölund]

Milestone pushed to 1.9.5

[Martin Sjölund]

Milestone renamed

[Martin Sjölund]

Ticket retargeted after milestone closed

[Martin Sjölund]

Milestone moved to 1.12.0 due to 1.11.0 already being released.

[Francesco Casella]

The milestone of this ticket has been reassigned to "Future".

If you think the issue is still valid and relevant for you, please select milestone 1.13.0 for back-end, code generation and run-time issues, or 2.0.0 for front-end issues.

If you are aware that the problem is no longer present, please select the milestone corresponding to the version of OMC you used to check that, and set the status to "worksforme".

In both cases, a short informative comment would be welcome.

[Per Östlund]

The mentioned models seem to work fine with both the old and the new frontend now.