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.
Related
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 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.
I am using Eclipse (version: Kepler Service Release 1) with Prolog Development Tool (PDT) plug-in for Prolog development in Eclipse. Used these installation instructions: http://sewiki.iai.uni-bonn.de/research/pdt/docs/v0.x/download.
I am working with Multi-Agent IndiGolog (MIndiGolog) 0 (the preliminary prolog version of MIndiGolog). Downloaded from here: http://www.rfk.id.au/ramblings/research/thesis/. I want to use MIndiGolog because it represents time and duration of actions very nicely (I want to do temporal planning), and it supports planning for multiple agents (including concurrency).
MIndiGolog is a high-level programming language based on situation calculus. Everything in the language is exactly according to situation calculus. This however does not fit with the project I'm working on.
This other high-level programming language, Incremental Deterministic (Con)Golog (IndiGolog) (Download from here: http://sourceforge.net/p/indigolog/code/ci/master/tree/) (also made with Prolog), is also (loosly) based on situation calculus, but uses fluents in a very different way. It makes use of causes_val-predicates to denote which action changes which fluent in what way, and it does not include the situation in the fluent!
However, this is what the rest of the team actually wants. I need to rewrite MIndiGolog so that it is still an offline planner, with the nice representation of time and duration of actions, but with the causes_val predicate of IndiGolog to change the values of the fluents.
I find this extremely hard to do, as my knowledge in Prolog and of situation calculus only covers the basics, but they see me as the expert. I feel like I'm in over my head and could use all the help and/or advice I can get.
I already removed the situations from my fluents, made a planning domain with causes_val predicates, and tried to add IndiGolog code into MIndiGolog. But with no luck. Running the planner just returns "false." And I can make little sense of the trace, even when I use the GUI-tracer version of the SWI-Prolog debugger or when I try to place spy points as strategically as possible.
Thanks in advance,
Best, PJ
If you are still interested (sounds like you might not be): this isn't actually very hard.
If you look at Reiter's book, you will find that causes_vals are just effect axioms, while the fluents that mention the situation are usually successor-state-axioms. There is a deterministic way to convert from the former to the latter, and the correct interpretation of the causes_vals is done in the implementation of regression. This is always the same, and you can just copy that part of Prolog code from indiGolog to your flavor.
A friend of mine needs to implement some statistical calculations in hardware.
She wants it to be accomplished using VHDL.
(cross my heart, I haven't written a line of code in VHDL and know nothing about its subtleties)
In particular, she needs a direct analogue of MATLAB's betainc function.
Is there a good package around for doing this?
Any hints on the implementation are also highly appreciated.
If it's not a good idea at all, please tell me about it as well.
Thanks a lot!
There isn't a core available that performs an incomplete beta function in the Xilinx toolset. I can't speak for the other toolsets available, although I would doubt that there is such a thing.
What Xilinx does offer is a set of signal processing blocks, like multipliers, adders and RAM Blocks (amongst other things, filters, FFTs), that can be used together to implement various custom signal transforms.
In order for this to be done, there needs to be a complete understanding of the inner workings of the transform to be applied.
A good first step is to implement the function "manually" in matlab as a proof of concept:
Instead of using the built-in function in matlab, your friend can try to implement the function just using fundamental operators like multipliers and adders.
The results can be compared with those produced by the built-in function for verification.
The concept can then be moved to VHDL using the building blocks that are provided.
Doing this for the incomplete beta function isn't something for the faint-hearted, but it can be done.
As far as I know there is no tool which allow interface of VHDL and matlab.
But interface of VHDL and C is fairly easy, so if you can implement your code(MATLAB's betainc function) in C then it can be done easily with FLI(foreign language interface).
If you are using modelsim below link can be helpful.
link
First of all a word of warning, if you haven't done any VHDL/FPGA work before, this is probably not the best place to start. With VHDL (and other HDL languages) you are basically describing hardware, rather than a sequential line of commands to execute on a processor (as you are with C/C++, etc.). You thus need a completely different skill- and mind-set when doing FPGA-development. Just because something can be written in VHDL, it doesn't mean that it actually can work in an FPGA chip (that it is synthesizable).
With that said, Xilinx (one of the major manufacturers of FPGA chips and development tools) does provide the System Generator package, which interfaces with Matlab and can automatically generate code for FPGA chips from this. I haven't used it myself, so I'm not at all sure if it's usable in your friend's case - but it's probably a good place to start.
The System Generator User guide (link is on the previously linked page) also provides a short introduction to FPGA chips in general, and in the context of using it with Matlab.
You COULD write it yourself. However, the incomplete beta function is an integral. For many values of the parameters (as long as both are greater than 1) it is fairly well behaved. However, when either parameter is less than 1, a singularity arises at an endpoint, making the problem a bit nasty. The point is, don't write it yourself unless you have a solid background in numerical analysis.
Anyway, there are surely many versions in C available. Netlib must have something, or look in Numerical Recipes. Or compile it from MATLAB. Then link it in as nav_jan suggests.
As an alternative to VHDL, you could use MyHDL to write and test your beta function - that can produce synthesisable (ie. can go into an FPGA chip) VHDL (or Verilog as you wish) out of the back end.
MyHDL is an extra set of modules on top of Python which allow hardware to be modelled, verified and generated. Python will be a much more familiar environment to write validation code in than VHDL (which is missing many of the abstract data types you might take for granted in a programming language).
The code under test will still have to be written with a "hardware mindset", but that is usually a smaller piece of code than the test environment, so in some ways less hassle than figuring out how to work around the verification limitations of VHDL.