Adding additional libraries to MODELICAPATH in JModelica - modelica

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.

Related

Create a package in Modelica

I am using Modelica in my work, where I have modeled a system that contains many models. I want to make it simple to use by creating a package using " within" so this package contains all the models. What I want is to open the package instead of opening many models, which takes time.
Instead of doing everything by hand, I suggest to create your packages with a Modelica tool (OpenModelica, Dymola, SimulationX, ...).
The tool will automatically create the folder structure and the within lines in the .mo files for you. Doing it manually is not much fun.
You could e.g. use OMEdit (part of OpenModelica) to create your package structure as follow:
create your top-level package via File > New Modelica Class
insert sub-models and sub-packages in existing packages via right-click > New Modelica Class
According to this website http://omwebbook.openmodelica.org/
A package is simply a container or namespace for names of classes, functions, constants, and other allowed definitions. The package name is prefixed to all definitions in the package using standard dot notation. An import language construct is provided for Modelica packages.
the package can help us to gather components that build the main model together in same place inside it , just by clicking on the package you open all your components inside it.
to open a package in Modelica we follow the follwing instructions:
After creationg the package you will get a folder with the package name in the place that you chosed to saved it in it , when you open the folder you click on package in order to open your package .
hope this can be helpfull

Exchanging Modelica FMU Models

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.

Creating Modelica Libraries

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.

Minimal references to PRISM/MVVM to have the support for commands

I am looking for information to which PRIMS/MVVM ddls I have to reference to in my project to have available Prism/MVVM functionality for handling Commands. I plan to use only this part of the frameworks.
Regards,
Wojtek
If you only want commanding support I would suggest to completely avoid Prism and that way you will reduce the size of your .xap file.
I would suggest you to look at the code (either in Reflector or open Prism's source) and copy to your project all the files in "Microsoft.Practices.Composite.Presentation.Commands" namespace in the "Microsoft.Practices.Composite.Presentation" assembly. You can ignore CompositeCommand.
If you prefer to reference the assembly, go with "Microsoft.Practices.Composite.Presentation". If you only use commands you won't need other assemblies. The compiler will tell you in case start using other classes from that assembly that depend on another one. The other two dependencies for this assembly (for classes other than commands) are "Microsoft.Practices.Composite" and "Microsot.Practices.ServiceLocation".

Don't expose symbols from a used library in own static library

I am writing a reusable static library for the iPhone, following the directions provided here.
I want to use minizip in my library internally, but don't want to expose it to the user.
It should be possible for the user to include minizip themselves, possibly a different version, and not cause clashes with my "inner" minizip version.
Is this possible?
Edit:
I've tried adding -fvisibility=hidden to additional compiler flags for minizip files and changing functions to be __private_extern__ and __attribute__((visibility("hidden"))), but it still seems to produce defined external symbols:
00000918 T _unzOpen
0000058e T _unzOpen2
00001d06 T _unzOpenCurrentFile
00001d6b T _unzOpenCurrentFile2
...
Edit #2:
Apparently the symbols marked with these annotations are only made private by the linker, which never happens when Xcode builds the sources, since it adds the -c parameter ("Compile or assemble the source files, but do not link.")
You could rename all exported symbol from minizip with objcopy.
something like
objcopy -redefine-sym=minizip.syms yourstaticlibray.a
and minizip.syms
_unzOpen _yourownprefix_unzOpen
_unzOpen2 _yourownprefix_unzOpen2
... ...
No clash if an executable is linked with an other minizip.a and yourstaticlibray.a, and because you renamed all the symbol in yourstaticlibray.a your call inside yourstaticlibray.a to minizip will use the prefixed symbol, and not the unzOpen one.
Since static library is nothing more than a set of .o files (which are not linked yet, as you have mentioned), the only way to completely hide presence of minizip from the outside world is to somehow compile minizip and your library together as a single compilation unit and make minizip functions/variables static.
You could have a look at how does SQLite do the "amalgamation" process which turns library source code into single .c file for further compilation: The SQLite Amalgamation.
As a bonus you'll get better optimization (really recent GCC and Binutils are able to make link-time optimizations, but this functionality is not released yet).