I tried to exchange my Modelica model with one of my colleagues but ran into difficulties regarding paths to CSV-Files.
When I create the FMU the paths to some of the CSV files are set and point to folders on my computer. For example C:/Users/Me/file.csv. This obviously doesn't work for my colleague.
How can I export my Modelica model (Dymola) in such a way that the paths are set relative to the user?
The most common way is to use the loadResource() function provided with the Modelica Standard Library (MSL) at Modelica.Utilities.Files.loadResource to specify the path to the file. This is usually done using a Modelica URI, which could look like this:
filename=Modelica.Utilities.Files.loadResource("modelica://myLib/Resources/Data/file.csv")
This specifies a path relative to the libraries root path. Usually data files are stored in the Resources folder within the library.
This comes with the advantage, that when creating the FMU in Dymola, you can check the flag "Copy resources to FMU", which will embed the file in the FMU directly if checked. If unchecked, the file will be looked for in the specified directory.
Related
I'm trying to understand mapping of URIs to files. Let's take this URI:
modelica://foo.bar/file.png
Is it correct that there are two possible locations for file.png?
It could be either
$MODELICAPATH/foo/file.png if file $MODELICAPATH/foo/bar.mo exists.
Or
$MODELICAPATH/foo/bar/file.png if file $MODELICAPATH/foo/bar/package.mo exists.
Likely Section "13.2.3 External resources" of the Modelica Language Specification helps.
A little modification of your example should help to understand how it works. Using modelica://foo/bar/file.png refers to foo as top-level package/library. The library the path is resolved when it is loaded in the simulation environment. In case you store the library hierarchically (i.e. every package is represented as folder, each model is a file) bar would be a subfolder within the libraries root directory. file.png would be the file name within bar.
This is different if the package is stored as a single file, but as this has several disadvantages I would recommend to go with the hierarchical option.
No need to edit $ModelicaPath$ if the library is loaded.
Usually pictures etc. are put into a Resources folder within the library. This folder can contain additional folders like data, Images, Scripts...
In JModelica I want to create models using components from multiple existing libraries.
This means that it would be very useful to add the multiple libraries to the MODELICAPATH so components can be referenced without changing their existing paths. Something similar seems possible in Dymola.
In JModelica 1.13 it seems that this was once possible using:
c_opts =
{'extra_lib_dirs':['c:\MyLibs1','c:\MyLibs2']}
compile_fmu(class_path, compiler_options=c_opts)
I have read through the JModelica 2.1 document and there seems to be no mention of this argument. I have also tried running the script above and the compiler is not able to locate the path of the model contained within a library listed in the options.
Adding libraries to the Third Party MSL Folder inside the JModelica installation is not an option, as the multiple libraries I'll be working with are GitHub repos.
Is it possible to add these multiple libraries to the MODELICAPATH via startup script or IPython code?
The option "extra_lib_dirs" has been removed in favour of the simpler interface:
from pymodelica import compile_fmu
name = compile_fmu("MyModel", ["MyModelicaFile.mo", "C:\My\Modelica\Lib", ...])
The list after the model is specificed can take any number of Modelica files or directories to where Modelica libraries are located.
Yes, JModelica.org looks at the environment variable MODELICAPATH for additional locations of Modelica libraries (as per the Modelica language specification, section 13.2.4).
Either you modify the variable in batch before starting JModelica.org, or you modify the environment inside Python:
import os
os.environ['MODELICAPATH'] = "C:/somePath/;" + os.environ['JMODELICA_HOME'] + "/ThirdParty/MSL"
from pymodelica import compile_fmu
compile_fmu("SomeLibrary.SomeModel")
Note, if you're going to compile models from MSL or models using parts of MSL, then you have to add the MSL folder from the JModelica.org installation to the MODELICAPATH as well. The reason for this is that we are overriding the default MODELICAPATH and JModelica.org uses MODELICAPATH to find MSL.
I might add that it is more efficient to add the library folders to MODELICAPATH than listing them in the compile_fmu command. The reason for this is that if you list them to the compile_fmu command, then all the libraries will be parsed, while, if you add them (or rather the parent folder) to MODELICAPATH, then they are loaded as needed.
I have a Simulink model, the purpose of which is automated code generation.
My model uses S-functions (developed by another party), which has hard-coded assumptions about the path. For instance, several external data files are needed, which are referenced in the S-function via a relative path like ..\Bin\data\datafile.bin. This makes it necessary to set MATLAB's current working directory to a specific path before the model can be run.
I can automatically check and set the correct path via model callback functions. However, all model callback functions only seem to be related to the simulation process, not the build process. That means that I can run the model irrespective of what directory I'm in, but when I try to build the model, it always fails unless I manually navigate MATLAB back to the correct directory.
Needless to say, that's quite annoying. So I was wondering if there is something like a "preBuildFcn" callback fnuction, a function that is run before starting the build process? Any other solution (that does not involve modifying the S-function) is also very welcome.
There are plenty of hooks into the build process of Simulink / Embedded Coder ('entry', 'before_tlc', 'after_tlc', 'before_make', 'after_make', 'exit', and 'error'). I assume you want an 'entry' hook.
All you need to do is write an M-function with the name your_system_target_file name_make_rtw_hook, as explained in the documentation Customize Build Process with STF_make_rtw_hook File.
In case you can't open the online documentation (login required), here is the path to the HTML in your MATLAB installation: MATLAB root\help\rtw\ug\customizing-the-target-build-process-with-the-stf-make-rtw-hook-file.html
I am not sure whether building simulink models is sufficiently similar to building regular MATLAB programs, but here is what I used in the past:
Set up the project manually
Build the project programmatically
The program that is used to build the project should be able to set the path or do other custom things.
I have created a small Modelica library of my own. The way I have created it is in a single file. But I would like to make it a proper Modelica Library, as in the one with multiple directories for each subpackages.
So this is what i followed. File > New Modelica Class > Specialization - Package > Unchecked Save contents in one file. I copied the entire package code from the single file library, pasted it here and saved it. while doing so, I've noticed that the library lost most of its extends clauses, few models went missing.
Have I followed the correct procedure to create the library or did I do something wrong?
Can anyone point me towards the right direction?
#MSK, I cannot help you with OpenModelica as I work with Dymola. I did however recently split a single-file library (called package in Modelica) into several files manually. I did this so that the library hierarchy is represented in the file system hierarchy (i.e. several subfolders and .mo files in a library folder). For 35,000 lines of code this took roughly 10 hours. Just follow these steps:
create folder with same name as library
in this folder, create a text file "package.mo"
"package.mo" has to start with the statement
within ;
package [name of your package, i.e. the folder name...without the brackets];
now you want to create a subclass within this package. To do this create another folder containing a text file called "package.mo"
start this "package.mo" with
within [name of your package];
and declare the model as usual.
continue all the way down your library hierarchy
at the lowest hierarchy level you no longer need to create folders. You can simply create a .mo with the name of the lowest level class. As usual, start this file with
within [name of your package].[subclass1].[subclass2];
For an example of implementation please refer to the Physiolibrary found at https://www.modelica.org/libraries or the Modelica Standard Library which also uses this structure.
I have been trying to find out how to deploy a Simulink model. There are possibilities and problems as well.
If I use Simulink Coder how can I find the generated code on my computer? Where is it saved as a file or package of files?
Can we deploy Simulink as .NET Assembly? If we can, where can I find a detailed documentation about it.
Is there any other way to use my Simulink model standalone?
Thank you for any effort.
By default all the code gets placed into a folder, in the current directory, called ModelName_CodeTarget, where ModelName is the name of your model and CodeTarget is the particular type of code you are generating. (This folder is created during the build process if it doesn't already exist.)
There is no mechanism for automatically generating a .Net assembly. Simulink Coder generates C code; what you do with it is then up to you (just as it would be with hand written code). Note that the process is fully customizable, so you could create your own build process to autmatically wrap the C code into an assembly (but it would be a very advanced maneuvre to do this).
There are a couple of Simulink Coder "targets" that generate standalone executable files. For instance, the GRT (Generic Real-Time) target generates a simple .exe file; the RSIM target (the Rapid Simulation Target) generates an exe where you can specify different .mat files that can be used to specify different model parameters for different simulation runs, and have the results of the different runs stored to different output .mat files.
Most of these questions are answered by looking at the early chapters of the Simulink Coder documentation.
It would be worth you taking some time to look at it to get a feel for how the code generation process works.