7

There are different Modelica Simulation Environments, including Dymola, Wolfram SystemModeler, OpenModelica, and Jmodelica. So, I try to load a thermal fluid library(ThermoSysPro https://github.com/Dwarf-Planet-Project/ThermoSysPro), but except Dymola, the results on the other software all end with errors.

If the library and the simulation environment are all based on the Modelica Specification Standard, why there is a compatibility issue? I think that maybe the library includes some features that are only supported by Dymola. Could anyone clarify the difference between these simulation environments?

Jack
  • 1,094
  • 6
  • 16
  • If you are interested to know more about JModelica, [here](https://www.reddit.com/r/Python/comments/dcj6fy/jmodelica_combining_the_power_of_python_and/?utm_source=share&utm_medium=web2x) I wrote a small tutorial plus collecting many other usefull links. – Foad S. Farimani Feb 06 '20 at 19:19
  • Newer versions of ThermoSysPro are shipped with OpenModelica: Just download and install the latest OpenModelica, then go to `C:\Program Files\OpenModelicaXYZ-64bit\lib\omlibrary\ThermoSysPro XYZ`. But when checking that newer version in Dymola in non-pedantic mode, there are still ~200 errors (most often: problem is structurally singular, model is not well-posed, non-physical connector). – Priyanka Feb 14 '20 at 08:32
  • @Priyanka, I also tried to use Thermosyspro with Dymola a few days ago, but I think the most difficult problem is how to initialize the system, how does OpenModelica deal with this issue? – Jack Feb 14 '20 at 10:44

1 Answers1

8

In general:

  1. The tool you use might not support certain Modelica language elements

    Just because a tool supports Modelica, it does not mean that it has implemented everything yet what the Modelica standard defines. Take OpenModelica for example, which did not fully support synchronous features before v1.12.

  2. The code of the library might not be conform with the version of the Modelica Language Specification (Modelica spec) used by your tool

    Some tools allow certain things, which are not defined in the Modelica spec: maybe because the Modelica spec was not precise enough on a topic, or maybe they are a bit ahead and already support things which might be part of future spec versions.

    In Dymola you have two options to check a bit stricter if your code is conform with the current Modelica Language Specification: use the pedantic mode for checking and set the flag Advanced.EnableAnnotationCheck=true to let Dymola also check annotations

In your concrete example: There are various troubles with the ThermoSysPor library, which might explain your problems.

  1. The library was written with the rather old Modelica Standard Library (MSL) 3.2.1., which is based on the Modelica Language Specification 3.2.

    The current Dymola version (2020) uses the Modelica Language Specification 3.4 (see the Dymola release notes of each version to find that out). OpenModelica apparently supports Modelica 3.3 (as noted in the release notes).

    The MSL has also evolved a bit in the meantime, with the current version being 3.2.3.

    Hence, it is required to update ThermoSysPro to the latest MSL version 3.2.3 and to the Modelica spec the tool supports. Then you can start comparing in which tools it works and in which not.

  2. The library does not fully work in Dymola either

    I tested with the latest Dymola version and Dymola 2016 FD01, which contained the MSL 3.2.1.

    1. Dymola 2016 FD01: 31 errors, 62 warnings
    2. Dymola 2020: 175 errors, 095 warnings

  3. The library contains invalid language elements. Two examples:

    1. In ThermoSysPro.Examples.SimpleExamples.TestCentrifugalPump OpenModelica v1.14 beta 2 complains, that cardinality is not used in a legal way. Apparently Dymola 2020 does not care (even in pedantic mode), but it's against the Modelica Spec 3.4.

    2. Many models contain the annotation DymolaStoredErrors, which is not standard conform. Custom tool annotations must start with '__'.

marco
  • 5,944
  • 10
  • 22
  • I also tested the ThermoSysPro library with Dymola 2020, but it successfully loaded the library, and I tested a few examples shipped with the library, they all worked fine. So, I am not sure why your result ends with 175 errors? Did you test all the examples and components in the library with some test scripts? If so, how did do that? – Jack Nov 20 '19 at 10:38
  • 1
    I checked the full library by marking the package `ThermoSysPro` in the package browser and clicking 'Check' (F8). – marco Nov 20 '19 at 10:40
  • 3
    The DymolaStoredErrors are empty in this library and can thus be removed without any problem. For cardinality the restriction was added in Modelica 3.3r1, but not yet implemented in Dymola. (Prior to that cardinality could be used this freely.) – Hans Olsson Nov 20 '19 at 14:47
  • 1
    Just a small correction, the MSL 3.2.3 is still based on Modelica Specification 3.2rev2. The current **development** version which will become 4.0.0 will be based on the Modelica Specification 3.4 – Dietmar Winkler Nov 21 '19 at 14:56
  • 2
    Thanks Dietmar, you are right. It is Dymola 2020 which uses the Modelica Language Spec 3.4, not the MSL. I mixed that up. – marco Nov 21 '19 at 15:02
  • @Marvel could you also test a simple model in ThermoSysPro? It's rather straight forward from WaterSteam library: SourcePQ + DynamicTwoPhasePipe + Sink(h) or Source(h) + DynamicTwoPhasePipe + SinkPQ. In both cases the OpenModelica crashes for me. – Tomillo Nov 22 '19 at 14:56