I am using Dymola 2017 (Compiler is Visual Studio 2013/VisualC++ 2013 express Edition (12.0)).
I tried to export different MSL examples (e.g. Modelica.Electrical.Analog.Examples.CauerLowPassAnalog) as FMU (co-sim and Model exchange). I imported the FMU back in Dymola. When I try to simulate the FMU, I get always similar error messages:
Here the FMU setting:
When I create an FMU of the example: Modelica.Electrical.Analog.Examples.CauerLowPassAnalog
The following files are created:
But when I open the file "LowPass.fmu" (as .zip file), there is just one file inside:
This is the first time the I work with the 2017 version - when I created a FMU with the 2016 version, there were always all files in the FMU.
Would be great, if someone could help me.
Thank you!
I was able to reproduce your error by importing and attempting to simulate an FMU while the current working directory was set within an existing Modelica package (i.e., a directory with the package.mo file).
To fix change your working directory to a folder without a package.mo file.
For example (cd c:/Documents/Dymola) and then import and run your FMU.
Hope that helps.
Below is my C:/Documents/Dymola folder once I create the FMU...
Everything can be deleted except the .fmu file and everything still works...
The meaning of the error message is that Dymola cannot find the extracted FMU library. It could be that your FMU is not properly extracted by Dymola.
I would first check the working directory (you can know that by typing cd in the Dymola command window), if the FMU is properly extracted there.
It might also help, if you change to a working directory close to the root (for exampe create a directory C:/tmp and cd to it), so that you don't run into problem with the path length limit in Windows.
Related
I have a difficulty. I can not add a library "FOTS Simulator" to the Simulink Library Browser in MATLAB.
I was reading the site "https://www.goddardconsulting.ca/simulink-creating-custom-libraries.html" but I cannot reproduce their result.
In my computer I have installed MATLAB in :
C:\Program Files\MATLAB\MATLAB Production Server\R2015a
And I created a "FOTS Simulator" folder. In this folder are several files, including "Slblocks". So this file is in:
C:\Program Files\MATLAB\MATLAB Production Server\R2015a\toolbox\FOTS Simulator
I ran slblock.m in a directory that is on the MATLAB path. However, I wrote Browser.Library = 'FOTS_2015a' (as you can see in the code below).
It should be noted that this file (FOTS_2015a) is in .slx format in :
C:\Program Files\MATLAB\MATLAB Production Server\R2015a\toolbox\FOTS Simulator
How do I make "FOTS Simulator" appear in the Library Browser?
Code:
function BlkStruct = slblocks
BlkStruct.Name = sprintf('FOTS Simulator')
Browser.IsFlat = 1;
BlkStruct.OpenFcn = 'FOTS_2015a'
Browser.Library = 'FOTS_2015a';
BlkStruct.MaskDisplay = ''
Browser.Name = 'FOTS Simulator';
% 'OFTS Simulator' is the library name that appears in the Library Browser
BlkStruct.Browser = Browser;
end
Many of the following steps are over-kill and not required, nonetheless I would suggest doing the following:
Close MATLAB
Start MATLAB
Remove your directory from the MATLAB path, saving the change so that it is permanently removed.
Close MATLAB
move or rename your slbocks.m file (so that effectively slblocks.m for your custom library doesn't exist)
Start MATLAB (do not cd into your directory)
Try to open your custom Simulink library by typing its name at the MATLAB command line. This should generate an error saying the library cannot be found. If the library can be found then go back to step 3.
Add your directory to the MATLAB path, saving the change so that it is permanently on the path.
Try to open your custom Simulink library by typing its name at the MATLAB command line. This should open your library. If it doesn't then for some reason MATLAB is not finding your library.
Close MATLAB
create slblocks.m for your custom library putting it in your directory
Start MATLAB
Start Simulink (by opening a model or creating one from scratch)
Open the Simulink Library browser
Your custom library should appear in the list of available libraries.
Is there a way to automatically load libraries, change to a certain working directory, etc. when launching Dymola?
The question is slightly ambiguous - the other answer is quite good for one scenario. (The openModel call in Step 2 can be modified.)
However, if you always want to launch Dymola in a specific directory etc it is possible using the GUI. How depends on version.
Dymola 2020 x (and later)
Allows changing start-up directory through File>Working Directory
And has Tools>Library Management>Modelica Path where you can add the directory containing your external libraries.
To make libraries appear preloaded you have to add a libraryInfo.mos script in the corresponding library; you can look at Modelica Standard Library in the Dymola installation for inspiration.
The latter is described in more detail in the section "More about libraries and the building of menus of libraries and demo" (somewhere in the User Manual).
Dymola 2017 FD01 (and slightly differently from Dymola 2016 FD01):
Change Directory (File>Change Directory)
Add to Modelica Path (File>Modelica Path)
Save those settings (Edit>Options>Settings: Select Startup and Modelica Path)
If you want to "preload" libraries there are some options:
In a startup script you can use import MyPackage; or openModel("...\\MyPackage.mo"); alternatively if you are administrator you could modify Dymola/insert/dymodraw.ini and add a line: Dymola5LibraryMenu "MyPackage" (technically it doesn't "load" - it just shows the library in the package browser).
An important difference is that changing dymodraw.ini keeps the library "loaded" even after "Clear All".
In recent years there are two options that might help you.
File>Library Management>Install This dialog allows you to open a
zip-file or something similar of a distributed library, install it,
update MODELICAPATH to find it again, and even update the File>Libraries
menu to include it for future use. All in one operation.
Simulation>Edit startup.mos If you prefer to edit the startup
script, this is the convenient way to find it end open it for
editing.
Here is a procedure which allows to load a set of libraries with one click.
It makes use of the fact that the dymola.exe can be started with a .mos script as first argument.
It is designed for situations such as
You are using Windows
You are working on one or more projects
Where every project requires a set of libraries to be loaded
Every project uses it's own working directory
Other users might collaborate, so they need the very same setup
Requirements
The setup is a bit of work the first time, but very quickly done for further projects. You need:
a start.mos file in your library
the environment variables DYMOLA_WD and MODELICA_LIBS
(This is only required to allow other users to use different paths for their libraries and working directories)
a file short-cut to dymola.exe
This is how start.mos looks like for a specific project (usually you only change the first two lines):
// user setup
libs = {"Buildings 6.0.0", "PhotoVoltaics", "MyProject"}
wd = "myproject"
// open all libs
lib_dir = Modelica.Utilities.System.getEnvironmentVariable("MODELICA_LIBS");
lib_dir = Modelica.Utilities.Strings.replace(lib_dir, "\\", "/")
for l in libs loop
openModel(lib_dir + "/" + l + "/package.mo");
end for;
// change to wd
wd = Modelica.Utilities.System.getEnvironmentVariable("DYMOLA_WD") + "/" + wd;
wd = Modelica.Utilities.Strings.replace(wd, "\\", "/")
Modelica.Utilities.Files.createDirectory(wd)
cd(wd)
Now you create a shortcut to dymola.exe in the windows file explorer. In the field Target you set
"C:\Program Files\Dymola 2020\bin64\Dymola.exe" "%MODELICA_LIBS%\MyProject\Resources\scripts\start.mos"
Example
Assuming a user has set the environment variables
MODELICA_LIBS = E:\modelica
DYMOLA_WD = E:\dymola_wds
the folder structure on the users hard disk must look as follows for the script above to work:
E:\modelica
|- Buildings 6.0.0
|- package.mo
|- ...
|- PhotoVoltaics
|- package.mo
|- ...
|- MyProject
|- package.mo
|- ...
|- Resources
| |- scripts
| |- start.mos
|- ...
Now the dymola.exe-shortcut is used to start Dymola, which will automatically load the required libraries for the project and change the working directory.
For another project a new shortcut is required, along with a new start.mos script.
This method has been tested for Dymola 2017FD01. Prior versions used a different method via a setup.mos script that is no longer available. As of this posting, there is no option to perform this actions via the Dymola GUI.
It can be easily accomplished via a .mos file with the steps shown below:
Create a .mos file in a location that makes sense. For example, C:\Users\USERNAME\Documents\Dymola\startup.mos
Add the actions desired to .mos file. For example, to load a library add openModel("C:\\Users\\USERNAME\\Documents\\ModelicaLibrary\\package.mo");
Dymola always puts its auto-generated files in the current working directory. It's often a good idea to have that location be the same location so there is no need to hunt down the location of output files. Therefore, at the end of the .mos file change the current directory: cd("C:\\Users\\USERNAME\\Documents\\Dymola");
If no shortcut exists to the Dymola.exe file, then create one.
Right click the shortcut and go to Properties. Under Shortcut>Target append "C:\Users\USERNAME\Documents\Dymola\startup.mos"at the end. The contents of that cell should now look something like this: "C:\Program Files (x86)\Dymola 2017 FD01\bin64\Dymola.exe" "C:\Users\vmg\Documents\Dymola\startup.mos"
That's it. When Dymola is launched from that shortcut the actions specified in the .mos file should be carried out.
Another suggestion where you don't need to hardcode your package into an environment variable of your operating system (and maybe more safe for inexperienced programmers):
Go to the folder where Dymola is installed (e.g. C:\Program Files\Dymola 2020).
Search for the Dymola.mos file in the insert-folder. 'insert' folder
Open the script (e.g., in notepad++)
Add the link(s) to your Dymola-library-package.mo file(s) here with the openModel statement
e.g., openModel("C:/IDEAS/package.mo"); Dymola.mos script
Save the script. Now, every time you open Dymola, your libraries will be loaded automatically.
I'm automating my build process, but I wasn't able to change the model_target_rtw folder to something different.
I'm not talking about CodegenFolder, but about the folder that's created inside it during compilation.
I'm currently working this around by renaming the folder after compilation, but it would be grate to remove that step.
The folder you are referring to is the RTW (Real Time Workshop) BuildDirectory.
You can get the value of BuildDirectory by running the command:
RTW.getBuildDir('MyModel')
See:
https://se.mathworks.com/matlabcentral/answers/274082-how-can-i-change-the-build-folder-of-a-model
Also look at this question:
Save generated code in a special folder in "rtwbuild"
If you run this command in MATLAB:
set_param(0, 'CodeGenFolder', 'C:\MyBuildDir')
and then run the RTW.getBuildDir command again you will see that the BuildDirectory has changed.
I have a Visual Studio 2010 solution that contains a library of functions, and I would like to be able to use MATLAB as one of several possible front-ends to this library. Therefore, I would like Visual Studio to automatically generate a mex file when I build the solution, without having to export all my build options and paths to mexopts.bat and open MATLAB to build the file from there. I have seen several suggestions to achieve something similar, for example in these posts:
Matlab 7.1+ and Visual Studio 2005
Compiling a MEX file with Visual Studio
How to use CMake and Visual Studio 2010 (64 bit) to build a MATLAB R2011a (64 bit) mex file?
However, they either seem a bit outdated (making references to files that are no longer to be found) or make use of external tools (eg. CMake). Does anyone know how to set up a new project (within the existing solution) in Visual Studio (2010 and newer) that will build a mex file for contemporary MATLAB releases?
After some experimenting with guidance from this page mentioned in the question, it seems like starting with an empty C++ project the following settings in the project's Property Pages are necessary and sufficient to build a working .mexw64 from Visual Studio 2010:
Configuration properties -> General:
Set Target Extension to .mexw64
Set Configuration Type to Dynamic Library (.dll)
Configureation poperties -> VC++ Directories:
Add $(MATLAB_ROOT)\extern\include; to Include Directories
Configuration properties -> Linker -> General:
Add $(MATLAB_ROOT)\extern\lib\win64\microsoft; to Additional Library Directories
Configuration properties -> Linker -> Input:
Add libmx.lib;libmex.lib;libmat.lib; to Additional Dependencies
Configuration properties -> Linker -> Command Line:
Add /export:mexFunction to Additional Options
$(MATLAB_ROOT) is the path to Matlab's root folder, eg. C:\Program Files\MATLAB\R2013a.
So far this has only been tried from a solution created from scratch and built for Matlab 2013a 64-bit. I assume that to build for 32-bit one only needs to change both occurrences of 64 to 32. I will update the post when I have confirmed that this works for an existing solution.
EDIT: As expected this works for projects added to existing solutions. Remember to set the new project to be dependent on the project that creates the library.
Edit 2: Following this question I can confirm that the above steps work in Visual Studio 2012, 2013, and 2017 too.
Quickly Setting up Visual Studio Projects for MEX files with a Property Sheet
All of the settings can be applied via property sheets, a mechanism for rapidly applying Visual Studio project configurations.
Steps:
Download the property sheet (MATLAB.props) from this GitHib repo.
It's short and sweet. I'd actual urge you to make your own to learn what's involved in the process. See the Property Sheet Details section below for a description.
Set the MATLAB root environment variables: MATLAB_ROOT for your 64-bit MATLAB installation, and MATLAB32_ROOT for any 32-bit MATLAB installations (e.g. C:\Program Files\MATLAB\R2014b\). This folder has the subdirectories bin, extern, sys, etc. Restart VS if it's opened.
Create an empty DLL project in Visual Studio, optionally creating a x64 solution platform. Do this by choosing "Win32 Project" and selecting DLL as follows:
In "Property Manager" (select from the View menu), for each project's build configuration, right click and choose "Add Existing Property Sheet...", and select the appropriate property sheet (32 or 64 bit). (See screenshot below)
That's it!
Just remember that when going between MATLAB to use your MEX file and Visual Studio to build a new version, it will be necessary to run a clear mex or clear specificMEXFileName to be able to overwrite it.
I build almost all my MEX files this way.
UPDATE (05/22/15): The file MATLAB.props now supports the Parallel Computing Toolbox for using mxGPUArray objects. If the toolbox path and library (gpu.lib) exist on your machine, they can be used. Just include the CUDA SDK "Build Customization" (that should be installed if you've installed the CUDA SDK and installed the Visual Studio integrations) to include cuda_runtime.h, etc. Finally, link with cudart_static.lib (but keep Inherit... checked or you will get other linker errors).
Property Sheet Details
There are only a few important settings in the property sheet:
Adding $(MATLAB_ROOT)\extern\include to the AdditionalIncludeDirectories paths (with inherited paths from parent configurations) -- the location of mex.h.
Adding $(MATLAB_ROOT)\extern\lib\win64\microsoft to the AdditionalLibraryDirectories paths -- the location of libmex.lib, etc.
Listing the libraries: libut.lib;libmx.lib;libmex.lib;libmat.lib.
Exporting mexFunction (it's a shared library): /EXPORT:mexFunction.
Setting the output file extention (e.g. .mexw64 for x64).
Not necessary, but it also specifies an output manifest that is NOT embedded in the library, sets MATLAB_MEX_FILE, and turns on generation of data required for profiling.
For completeness, note that there is a more formal "build configuration" system for project configuration, which includes a property sheet, but a loose property sheet is sufficient for setting up a simple MEX project.
A Note About -largeArrayDims
The -largeArrayDims option is a switch to the mex command in MATLAB that simply indicates not to define MX_COMPAT_32. So, in Visual Studio, you don't have to do anything since this is not defined by default. If you want the opposite behavior (-compatibleArrayDims), then define MX_COMPAT_32 in the Preprocessor section.
What's libut.lib for?
I include libut.lib, which provides a few nice functions for detecting a break (CTRL-C) from within a MEX file. The relevant declarations (although this is getting off topic):
// prototype the break handling functions in libut (C library)
extern "C" bool utIsInterruptPending();
extern "C" void utSetInterruptPending(bool);
For building/linking/compiling, automate visual studio with an extension or macro to
start a thin Matlab client (using -nojvm -noawt -nodesktop -nosplash commandline options, this starts in less than a second on my machine)
generate the binary by calling mex (including the other dependencies etc).
if debugging is activated, attached the visual studio debugger to your newly started thin matlab client(any break points you click in VS will be active).
I have automated this for visual studio 2010. This way, you work with your mex-wrapper entirely from the visual studio IDE, have 4 extra pushbuttons for debugging etc. Compile errors are echoed from a matlab terminal window instead of within Visual Studio. Find the Macros uploaded here:
http://www.mathworks.se/matlabcentral/fileexchange/39549-visual-studio-toolbar-for-mex-interface-with-video-tutorial
In SPSS 11 it was possible to specify relative paths. Example:
FILE HANDLE myfile='..\..\data\current.txt' /LRECL=533.
DATA LIST FILE=myfile /
...
This worked because apparently, SPSS 11 set the working folder to the path where the source .SPS file is saved. It seems that SPSS 18 always sets it's working folder to the installation folder of SPSS itself. Which is not at all the same thing.
Is there an option to change this behaviour? Or am I stuck with changing everything to absolute filenames?
Instead of a relative path, you could define a directory path and use it inside other file handle declarations to save typing:
FILE HANDLE directoryPath /NAME='C:\Directory\Path\' .
FILE HANDLE myFile /NAME='directoryPath/fileName.xyz' .
GET FILE='myFile' .
This will get the file: C:\Directory\Path\fileName.xyz.
The direction of the slashes may be important.
(Works in version 17)
If you use the INSERT command to run an sps file, it has an option to change the working directory to that location.
You could use the HOST command to SUBST a drive letter (on PCs) and reference everything through that.
You could define a FILE HANDLE to the common root location and use that in file references.
You could use Python programmability to find the path to the active syntax window and issue an SPSS CD command to set the backend working directory appropriately.
HTH,
Jon Peck
With Python, you can get the full path of the current syntax window (or any other one) and get its path. Using that you can issue an SPSS cd command to change the backend working directory accordingly.
If you define an environment variable, though, you can use that in file specifications within SPSS.
p.s. SPSS has an extensive set of apis and helper modules for Python (as well as for R and .NET languages). You can get information about this from SPSS Developer Central, www.spss.com/devcentral. All the language extensions are free once you have the base SPSS Statistics product.
Regards,
Jon Peck
Or use "CD" command to change your default working directory. See also:
http://www.spss-tutorials.com/change-your-working-directory/
For example, if your default directory is C:\project, then GET FILE 'data\data_file.sav'. will open data_file.sav from C:\project\data.
And then, a few minutes later, i came across this little python script from jignesh-sutar (see here: SPSS syntax - use path of the file.
With his python code you can use the path of the syntax file as starting point for all the paths in your syntax.