- Index
- » Users
- » sjoelund.se
- » Profile
Posts
+a is an experimental flag that is not supported by the OpenModelica backend
How do you mean? You simulate from 0.0 to 1.0 but get results from 0.0 to 0.999997?
You can try to use simulate(... , measureTime=true). It should at least list all non-linear systems and the variables that are part of them (if you did not find this out already).
It means the solver is trying to solve a non-linear system of equations but cannot find the solution.
Try these examples and you should realize why this happens. Sadly, the error-message is quite bad and does not provide all the information you need (it points to wrong equation-system)
Code:
loadString("
model M
Real x,y;
equation
x = sin(y);
y = cos(x);
end M;
");
simulate(M);
loadString("
model M
Real x,y;
equation
x*time = sin(y);
y = cos(x);
end M;
");
simulate(M);
As far as I know, OpenModelica only handles assertions, not terminate
Please do. I think it would work if you "port install paradiseo configure.compiler=macports-gcc-4.4". The paradiseo sources really seem to hate clang/llvm which is the new OSX default.
Code:
Login as Administrator
Logout, click Administrator. Enter your admin password. Open a terminal.
Code:
ssh root@localhost
If you have remote login enabled, you can login to any account you want...
Code:
su
Then type the password of the root account to gain a root shell
Code:
sudo su
Type your own password to gain a root shell
Code:
sudo sh
Type your own password to gain a root bourne shell
Or you could always just edit the file using sudo nano
Several choices:
Login as Administrator
ssh root@localhost
su
sudo su
sudo sh
After setting up a MacPorts installation, run (as root). Is not the same as running as sudo (sudo cannot redirect files unless you tee it). If you'd like to maintain OpenModelica on macports.org, feel free. It's too much work for me (I won't accept to maintain the horrible paradiseo and rml-mmc dependencies on macports).
Read the instructions carefully: http://openmodelica.org/index.php/download/download-mac
It will not work until you install our repository
Read the instructions carefully: http://openmodelica.org/index.php/download/download-mac
It will not work until you install our repository
What errors do you get when trying to install using macports? Problems with the openmodelica port, or problems with something in macports?
The platform name for FMI 1.0 on OSX is actually unspecified. And the new names for FMI 2.0 are totally weird (darwin64? doesn't even say what processor you're running...)
Ok. You need r11526+ for the first bugfixes to FMI. r11621 has some additional changes to make simulations work properly in Dymola import.
What revision of OpenModelica are you running? This should have been resolved in the trunk version.
No, it's not required. However, it is a reasonable coding style. And we can keep them and still support the translation according to that stackoverflow article.
The change is rather simple:
Create a static function initGlobalTranslationStrings(), called in main (after installing the Qt translator to the system, but before creating any GUI windows). This function should set up all the strings.
Code:
void initGlobalTranslationStrings(void) {
readOnly = tr("Read-Only");
writeAble = tr("Writeable");
iconView = tr("Icon View");
diagramView = tr("Diagram View");
modelicaTextView = tr("Modelica Text View");
documentationView = tr("View Documentation");
}
Or something like that.
Left side is a scalar for each loop iteration, while the right side is a 1*1 matrix. Since it always has type [1,1], you can call
Code:
scalar()
on the right side (or re-write it to not generate an array expression).
Yes, it's not supported: http://test.openmodelica.org/~marsj/MSL … rsive.html
Some of Modelica.Media is working, with Fluid in the works (possibly ready for the next OM release, but more probably 2 releases off)
It was not standardized yet, Adrian. Not even in the drafts if I remember correctly.
This is a complete model that you can use. However, it has connectors which need to be connected before the model can yield any useful results. Partial models are a little different in Modelica (more abstract; think: a rotational component with 2 connectors).
You can solve this easily by issuing "port install omniorb +python27". I'll see if I can make the port ignore python if it's not requested (you cannot force a dependency on a variant of a port in macports).
Is that the expected result or the wrong result? I know nothing about the machines...
MultiBody also works (except Fourbar1). Note that e.g. EngineV6 does work, but takes too long for me to test in this script. When it is killed because of a timeout, we do not get any feedback on how many phases succeeded, so it looks very red.
So to summarize, most of Digital and all of Media, Fluid is off limits. And most of the other models do work, with some exceptions (some of these models are modelled in a better way in MSL32, but if you look at that report you'll see why we won't use MSL32 as a default anytime soon).
Code:
apt-get build-dep openmodelica
svn co https://openmodelica.org/svn/OpenModelica/trunk
cd trunk
autoconf
./configure '--disable-rml-trace' 'CC=gcc-4.4' 'CXX=g++-4.4' 'CFLAGS=-O2' '--with-omniORB'
make -j2 omedit
build/bin/OMEdit
Some localization was started on OMShell. If you wish to contribute some localization in OMEdit, feel free to make the necessary adjustments in the OMEdit trunk version. Getting commit access is not hard http://openmodelica.org:8080/cb, create a user, join the OpenModelica project.
Run apt-get build-dep openmodelica again to install the omniorb-python package.
I made the latest build as a binary:
http://build.openmodelica.org/omc/build … -11449.dmg
I think 11448 still had some issues as I had been neglecting OSX builds for so long. But I never saw an error like this. Maybe try "port clean openmodelica-devel"?
Shift-Command-Q - Log out
Maybe login/logout helps? Can also try the following:
Code:
echo "checkSettings()" > ~/tmp.mos
/opt/openmodelica/bin/omc ~/tmp.mos
rm ~/tmp.mos
But that means the command "g++" should be available and OSX should quit crying.
Try ls -lH /usr/bin/g++ to be sure the chain of symlinks point somewhere real. And try "g++ --version" from command-line to see if the file is executable.
Code:
sakura:~ martin$ ls -l /usr/bin/{g,}cc
lrwxr-xr-x 1 root wheel 12 Feb 10 07:54 /usr/bin/cc -> llvm-gcc-4.2
lrwxr-xr-x 1 root wheel 12 Feb 10 07:54 /usr/bin/gcc -> llvm-gcc-4.2
That's so odd. My XCode 4.2 installed gcc and g++ just fine. What is your output of
Code:
ls -l /usr/bin/{gcc,cc,g++,c++,clang,clang++}
No, there is not
First of all OM 1.6.0 is very old and I'd strongly recommend a newer one. Secondly, you should simply need to install XCode to get the gcc and g++ commands available.
Code:
loadString("model M
Real r = time;
end M;");
simulate(M,startTime=0, stopTime=1, numberOfIntervals=268435456);
// Produces 4GB M_res.mat - 2GB for time, 2GB for r
Code:
currentSimulationResult:="M_res.mat";
val(r,0.05); // Takes a long time as it reads the whole file to memory... Silly me
But it works.
I think our files become corrupt after trying to write more than 4,294,967,295 rows. The maximum file size is dependent on the number of variables in your equation, with the maximum being 4,294,967,295, giving 147573952589676412928 bytes when storing doubles.
But I don't know if there is an implementation bug that causes problems for smaller files since I did not program the mat-writer myself.
Maybe because of variable alias elimination. But I tried all of these on the latest version in Linux, and all of your examples do produce the correct results for me. Might be a Windows-specific issue or an issue with 1.8.0.
Simply open the package.mo and the rest will follow.
No version of OMEdit implemented Modelica 2.2 annotations. You may have some luck using SimForge, or converting the library to Modelica3 using Dymola (maybe).
Yes, you can have several version of OM installed. You need to set OPENMODELICAHOME environment variable before calling each client though.
jadoogar wrote:
Scripting 20:53:20 0:0-0:0 Requested package Modelica of version 2.2.2, but this package was already loaded with version 3.1. You might experience problems if these versions are incompatible.
This is a major problem if ThermoPower uses something in MSL that changed between 2.2.2 and 3.1. Many packages did, some did not. YMMV.
If you want to change the library path (you can then store your libraries where you like and enable/disable some depending on taste)...
Put one of the following depending on what the library looks like:
Code:
/opt/local/openmodelica/lib/omlibrary/ThermoPower X.X/package.mo (Binary package)
/opt/local/lib/omlibrary/ThermoPower X.X/package.mo (Default MacPorts path)
/opt/local/lib/omlibrary/ThermoPower X.X.mo
/opt/local/lib/omlibrary/ThermoPower.mo
Of course, copy all files that come with the library, but keep put either the .mo or package.mo in the correct path and the rest relative that
See this line when you run the simulate() command?
Code:
simulationOptions = "startTime = 0.0, stopTime = 1.0, numberOfIntervals = 50, tolerance = 0.000001, method = 'dassl', fileNamePrefix = 'Alias', storeInTemp = false, noClean = false, options = '', outputFormat = 'mat', variableFilter = '.*', measureTime = false, cflags = ''",
If you call
Code:
simulate(Model, variableFilter="x|y")
You only store time, x and y in the result-file. The syntax is a regular expression, which needs to match the whole name of the variable. You can google around for the exact syntax, we use "man 3 regex" REG_EXTENDED syntax.
Thanks. Added a tl;dr; bug report here: http://openmodelica.org:8080/cb/issue/1692
Could you provide a model that shows this behaviour? I have not seen this in any code myself and need a starting point if I'm going to fix it.
Writing to a variable beyond this limit is pointless since the nonlinear solver will not consider this and you will either get wrong result or a crash.
No, name, etc are attributes of the tag.
Code:
<tagName attr=value>
</tagName>
OpenModelica does handle UTF8 characters in filenames, classnames, comments, annotations. At least in Linux, where UTF8 is the default. For Windows, some of the defaults seem to assume Wndows-1252 encoding and OMEdit has not been updated to handle this.
Noone reopened http://openmodelica.org:8080/cb/issue/1 … ation=true so I'm assuming the next nightly build will be working on Windows...
Do you mean the following?
Code:
when sample(0.0 /* startTime */, 1.0 /* interval */) then
t_dummy = time;
end when;
Have you tried making t_dummy a discrete variable? Then you can set it in the when-clause without reinit.
Only state variables can be used in a reinit, and t_dummy cannot be selected as a state variable. (But apparently OpenModelica silently accepts this and you get the unexpected behaviour)
If you want a delay function, why don't you use the builtin delay function in Modelica?
Yes. I'll change it to stop being extremely stupid (value = actual expressions; ignoring the simplified one). That's a little better than failing to simulate.
We're pretty sure this subscripting is illegal, simply because a.y has undefined type (Real[1] or Real[2] depending on which element on a you access).
However, there is no answer to the ticket here: https://trac.modelica.org/Modelica/ticket/655
This now works in r11010 (the compiler simplifies the second expression to -1.0).
http://build.openmodelica.org/Documenta … MLDAE.html
But it's not been very well maintained the last few years so it might fail for some models.
Well, you could modify the existing file in-place. But that's almost the same as writing a new input file.
You'll have to attach or mail me a log so I can see what fails and what compilers, etc you use.
The builds are working at the moment: http://build.openmodelica.org/omc/builds/mac/x86_64/
With-qwt should point to /opt/local or whatever prefix you installed qwt at. It does some extra searching to auto-detect since qwt does not have a standard installation path (may be /usr/include/qwt, may be /usr/include/qwt-qt4)
How do you enter the commands and in what tool? If you enter the simulate and plot commands in the same command in OMNotebook/OMShell, note that you need a semicolon after the simulate command.
This is because qmake has no knowledge about other libraries and sucks at everything using frameworks. So we simply don't support it and build using macports instead (this was especially true for earlier versions where a build using the frameworks would simply crash; I haven't checked lately).
As for the config files. We have too many master students who don't care about consistency
That message confuses me a little. Did you use deb-src ... nightly-ubuntu (there is no such repository). You could also go back to -nightly and wait until 12:16 CEST and the new package should be built provided there is no bad check-in before 10:45.
The nightly-ubuntu package should work for you. Some people have commited code that doesn't compile the last few nights so no new build was made.
Looks similar to this problem: http://openmodelica.org:8080/cb/issue/1 … ation=true
Code:
$ svn log -r9222
------------------------------------------------------------------------
r9222 | adrpo | 2011-06-01 00:42:19 +0200 (Wed, 01 Jun 2011) | 20 lines
- BIG CHANGE!
- generate Model_init.xml instead of Model_init.txt
- clean objects in Model.makefile before compiling (Make doesn't seem to get that
Model.c is newer than Model.o if we issue two simulate commands for the same model,
even if the model changed via loadFile.)
- check the result of fflush in systemimpl.c and printimpl.c
- fflush in c_runtime/linearize.cpp
- added c_runtime/simulation_input_xml.h and cpp to read the Model_init.xml file.
- link the generated code with the XML parser library -lexpat as libc_runtime needs it now
- Model.c and Model_init.xml will now contain a GUID which is used in c_runtime/simulation_input_xml.cpp
to check if the Model_init.xml is matched with Model.c (Model.exe)
- The Model_init.xml is based on FMI but with much more information that we need for OMC.
- The Model_init.xml file it has no schema yet as it may change in the near future to include
more things that are now static in the generated code (Model.c). This will make compilation
of generated code faster.
- disabled testsuite/interactive-simulation/runInteractiveSimulation.mos and added only a
compilation test (more work is needed to make the run test more robust).
- updated tests and compiler files with the name change from _init.txt to _init.xml.
------------------------------------------------------------------------
As far as I know more static data was moved into the xml-file, but it's basically an FMI description with some extensions.
http://build.openmodelica.org/Documenta … yPath.html for omc scripting.
Or set environment variable TMPDIR=/home/user/tmp/. Many Unix applications look for this, and on OSX you get odd tmp-dirs like /var/folders/9m/y0z96n9j22dg43hldg3v19y0000102/T/.
No, there is not
The code you submitted doesn't compile so I tried to make a similar model:
Code:
model TestPde
parameter Integer l = 10 "lenght";
parameter Integer n = 30 "Number of section";
parameter Real deltax = l / n "section lenght";
parameter Real C = 1 "diffusion coefficient";
parameter Real Ts(unit = "s") = 0.01 "time bettween samples";
discrete Real T[n](start = fill(0, n));
Real T0 = 0;
equation
T[1] = T0 "initial condition";
T[n] = T[n - 1] "limit condition";
for i in 2:n-1 loop
when sample(0,Ts) then
T[n] = pre(T[i]) + Ts * (C * ( pre(T[i+1]) + pre(T[i-1]) -2*pre(T[i])/ deltax^2));
end when;
end for;
end TestPde;
But this gives the error:
[a.mo:8:3-8:41:writable] Error: Variable T[2] is not referenced in any equation (possibly after symbolic manipulations).
Are you using the latest omc (nightly build)? Or what does your complete model look like?
Edit: Changing T[n] to T[i] success and the model then compiles in the latest OpenModelica
could you paste lines 168-177 of the file for me? it seems to be a colon instead of semicolon output from some place but it should help if i know what code was generated
The same options as before except skip these two.
--with-Coin is the old visualization that existed in OpenModelica. It has been replaced by the more powerful (and standardized) ModelicaServices API (although OpenModelica doesn't ship with any of the libraries that do provide graphical support).
SendData has been replaced by OMPlot (formerly plot3, now renamed to plot to keep the old functionality). OMNotebook no longer supports inline graphs and visualization as it used to.
None of these configuration options was actively maintained. In Linux, OMNotebook couldn't use the inline graphing and on Windows we were unable to compile with Coin3D.
Fixed in r10892
Code:
loadString("model PreMatrix
Integer x[2,2] = integer(time*fill(1,2,2));
Integer y[2,2];
algorithm
for i in 1:size(x,1),j in 1:size(x,2) loop
y[i,j] := pre(x[i,j]);
end for;
end PreMatrix;","PreMatrix.mo");getErrorString();
buildModel(PreMatrix);getErrorString();
Generates:
Code:
/*#modelicaLine [a.mo:6:5-6:26]*/#
integer_array_create(&tmp0, ((modelica_integer*)&($Py)), 2, 2, 2);
(*integer_array_element_addr(&tmp0, 2, (modelica_integer)$Pi, (modelica_integer)$Pj)) = *(&$P$PRE$Px + ((modelica_integer)$Pi*2) + ((modelica_integer)$Pj));
/*#endModelicaLine*/
And yes I know the assignment code is damn stupid...
First of all the code is not valid Modelica:
Code:
[a.mo:9:1-11:9:writable] Error: Connector Port is not balanced: The number of potential variables (1) is not equal to the number of flow variables (0).
In newer OpenModelica, you need to fix your model (by using causal connectors) or use +std=2.x to ignore this error. The model succeeds to simulate for me, which suggests you simply need to update OpenModelica to the latest version.
OpenModelica says:
Code:
[/home/marsj/dev/trunk/build/lib/omlibrary/Modelica 3.1/Mechanics/MultiBody/Joints.mo:331:7-331:60:writable] Error: Model is structurally singular, error found sorting equations revolute1.R_rel.T[2,3] = revolute1.e[2] * revolute1.e[3] + cos(revolute1.phi) * ((-revolute1.e[2]) * revolute1.e[3]) - (-sin(revolute1.phi)) * revolute1.e[1];
revolute1.R_rel.T[2,2] = revolute1.e[2] * revolute1.e[2] + cos(revolute1.phi) * (1.0 - revolute1.e[2] * revolute1.e[2]);
revolute1.R_rel.T[1,3] = revolute1.e[1] * revolute1.e[3] + cos(revolute1.phi) * ((-revolute1.e[1]) * revolute1.e[3]) - sin(revolute1.phi) * revolute1.e[2];
revolute1.R_rel.T[1,1] = revolute1.e[1] * revolute1.e[1] + cos(revolute1.phi) * (1.0 - revolute1.e[1] * revolute1.e[1]);
0.0 = atan2(-revolute1.R_rel.T[1,3],revolute1.R_rel.T[2,2]);
0.0 = atan2(revolute1.R_rel.T[2,3],revolute1.R_rel.T[1,1]);
for variables revolute1.phi(17), revolute1.R_rel.T[2,3](13), revolute1.R_rel.T[2,2](12), revolute1.R_rel.T[1,3](10), revolute1.R_rel.T[1,1](8),
Dymola 7.4 demo says:
Code:
The model includes the following hints:
All Forces cannot be uniquely calculated.
The reason could be that the mechanism contains
a planar loop or that joints constrain the
same motion. For planar loops, use for one
revolute joint per loop the joint
Joints.RevolutePlanarLoopConstraint instead of
Joints.Revolute.
How it came to that conclusion I have no idea.
More recent OpenModelica versions automatically load ModelicaServices when Modelica is loaded
Oh, my bad. I keep forgetting a semicolon in OMNotebook/OMShell supresses the output. So remove the last ; after runScript and it should print the output.
Yes, you can do that. It might be better to run OpenModelica script-files from command-line:
Code:
omc a.mos
You can also run the same script from OMShell/OMNotebook:
Code:
cd("/path/to/workingDir/");
runScript("a.mos");
The advantage of running the script from command-line is that you get incremental progress. You can see how far OMC has gotten in the script, while OMNotebook/OMShell block the GUI until all commands have finished.
a.mos:
Code:
loadModel(Modelica);getErrorString();
simulate(Modelica.Mechanics...);getErrorString();
...
Is this for-loop in an algorithm or equation section?
To debug this I would need the output of checkSettings() in OMShell. As well as the output of "find /home/openmodelica" run from a terminal.
Fun bug
The link to the issue tracker is below, and I don't think I've seen this issue with sum-reductions before:
http://openmodelica.org:8080/cb/proj/tr … acker_id=1
Anyone registered to the codebeamer should be able to post bug reports.
Instead of setting your OPENMODELICAHOME (which you didn't set; you need to set it in a terminal and then launch eclipse from that environment), you could simply point to the omc executable /usr/bin/omc instead. OpenModelica is compiled with its prefix hardcoded so it knows where to look without environment variable magic.
Ok, this seems to be an issue so I'll add it to the bug-tracker (with the missing declaration of the record Value).
Edit: http://openmodelica.org:8080/cb/issue/1671
Yes, and then wait until next build finishes (as the current version still depends on omshell-terminal).
You can force an install, no problem (it's only a little unsafe). OMShell will then work and OMShell-terminal probably will not.
Code:
--force-yes
Force yes; This is a dangerous option that will cause apt to
continue without prompting if it is doing something potentially
harmful. It should not be used except in very special situations.
Using force-yes can potentially destroy your system! Configuration
Item: APT::Get::force-yes.
Or wait a day or so and nightly builds will allow OMShell to be installed without OMShell-terminal as a dependency.
Basically, Debian stable updated the readline version so the omshell-terminal package causes conflicts.
You can still
Code:
apt-get install omc omnotebook omedit omlibrary-msl31
Print.getString is correct.
It's printing to an external buffer (if you're used to Java, this is like a StringBuilder). You then need to retrieve this buffer and return it or print it to console (using print(str)).
The SimCode contains the following:
Code:
simple equation: result1 = value1
simple equation: result2 = if CondEnum.b == CondEnum.a then 1.0 else -1.0
simple equation: result3 = if CondEnum.b == CondEnum.a then 1.0 else -1.0
But the equations are actually not put in the generated code. I'll open up a bug for it (http://openmodelica.org:8080/cb/issue/1 … tion=true)
The source-package (deb-src http://build.openmodelica.org/apt nightly contrib) lists all dependencies to compile OpenModelica:
Code:
Source: openmodelica
Section: math
Priority: optional
Maintainer: OpenModelica Build System <build@openmodelica.org>
Build-Depends: debhelper (>= 7.0.0),
libsqlite3-dev,
libssl-dev (>= 0.9.8g),
libreadline-dev,
libqt4-dev (>= 4.4.3),
libqwt5-qt4-dev (>= 5.1.1),
liblpsolve55-dev (>= 5.5.0.10),
rml-mmc (>= 204),
openjdk-6-jdk | sun-java6-jdk,
libomniorb4-dev,
omniidl4 | omniidl (>= 4.0.0),
gnuplot,
xsltproc,
flex,
paradiseo,
bison,
libf2c2-dev,
liblapack-dev,
autoconf,
zip,
libexpat1-dev,
libsoqt4-dev,
libcoin60-dev (>= 3.1.3)
Standards-Version: 3.8.4
It's a lot easier to use
Code:
apt-get build-dep openmodelica
than installing the packages by hand though.
1.7 is too old for this API; you need to manually move libraries around or change the environment variable OPENMODELICALIBRARY
First install the MSL package (installed by default on OSX/Windows):
Code:
apt-get install omlibrary-msl221
Then load it:
Code:
loadModel(Modelica,{"2.2.1"})
I'll go out soon, but I can give you a quick reply:
http://www.mail-archive.com/openmodelic … 01133.html
Hope it's enough
They sure forgot to update a lot of makefiles for unix... 10464 should work as I just fixed it, did make clean and made sure it runs.
The files are undergoing some major changes and I guess a Windows developer made a breaking change for Linux. Try r 10442. It's my last commit and should be known good unless I forgot to update before committing.
So you x=y=0 and the charges are opposite so they attract each other and should stick there? The problem is the infinite power and low resolution of double precision floating point (as you could have guessed). I'm not sure what the best approach would be. Something similar to the above approach or possibly a when-clause that uses an external C function (then you can deal with the case that you get infinite acceleration and you can reinit() rx and ry to 0).
Did you see the pretty warning that says
Code:
rx <> 0.0
will not work as expected?
Anyway, you can tell DASSL what tolerance to use as when you get close to the 0, the system changes too fast. You also need to change the cutoff point from 0.0 to some epsilon close to zero.
Code:
loadString("
class Kulon
Real rx(start=0.1);
Real vx(start=2);
Real ax;
parameter Real q = 1;
parameter Real m = 1;
equation
m*ax = if noEvent(abs(rx) > 1e-12) then -(q*q)/rx else 0;
ax = der(vx);
vx = der(rx);
end Kulon;
");
simulate(Kulon,stopTime=5.0,tolerance=1e-3);getErrorString();
It's not available for Windows yet afaik. I can make a Mac build when it is released though.
Regarding the dropdown menu, do you mean the feature described in https://trac.modelica.org/Modelica/ticket/624 or something else? It's really hard to tell what you mean since we do not use Dymola (and the standard library is filled with Dymola-specific annotations).
Took me some time to find this post again since I only searched for my own posts. Seems I forgot to reply earlier, then...
Anyway, OpenModelica r10271+ now has this feature (in addition to a cancel simulation option instead of forcing users to kill processes themselves).
Fluid is actually loaded into OMEdit, but removed straight away due to complications (the OpenModelica kernel crashes for some of the Fluid models, which causes unsaved data to be lost; we do not want users shooting themselves in the foot).
In Tools->Options->Libraries, you can add your own read-only libraries to be loaded by OMEdit on each start.
Then you need to get an older OMOptim version (earlier than r9222)
Modelica.Fluid support is being worked on, it is not yet support (same for Modelica.Fluid.Dissipation)
What version of OpenModelica are you using? It seems to be compiling in the trunk version. The only issue I could find with it is that the result may be overwritten if you do not assign it to a real array right after the function call returns, i.e.:
Code:
function get_results
input Real m;
input String property;
input Integer n;
output Real res[n];
external "C" getresults(m, property, res) annotation(Include="
void getresults(double m,const char *str,double *res) {
res[0]=1.5;res[1]=2.5;
}");
end get_results;
function f
input Real r;
output Real res[2] := (get_results(r,"abc",2).+get_results(2*r,"abc",2)); /* This adds the first result to itself, only */
end f;
model M
Real res[2] = f(1.5);
end M;
Then your installed rml is probably not the latest revision. Note that I don't trust the rml makefiles for 2 cents so it's possible a clean compilation is required. But just to save you some time: if your /usr/local/bin/rml is older than 2011-09-25, it's not recent enough.
Does make clean (or simply rm -f Compiler/omc_release/*.{sig,sigx,srz}) solve it?
Update to a newer rml-mmc version
Ok, the latest version of OMEdit doesn't crash. It can load the file correctly, but not edit it (it will randomly move classes around or crash when modifying the class). I will forward this to Adeel
Still I can't see the full code, but if your OMEdit crashes on the Media models, you just need a newer version as I think it fixed some of these issues.
I would need to see a full exampl, but this will give a parser error as record extends needs a definition (i.e. ConstantRecord /* defs */ end ConstantRecord).
A few of them are still valid. Some have known problems that are still being worked on. Many of them are now invalid but noone has had time to check them all.
Go vote for bug #1515 if you want this fixed. Maybe Willi forgot about it
http://openmodelica.org:8080/cb/issue/1515
It is not only possible to run several simulations in parallel; it is also very efficient and easy (especially on OS'es that support symlinking). You simply need to create one subdirectory for each process, symlink the executable and put one init.xml file in each directory.
It is also possible to run a single simulation in parallel, but this does not always yield faster code due to synchronization (several times per step vs. once per execution as described above).
Do what OMEdit does and program your own interactive client.
Read the system documentation CHAPTER 6 INTERACTIVE SIMULATION FACILITIES https://openmodelica.org/svn/OpenModeli … System.pdf
(user: anonymous password: none (4 letters)).
OMShell cannot perform interactive simulations. The only client shipped with OpenModelica that can do this is OMEdit.
Command-line omc (mos-script) is always best
As for the loading crashes... they should have been fixed in r10111
omc handles the code just fine. OMEdit on the other hand seems to have some issues with editing the package... (Note that I am talking about the trunk version of OMEdit; older versions may have crashed from it, new one only has trouble saving the model)
In r10094+ it will be possible to modify the config-file (on Linux ~/.config/openmodelica/omedit.ini) manually and add your custom libraries.
For example, this would change the MSL version to 3.2 and also load the LinearSystems2 package:
Code:
[libraries]
Modelica=3.2
ModelicaReference=default
Modelica_LinearSystems2=default
Yes, stream connectors should work in OpenModelica.
I think I would need the complete log in case it's built using -j2 or higher (the tail of the log looks suspiciously perfect)
Yes, you need to take some extra care as Modelica does not support external "C++".
You can force OMC to use a non-standard compiler (setCompiler("g++"); but your code might not work in other Modelica tools if they also use C compilers). Or you use the more portable solution: precompiled libraries with C symbols exported as entry points (as described below).
annotation(Library="myFile.o or myFile.a or myFile.so") if the function definitions have been exported using:
Code:
extern "C" {
void AddTwo(...) {
...
}
}
I installed the old lenny packages again and built the new rml-mmc. Newer versions should not require SML compilers to be installed for omc compilation. Hope this helps.
I'll see if it's possible to remove this dependency then. We build rml-mmc using MLton (ml-lex and ml-yacc are build-time dependencies that also pull in smlnj). Debian lenny had smlnj, and the package was kept on the upgrade to squeeze. Since then it seems Debian has removed support for Standard ML compilers...
I'll see what I can do - especially since the 32-bit build server is now broken
First of all, only keep one of the binary repositories in your config to make update faster.
As for the dependencies, try to install the failed ones one by one and see where the error comes from. Or simply apt-get install the packages listed below and go straight for the building step
libsqlite3-dev,
libssl-dev (>= 0.9.8g),
libreadline-dev,
libqt4-dev (>= 4.4.3),
libqwt5-qt4-dev (>= 5.1.1),
liblpsolve55-dev (>= 5.5.0.10),
rml-mmc (>= 204),
openjdk-6-jdk | sun-java6-jdk,
libomniorb4-dev,
omniidl4,
gnuplot,
xsltproc,
flex,
paradiseo,
bison,
libf2c2-dev,
liblapack-dev,
autoconf,
zip,
libexpat1-dev,
libsoqt4-dev,
libcoin60-dev (>= 3.1.3)
The problem is probably that Adeel is the only person working on maintaining OMEdit (most of the developers use only the command-line interface; myself included). Providing example models so he can verify bugs and understand them probably helps a lot. I prefer the bug reports myself because I can assign them to people who then get an email (not many of the developers read these forums).
In the Modelica 3.3 specification it will be clear that you cannot use models in functions: "A function may only contain components of restricted class type, record, operator record, and function; i.e. no model or block components."
This was always the case but not clearly stated. You are expected to extend a class and set the attributes in the modifier of the extends, i.e.:
Code:
model M
extends N(p=1.5);
end M;
or directly as a component:
Code:
model M
N n(p=1.5);
end M;
In OpenModelica r10002+ the syntax in the initial post works.
I believe Dymola is correct. delay is a vectorizable function, but OpenModelica does not support calling it as such. The following works:
Code:
block Variable3Delay "Delay block with variable DelayTime"
extends Modelica.Blocks.Interfaces.MIMO;
parameter Real delayMax(min=0, start=1) "maximum delay time";
Modelica.Blocks.Interfaces.RealInput delayTime;
equation
for i loop
y[i] = delay(u[i], delayTime, delayMax);
end for;
end Variable3Delay;
I'll see if I can solve it easily.
OpenModelica crashes because the runtime makes certain assumptions about integers. Such as if you have unknown dimensions, you assign to the whole array at once and not just a slice. It would be good to make this return an error message though
The Dymola 7.4 demo says:
Code:
Check of ArrayTestModel:
Error: For equation
for i in (1:dimensionOne) loop
aux = min(i, listSize);
outputList[i] = valuesList[aux];
end for;
found in class ArrayTestModel.ArrayExampleFunction, declaration window at line 15.
Error: Wrong number of indices in outputList[i].
There should be 2 indices.
Error: Wrong number of indices in valuesList[aux].
There should be 2 indices.
Errors detected in functions.
Check aborted.
ERROR: 3 errors were found
Drag and drop of custom models has been added. Loading custom libraries at startup has not as far as I know.
XML is even more annoying to parse than the OMC output though...
Anyway, the Java interface uses an ANTLR grammar. It works very well for the typed API. The untyped API is very odd, returning Ok instead of true and so on, so these calls usually have to be manually parsed. OMEdit used a lot of weird rules to try parsing the untyped API, instead of just rewriting the output to be in a sane format
While we do plan to make the OMC interface more powerful in the future (automatically generating idl files and entry-points to API calls), it's a long way off.
The OMC Java interface (http://openmodelica.org/index.php/resea … :msc:2009) is just a parser + runtime for casting the parsed objects to the expected types, so it's probably similar to what you are doing (except Java is a horrible mess to work with; needing tons of reflective API).
You can use Modelica.Blocks.Tables. Reading the contents of (anonymous:none) https://openmodelica.org/svn/OpenModeli … tables.cpp it seems that OpenModelica supports reading from mat-files. If Excel cannot export to Matlab format, writing a csv importer should not be hard for you to do. Do note though: The tables implementation is not very well tested and may be buggy (the code is not very readable). Also, the documentation for the tables seems to be Dymola-specific; each Modelica tool has to provide its own table interface.
The start value is used as an initial guess during initialization (which I believe comes before simulation according to the standard; although maybe that is never stated).
That will create a jagged array, and I suppose OpenModelica will have some major issues with it (as you found out).
Basically, the assumption is that the following kind of code should work:
Code:
model N
parameter Integer n;
Real r[n];
end N;
model M
N[2] n(n = {3,4});
equation
n[:].r = {{1,2,3},{4,5,6/*,7*/}}; // The 7th element cannot be used here, because any array has to be rectangular...
end M;
The code as written works in OpenModelica, but I believe it should not. Loading this code in Dymola 7.4 causes a segmentation fault! I suppose I should open up a modelica.org ticket to ask for clarification if this is allowed or not
The following works in Dymola, but not OpenModelica, and I believe this should be legal at least
Code:
model M
N[2] n(n = {3,4});
equation
n[1].r = {1,2,3};
n[2].r = {4,5,6,7};
end M;
Per fixed this in r9956. If you are using Linux/OSX nightly builds, it will be out in 26 hours or so. If you use Windows, I suppose you need to wait for the next 1.8 beta or nightly build.
Oh, I read the order of the indices wrong (just assumed it was i outer-most). The code should work... As should this smaller example:
Code:
connector Signal
parameter Integer n;
Real values[n];
end Signal;
model ArrayOfSignalsTest
Signal mySignals[1](each n = 3);
equation
mySignals[1].values[2] = 1;
end ArrayOfSignalsTest;
I'll create a bug for it: http://openmodelica.org:8080/cb/issue/1 … ation=true
The problem is that you are doing something similar to:
Code:
XXX[2] a;
a[3] := ...;
That is, the index is out of bounds (and boy would such an error message be easier to interpret...)
Regarding how to retrieve the build number:
In Linux/OSX just call getVersion(), or check the version that your OMEdit/OMNotebook/OMShell/MDT says you are using. In Windows, write the revision on a post-it when you install OMC
terminate is basically the same as assert(false,msg), but should exit with a success rather than failure. So you are using it correctly. However, not a lot of libraries rely on terminate so the OpenModelica runtime does not yet support it (it used to, but was accidentally removed when trying to fix assert for multi-step solvers). Also see bug #1515: http://openmodelica.org:8080/cb/issue/1 … tion=true.
These should all work in r9802 (available in 26~27 hours from now)
That error is related to the first one I think.
One equation has l[1]/*OTHER*/.sIn/*REAL*/ instead of l[1]/*DAE.ET_COMPLEX():unknown*/.sIn/*REAL*/. The internal type gets messed up somewhere and causes getVar() to fail, which means it think it has an equation without any variable in it.
Seems to be an OpenModelica error for sure
Code:
Variables (5)
=========
1: output l[1].sOut:VARIABLE() .TestArray, .Loop, .Real type: Real [1]
indx = -1
2: input l[1].sIn:VARIABLE() .TestArray, .Loop, .Real type: Real [1]
indx = -1
3: sOut:VARIABLE() .TestArray, .Real type: Real indx = -1
4: sIn:VARIABLE() .TestArray, .Real type: Real indx = -1
5: $dummy:STATE(fixed = true ) type: Real indx = -1
Equations (5)
=========
1 : l[1].sOut = l[1].sIn
2 : sIn = time
3 : l[1].sIn = sIn
4 : l[1].sOut = sOut
5 : der($dummy) = 0.0
number of rows: 5
1:2 1
2:4 // sIn, OK
3:4 // sIn, NOT OK - l[1].sIn missing
4:3
5:5
Anyway, you can avoid the error by using setCommandLineOptions("+preOptModules=removeFinalParameters,removeEqualFunctionCalls,expandDerOperator,removeSimpleEquations")
This will cause the offending optimization module to not run
I get (after changing order of optimization modules):
Code:
Error: An independent subset of the model has imbalanced number of equations (2) and variables (1).
variables:
sIn
equations:
1 : sIn = time
2 : l[1].sIn = sIn
So something is probably wrong with the incidence matrix (it splits the equation-systems based on it); I'll have a look.
This is a bit too complicated math to do in my head, trying to figure out if using an inverted matrix causes performance issues. If you have problems then I guess it does (dense matrix scales O(n^2) instead of ~O(n) for a sparse matrix).
Ok. +d=bltdump does not output the (final) optimized version of the dae. It's simply the form of the dae after matching+index reduction (so you would miss late inline, etc). Try +d=dumpindxdae instead; it might help a little.
As for b*inv(a). Are you symbolically inverting the matrix or doing it numerically at each time step?
A better way to make RT deadlines than trying to remove simple equations is to try to reduce the number of non-linear equations. Try for example (but on your real model):
Code:
loadModel(Modelica);
loadString("
model circuit
import Modelica.Electrical.Analog.Basic.*;
import Modelica.Electrical.Analog.Sources.*;
Resistor R1(R=100);
Capacitor C1(C=0.000001);
SineVoltage V1(V=1,phase=0,freqHz=500);
Ground G;
equation
connect (V1.p, R1.p);
connect (R1.n, C1.p);
connect (C1.n, G.p);
connect (V1.n, G.p);
end circuit;
");
simulate(circuit,measureTime=true);
As for MNA, I assume it would change from state equations to algebraic ones as the number of equations and variables need to be the same in Modelica. Since you are using the model for a real-time simulation, the ODE function would be called only once (cannot use DASSL in real-time), so the opcount should be the same regardless (unless MNA somehow simplies the calculation a lot).
As far as I know, we always solve the system as an ODE.
I'm assuming you don't need to save a result-file then? Would an optimization that reduces the number of equations in functionAlgebraics be helpful (i.e. basically remove all equations in the following model)?
Code:
model M
Real r = 1.5*time;
Real y = 5.0*time;
Real z = r;
end M;
Willi fixed this in r9767, so this will work in the next build we release.
Adrian Pop said he expect Media in November (there were some more problems with redeclare that took longer than expected), Fluid is expected by March.
I created a bug in the tracker for this: http://openmodelica.org:8080/cb/issue/1614
Changing solver to dassl seems to work; I am assuming it detects some problem and retries; someone with more knowledge of the runtime should have a closer look.
Now the following code generates a good error-message:
Code:
// name: IfElseIf
// status: correct
model IfElseIf
equation
if cond then
abc();
else if cond then
def();
end if;
end IfElseIf;
// Result:
// Error processing file: IfElseIf.mo
// [IfElseIf.mo:11:1-11:13:writable] Error: Parse error: Expected 'end if'; did you use a nested 'else if' instead of 'elseif'?
//
// # Error encountered! Exiting...
// # Please check the error message and the flags.
//
// Execution failed!
// endResult
What editor were you using? OMEdit shows 'elseif' as a keyword.
The problem is that you are using the pattern
Code:
if X then
...
else if X
...
end if;
With proper indentation it is easy to spot the problem:
Code:
if X then
...
else
if X then
...
end if;
end /* expected if */
(Use elseif instead of else if; it has a quite different meaning)
I will see if I can make the parser return a better error-message for this case; it seems that it is easy to make this syntax error as a novice.
The following works, but support is still experimental and very much work in progress. I suggest using the very latest nightly builds.
Code:
loadString("
model M
Real r=15.0*time;
end M;
");
translateModelFMU(M);getErrorString();
// Creates file M/M.fmu
The rules file (which is a makefile) uses e.g. $(MAKE) omc mosh omlibrary
I don't have a Linux machine in front of me, but I guess if you use MAKE="make -j2" apt-get -b source openmodelica it would compile in parallel (there should be no issues; macports uses parallel builds by default). If this does not work, I guess you would need to check the apt documentation for how to override the default make command.
I listed the number of equations that were generated after optimization. After flattening it will contain as many equations as there are variables (there is no way around that). But after optimization very few are left.
Thanks; I'll add this as an additional dependency in the build (debhelper usually finds these automatically, but apparently expat was a problem as you say).
So your system is similar to mine, then.
Code:
/home/marsj/matlab2009/bin/glnxa64/libexpat.so.1
/home/marsj/matlab2009/bin/glnxa64/libexpat.so.1.5.0
/home/marsj/matlab2009/toolbox/symbolic/mupad/glnxa64/lib/libexpat.so.1.0.0
/lib/x86_64-linux-gnu/libexpat.so.1
/lib/x86_64-linux-gnu/libexpat.so.1.5.2
/lib32/libexpat.so
/lib32/libexpat.so.1
/lib32/libexpat.so.1.5.2
/usr/lib/x86_64-linux-gnu/libexpat.so
The main difference seems to be /usr/lib/x86_64-linux-gnu/libexpat.so which is in your cache but not in locate?
Does the following work?
Code:
echo "int main() {return 0;}" | gcc -x c - -lexpat
And what does the following return?
Code:
$ locate libexpat.so
Well, you can modify the _init.txt using shell-scripting.
For example:
sed -i 's/.*a_a.x_x/2.5 \/\/ a_a.x_x/' B_init.txt
Note that newer versions of OpenModelica has changed format of the init-file to xml. Adding a scripting command to change parameters directly in CORBA/OMShell is on my TODO-list
You can call system("./MyFile") via CORBA to run an external command.
I tried a serial RC circuit in OMEdit and got only 2 equations...
eq: capacitor1.n.i = sinecurrent1.signalSource.offset + (if time < sinecurrent1.signalSource.startTime then 0.0 else sinecurrent1.signalSource.amplitude * sin(6.28318530717959 * (sinecurrent1.signalSource.freqHz * (time - sinecurrent1.signalSource.startTime)) + sinecurrent1.signalSource.phase));
eq: der(capacitor1.v) = DIVISION(-capacitor1.n.i,capacitor1.C,"(-capacitor1.n.i) / capacitor1.C because capacitor1.C == 0");
Parallel RC gives 4 equations (4th comes from the conditional heat port):
eq: capacitor1.n.i = DIVISION(capacitor1.v,resistor1.R_actual,"capacitor1.v / resistor1.R_actual because resistor1.R_actual == 0");
eq: resistor1.LossPower = capacitor1.v * capacitor1.n.i;
eq: der(capacitor1.v) = DIVISION(-capacitor1.n.i,capacitor1.C,"(-capacitor1.n.i) / capacitor1.C because capacitor1.C == 0");
eq: sinecurrent1.n.i = (-(if time < sinecurrent1.signalSource.startTime then 0.0 else sinecurrent1.signalSource.amplitude * sin(6.28318530717959 * (sinecurrent1.signalSource.freqHz * (time - sinecurrent1.signalSource.startTime)) + sinecurrent1.signalSource.phase))) - sinecurrent1.signalSource.offset;
How did you check how many equations were generated?
It is if you are running Linux or OSX nightly builds.
The allocation issue is now fixed in trunk (r9666), but DASSL does not like the model using default start/stop time and step size:
Code:
DASSL-- AT T (=R1) SOME ELEMENT OF WT
In above message, R1 = .2000020000000E+00
DASSL-- HAS BECOME .LE. 0.0
DASSL-- ACTION WAS TAKEN. RUN TERMINATED
DASSL-- THE LAST STEP TERMINATED WITH A NEGATIVE
DASSL-- VALUE (=I1) OF IDID AND NO APPROPRIATE
In above message, I1 = -3
This model just barely compiles. It contains a mixed system of size 15 (262k elements) and allocates a 29x29 matrix in each iteration (and free'd after each time step only). This matrix does not need to use the memory pool as I believe its sizes are known during compile-time. I will try to move it to use stack memory instead.
Makes me happy
It's not really fixed. It won't work for \\, \n, \a and more funny things OMC may sometimes return
I think you could open the console window and send two commands:
deleteClass(Modelica)
loadModel(Modelica,{"3.1"})
And I think it might even work by only calling loadModel(Modelica) (not deleting the old one)
OMEdit removes Modelica.Fluid and Modelica.Media on load because OpenModelica has issues with them
Switching to euler or rungekutta often means no errors are generated in the log, but the simulation finishes anyway. And you will have some numerical errors. I'm not an expert in either numerics or modelling, so I can give little help here. I just know that for certain models and step sizes, some solvers error out while they work well under different circumstances.
Fixed in r9547 simply means it is fixed in r9547 of OpenModelica (if using Windows, the MSI should have said which version of OpenModelica it was built from). The latest Windows build is 9366; latest Linux is 9547.
This code generation issue is fixed in r9547. When trying to run the simulation I got DASSL errors though (but I don't know if the default simulation settings were correct or not).
Code:
DASSL-- ACTION WAS TAKEN. RUN TERMINATED
DASSL-- THE LAST STEP TERMINATED WITH A NEGATIVE
DASSL-- VALUE (=I1) OF IDID AND NO APPROPRIATE
In above message, I1 = -3
Ok, the code contains stuff like this:
Code:
CODEGEN_COULD_NOT_HANDLE_ASUB(tmp4857[(modelica_integer)$Pi, (modelica_integer) 4]);
I will have a closer look.
I would need to see the Modelica sources to give any help
You can run the following on Linux (and Windows if you setup paths correctly... which is a pain):
Code:
omc +s MyModel.mo Modelica
make -f MyModel.makefile
./MyModel
Or you can run:
Code:
omc MyModel.mos
MyModel.mos:
Code:
loadModel(Modelica);
loadFile("MyModel.mo");
simulate(MyModel, ...);
plot(x)
Or use plot3 instead of plot as it is nicer
There is also no need to set OPENMODELICAHOME or OPENMODELICALIBRARY anymore, so the instructions may be ignored for most users
Yes, the OpenModelica backend does really odd things for some of these equations. It seems to scale O(n^3.5), which means very rapid degradation is quality. https://openmodelica.org:8443/cb/issue/ … ation=true has an example I submitted some time ago
Windows issues are so funny to look at. I'm assuming you installed the 1.7 release; the nightly build should work better http://build.openmodelica.org/omc/build … ly-builds/
I would upgrade to a more recent OpenModelica (say 1.7) as it has a lot better support of external Fortran functions and Lapack than 1.5 did.
It sometimes means that MSL was not loaded. To solve, call loadModel(Modelica). Also, it might mean that I forgot to copy down the full path: Modelica.Math.Matrices.inv ...
If you have the Modelica Standard Library, you can simply make a function call to Modelica.Matrices.inv
Because an -L-directive is missing. I'm adding it to the configure line (or you could set it in CFLAGS).
Where is your omniORB installed? (locate libomniORB4.so)
configure using --with-omniORB for the GUIs (OMEdit, OMNotebook, OMShell)
You also need -I for includes (should actually be LDFLAGS=-L... CPPFLAGS=-I..., but for gcc it works setting these in CFLAGS). -L is for the linker (libraries) and -I for the preprocessor (includes)
We now use the lpsolve installed on the system rather than the version we used to keep in subversion (I think). Where is your lp_lib.h installed? This does not really seem to be standardized in any system (we only check for lpsolve/lp_lib.h and lp_lib.h). Setting CPPFLAGS (-I/path/to/lpsolveincludes/) might work if it's in a really weird place.
svn update not working? http://openmodelica.org/index.php/developer/source-code
I'll start with sorting as that is easy to explain. Suppose you have equations:
b = a - c
b = 2 * c
c = log(time)
In order to solve a, you first need to evaluate b and c. So we sort the equations and execute them in a specific order:
(solve for c) c = log(time)
(solve for b) b = 2 * c
(solve for a) b = a - c
The optimizer handles these things and more (index reduction, alias elimination, etc). Although I would not really write analysis and optimization as two phases in a pipeline as they are intertwined.
The OpenModelica trunk uses:
Code:
#ifndef NAN
static union MSVC_FLOAT_HACK __NAN = {{0x00, 0x00, 0xC0, 0x7F}};
#define NAN (__NAN.Value)
#endif
Since some Linux distros only enable NAN if C99-mode is being used. Older OpenModelica versions (maybe the version you are compiling?) used NAN as it was. Try svn update and compile again
svn revision 205 (?) or greater is required I believe. r208 (2.5.0) is also available. Or it could just be that you have both an old and a new rml installed that messes things up (old rmlc, new rml)?
Then the compiled rml version is too old, I believe.
You should always install the rml binary. However, if you compiled using mlton, you need an additional command
Code:
$(MAKE) install
$(MAKE) -C compiler install-mlton
In OpenModelica, the environment variable is called OPENMODELICALIBRARY (). Do note however that the official library contains some errors that the OpenModelica-provided version does not have (which is also 3.1 build 6).
This is what the structure looks like on Linux (OPENMODELICALIBRARY=OPENMODELICAHOME/lib/omlibrary=/usr/lib/omlibrary)
Code:
$ ls /usr/lib/omlibrary/
Modelica 3.1 ModelicaReference 3.1 ModelicaServices 1.0
According to the Modelica specification, the directory name should be LibraryName<space><version>. OMEdit will load the preferred version (release versions before prereleases, etc), with no way of changing this behaviour (yet).
Your OPENMODELICAHOME should either be unset or be /opt/openmodelica (not bin/)
Try r9288. I found another place where OMNxxx_tempfiles was used...
Well. Your suggestion is already the one used (writing to the temp-directory that Qt believes is appropriate). The old code to create/remove this directory was still in place, but should now have been removed by me (r9274).
You can also skip calculating the sum of the errors by using:
der(myErrorEstimate) = my.Variable.To.Measure);
And then just call val(myErrorEstimate,stopTime)
Make sure your new qmake (or qmake-qt4 if you simply want to make an alias) is first on the path. Would make you compile using this version (might need to remove the qmake-generated Makefiles also).
Or simply use "make omc omshell omnotebook" and skip OMEdit.
Sort of. I think you can also hack around with the Uses annotation of Modelica 3.1/package.mo to load your library with its proper name (it still needs to be in omlibrary though). I have not tested this myself though. And OMEdit has not improved its support for these things a lot
What error does this produce?
Code:
echo "void main() {}" > a.c && gcc a.c -llpsolve55
Also, do you have lpsolve55_pic on your system? You can also try --with-static-lpsolve if you have liblpsolve55.a and libcolamd.a...
It's a new dependency of OpenModelica.
Code:
apt-get install libexpat1-dev
Yes and no. I've added a flag to statically link it, so hopefully it will not be needed in the next build.
I believe this is related to https://openmodelica.org:8443/cb/issue/ … ation=true
While you think that you modify just one parameter, OMEdit modifies all of them. And some of the modifiers are now illegal because of Modelica scoping rules. You can work around this by going into the text view and removing the text that sets parameters that you did not modify (i.e. T_rising = rising, etc).
If using:
Code:
./configure ... LDFLAGS=-L/path/to/readline/lib/
Make sure /path/to/readline/lib/libreadline.a exists
Or simply ./configure --disable-omshell-terminal to compile without readline (use Qt-based OMShell instead of readline-based OMShell-terminal). Note that RML 1.6 is way too old for OpenModelica.
Code:
$ rml -v
rml+mmc compiler version 2.4.8 built 2011-01-20 15:30
What does a "predefined" macro mean according to you?
Code:
annotation(Include="#define XXX(X,Y,Z) ((X)+(Y)+)Z))")
or something different?
- Index
- » Users
- » sjoelund.se
- » Profile