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.
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.
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 '__'.
I implemented a (medium to big) simulink model in v2012b.
I thought it would work also in 2010bSP2, but it didn't. Some mask blocks are not opening and other strange errors.
In previous versions of simulink there was a "save as simulink 201x" model to force compatibility, but I couldn't find it anymore in 2012b.
Any clues on how to avoid rework?
Starting with 2012b, and the new interface, they have moved the option to the menu:
File / Export Model to / Previous Version
The feature never seems to fully work, and I often get warnings when first loading a model into an older version, so I would recommend giving your model a thorough check over and test. I always save again from the correct version, to clear the warnings.
The refactoring for a New Simulink Version can show up at several points.
Your own libraries: There is a feature called "Forwarding Tables" that allows you to specify where a block in the new library is (I suppose you will have to refactor your libraries as well, and probably someone else uses those libraries too)
It sounds like a biiig hack (and it is) but i found it sometimes the path of lowest resistantce... Just open your model in the Editor of your choice and replace the block paths whith the common refactoring funcitons. It is terrible i know but Simulink really lacks of refactoring functions...
I am trying to develop a simulation in OpenModelica of a flow that has a single substance that will be liquid or vapor. The Modelica.Media.Water models do have two phases, but are extremely complicated, and would be very hard to reproduce for a completely different substance.
I would like to find a simple example of a two phase medium that I can work from. There is a partial package TemplateMedium and a partial package PartialTwoPhaseMedium, but I don't see any examples of how to write a completely new Medium that can be in either of two phase.
If anyone can provide a simple example, or just a list of the minimum set of properties and equations that are required that would be extremely helpful as a starting point.
To address some of the question in comments:
I am just getting started on this model, so I am trying to understand the details of how the Media model is constructed, and what my specifics are included in the model versus what has to be added for each new media. I working with propylene, so there is good data available. This is one of the media that is included in CoolProp, so being able to use ExternalMedia and CoolProp would be very useful, but I believe that these are not yet working with OpenModelica, from a number of comments and bug reports.
Generally, your medium model can be written in Modelica or you can reuse an existing external library. Writing good medium models is a lot of work, so reusing existing libraries is usually a good idea. This is the approach taken by ExternalMedia (open source) or TILMedia (commercial).
If you are interested in an open-source workflow, ExternalMedia in combination with Coolprop is a reasonable decision. All three projects OpenModelica, ExternalMedia and CoolProp accept contributions from the community, so maybe you should help improving these instead of writing your own library. There is a lot of work going on already, I am unsure of the current status. Writing qualified bug reports (including steps to reproduce the problem) is also a very welcome way to contribute.
For some applications, it might be good to have the Medium model directly in Modelica. This is the approach taken by Modelica.Media (obviously), HelmholtzMedia and the commercial media libraries from XRG or Modelon (not 100% sure about that). There are some more implementations, but these are neither open source nor commercial, only information are e.g. conference papers.
The examples you can look at include the R134a medium from the MSL or the code from the HelmholtzMedia library.
Also, looking at the ExternalMedia implementation might help.
For fluids that cannot change phase, there are some good examples in the Annex60 library.
As you have a pure substance that can change phase, your new medium should extend from PartialTwoPhaseMedium.
PartialTwoPhaseMedium is partial, defining only what functions are there, but (mostly) not the algorithms of the functions.
You will have to write an algorithm for each and every function that is available in the interface and does not have an algorithm in order to be fully compatible.
For a start, you should implement at least one of the setState funtions, e.g. the setState_ph function.
Then later, implement at least one setSat function and the BaseProperties.
If you implement your own medium, you also have the choice of how to model it: Using the full multiparameter Helmholtz energy equation of state, a simpler equation of state like Peng-Robinson or other cubic EoS, some polynomials or splines, table-based methods like TTSE or SBTL and probably many more options.
I'm looking for a function in Julia to estimate coefficients for an ARMA process.
For example using the Prediction Error Model as pem and armax in Matlab (part of system identification toolbox) do. pem documentation and armax documentation.
I've looked at the following packages, but can't see that they do what I'm looking for:
TimeSeries.jl
TimeModels.jl
One solution is of course to use Matlab.jl and use the Matlab functions, but I was hoping to do it all in Julia.
If there isn't anything right now, does anyone know of if there are any good Julia functions for multidimensional numerical minimisation (like Newton-Raphson), that can be used for implementing a PEM function?
UPDATE: I've just pushed a module to github called RARIMA.jl. This module can be used to estimate, forecast, and simulate ARIMA models (of which ARMA is a special case). Some of the functions are implemented in Julia, others (particularly estimation) call equivalent R functions using the RCall package which you will need to install and verify it works prior to using RARIMA. The package isn't officially registered (yet), so Pkg.add("RARIMA") won't work for now. If you want to use RARIMA, instead try Pkg.clone("https://github.com/colintbowers/RARIMA.jl"). If this fails, you can file an issue on the repository github page, but be sure to check RCall is installed and working before doing this. Cheers, I'll come back and update here if/when the package is officially registered.
ORIGINAL ANSWER: I just had a glance at the source, and TimeModels does not appear to have any functionality for estimating ARIMA models, although does have one function for simulating them. Given time though, I suspect this will be the package that deals with ARIMA modelling. The TimeSeries package is more about building the object type TimeSeries rather than implementing time series models, so I would be surprised if ARIMA modelling is ever merged into that package.
As near as I can tell, at this point if you want a fully functioning ARIMA package you'll need to use Matlab or R. The R one is very good (see the forecast package written by Rob Hyndman - it is very nice) and is probably easier to interface with from Julia than the Matlab option. Of course, the other option is to start it yourself and merge the code with the TimeModels package :-)
In terms of optimization procedures, Julia has a fair few that are written in Julia, and can be found under the JuliaOpt umbrella. The Optim package in particular is quite popular and well developed. However, most of the people I know who are really into this stuff use NLOpt which is a free open source library callable from many languages (including Julia). I have heard nothing but good things about this library from people who tend to work with this stuff 24/7.