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?
In general:
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.
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.
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.
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.
Dymola 2016 FD01: 31 errors, 62 warnings
Dymola 2020: 175 errors, 095 warnings
The library contains invalid language elements. Two examples:
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.
Many models contain the annotation DymolaStoredErrors, which is not standard conform. Custom tool annotations must start with '__'.
Related
I have some test simulations that, when run, do not follow the exact same solution path when run in Dymola 2021x and Dymola 2022. Thus, my system that checks to make sure my test simulations are running properly indicates that they are in fact not running properly. It appears that the simulations are still within +/-2*tolerance of each other. I am attempting to learn why it would be that the solutions are not numerically identical if they inputs and models are identical. Nothing in the update release indicated that there were any solution method changes.
From the Dymola 2022 Release Notes, one possible explanation could be in the different Modelica Language Specifications (3.4 in Dymola 2021x, 3.5 in Dymola 2022), either affecting the models directly (MSL 4.0.0 is compliant with the Language Specification 3.4, for example), or the way the models are handled during translation.
You mention you have a system in place that checks your simulation. Is it implemented in Modelica, that is, might it be affected by the different Language Specifications?
Personally, I tend to expect in each release minor changes/improvements in the translation algorithms and in the solvers; even though they might not be mentioned in the release notes. Perhaps this attitude only works because my models are rather coarse, so I cannot really say whether such a change in the computed solution (+-2*tolerance, tolerance=0.1% in my case) is bringing me closer or farther away from the real solution.
I am new to openmodelica,
Since I work in reliability engineering, the main feature of openmodelica that I will use is petri nets modelling.
I've learnt the ExtendedPetriNets library (https://github.com/modelica-3rdparty/ExtendedPetriNets).
However when I open this library in openmodelica I received several error messages which can be grouped into:
Class or component Ellipse not found
In modifier (Ellipse(extent = {{-100, -100}, {100, 100}}), class or component extent), class or component Ellipse not found in <Icon>
Duplicate modification of element Line.points on component Icon
[ExtendedPetriNets: 569:14-569:42]: Duplicate modification of element Line.points on component Icon
I suspect these error messages are due to version incompatibility between ExtendedPetriNets V 1.0 and OmEdit v1.13.2.
Hence my questions are:
1. Is it really due to version problem?
2. How to solve this problem?
Yes, it is due to version problems.
But the errors above are not important and you could just remove the problematic code, since Ellipse and Line.points are just part of the graphics.
ExtendedPetriNets uses an older set of graphical annotations than the one standardized in Modelica Specification 3.
However, ExtendedPetriNets also rely on ModelicaAdditions.PetriNets from https://github.com/modelica-deprecated/ModelicaAdditions which uses an older version of the Modelica Standard Library - and you would need conversions to use that with current versions.
It is likely that this will create more severe problems if you solve the first ones.
In the new Modelica Standard Library there is sort of a replacement for petri nets in the form of Modelica.StateGraph but it seems to lack the extensions you need.
I have been exploring Open Modelica for a week for system Dynamics. All though I learned few basic things(like function and class syntax etc..) from Spoken Tutorial, I need to go a long way. I am not to find a proper source mentioning the syntaxes for various aspects. For example, I am not able to find syntax for writing derivatives(dy/dx) apart from the time derivative[ der(x)]. Is there someplace where I can look into for further proceeding?
P.s. I am new to Softwares like MATLAB, Octave etc.. and OpenModelica is my first one.
OpenModelica is a Modelica tool. All Modelica related resources, e.g. language specification, can be found here: https://www.modelica.org/
Is there any method that support calling Modelica operator from java ?
If I want to use the Modelica Operator like der(), pre() and so on, call them from java.
Is there any technology I can use?
There are several ways to simulate Modelica models from a Java program. To directly simulate the Modelica code, use the Java interface of an existing Modelica simulator:
OpenModelica's Java interface
Java interface for Dymola
Another option is to export the Modelica code to a Functional Mockup Unit (FMU) via the Functional Mockup Interface (FMI), e.g. using Dymola. Then use a Java FMI library (e.g. JFMI) to interact with the FMU. Note that you'll probably need to supply the solver code yourself. However this is far easier for an FMU than for raw Modelica code.
Also see this question on SO for more information about exchaning information between Modelica and Java.
I am doing a compilers discipline at college and we must generate code for our invented language to any platform we want to. I think the simplest case is generating code for the Java JVM or .NET CLR. Any suggestion which one to choose, and which APIs out there can help me on this task? I already have all the semantic analysis done, just need to generate code for a given program.
Thank you
From what I know, on higher level, two VMs are actually quite similar: both are classic stack-based machines, with largely high-level operations (e.g. virtual method dispatch is an opcode). That said, CLR lets you get down to the metal if you want, as it has raw data pointers with arithmetic, raw function pointers, unions etc. It also has proper tailcalls. So, if the implementation of language needs any of the above (e.g. Scheme spec mandates tailcalls), or if it is significantly advantaged by having those features, then you would probably want to go the CLR way.
The other advantage there is that you get a stock API to emit bytecode there - System.Reflection.Emit - even though it is somewhat limited for full-fledged compiler scenarios, it is still generally enough for a simple compiler.
With JVM, two main advantages you get are better portability, and the fact that bytecode itself is arguably simpler (because of less features).
Another option that i came across what a library called run sharp that can generate the MSIL code in runtime using emit. But in a nicer more user friendly way that is more like c#. The latest version of the library can be found here.
http://code.google.com/p/runsharp/
In .NET you can use the Reflection.Emit Namespace to generate MSIL code.
See the msdn link: http://msdn.microsoft.com/en-us/library/3y322t50.aspx