Opened 9 years ago
Closed 9 years ago
#3233 closed defect (fixed)
Simulation executable generated with +simCodeTarget=Cpp fails if called by OMEdit
Reported by: | rfranke | Owned by: | rfranke |
---|---|---|---|
Priority: | high | Milestone: | 1.9.3 |
Component: | Run-time | Version: | trunk |
Keywords: | Cc: | mwalther, vwaurich, niklwors, adeas31 |
Description
Attempting to simulate a model from OMEdit with the option +simCodeTarget=Cpp, the simulation fails with the message:
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::program_options::unknown_option> >'
what(): unrecognised option '-port=38942'
It appears that the generated simulation program does not understand the port option passed by OMEdit. It works if started from the command line without options.
Change History (28)
comment:1 Changed 9 years ago by rfranke
- Cc mwalther vwaurich niklwors added
comment:2 Changed 9 years ago by rfranke
comment:3 follow-up: ↓ 4 Changed 9 years ago by adrpo
There is an available implementation of alarm for Windows in trunk/SimulationRuntime/c/util/omc_msvc.c.
On Linux/Mac one can use the available one.
comment:4 in reply to: ↑ 3 Changed 9 years ago by adrpo
Replying to adrpo:
There is an available implementation of alarm for Windows in trunk/SimulationRuntime/c/util/omc_msvc.c.
On Linux/Mac one can use the available one.
Ouch, this is about port, not alarm. Sorry.
comment:5 Changed 9 years ago by adrpo
Rüdiger, if you have a fast (Linux) machine you could run the testsuite and if nothing breaks commit the code and then have a look at (https://test.openmodelica.org/hudson/) hudson jobs OpenModelica_BUILD_CLANG and OpenModelica_TEST_CLANG to see if they don't break.
If you have easier commits that you're almost sure that don't break the code you can commit directly but have an eye on hudson. You can even register in hudson and you will get an email if some of the builds are broken by your commit.
To run the testsuite:
> cd path/to/where/OpenModelica/trunk/is/checkout > autoconf > ./configure ... # the configure I use is: > ./configure --with-omniORB CC=gcc-4.4 CXX=g++-4.4 --without-omc CFLAGS='-O2 -falign-functions' > make -jXX clean > make -jXX omc-and-runtimeCPPinstall > cd testsuite/partest > time ./runtests.pl
If you don't have a fast machine contact me and I can give you access to one of our development servers.
comment:6 Changed 9 years ago by rfranke
The test is running. My machine isn't particularly fast, but I'm getting a lot of green messages in the console :-)
comment:7 Changed 9 years ago by adrpo
Good. Don't worry about the failing test. Is actually succeeding and I'll update it.
comment:8 Changed 9 years ago by adrpo
To update a test you can do something like:
user@ccc:~/om/testsuite/openmodelica/cppruntime/libraries/msl32$ ../../../../rtest -b Modelica.Electrical.Digital.Examples.Counter.mos
In this case I also had to change the test type to do SimpleSimulation as it now started to work.
comment:9 Changed 9 years ago by rfranke
SVN r25202 commits the patch and it works as intended.
Now the command line parser of the Cpp runtime fails at another points though. The parser supports short options, like -o, and long options, like --OutputFormat. The OMEdit option:
-override=startTime=0,stopTime=1,stepSize=0.002,tolerance=1e6,solver=dassl,outputFormat=mat,variableFilter=.*
is parsed into
-o verride=startTime=0,stopTime=1,stepSize=0.002,tolerance=1e6,solver=dassl,outputFormat=mat,variableFilter=.*
and then an error is raised about a wrong output format...
Couldn't OMEdit and the C runtime follow more commonly used conventions, like -- for long options?
Moreover, why is a nested options string used for experiment settings? Wouldn't individual long options simplify the command line parsing, like:
--startTime=0 --stopTime=1 --stepSize=0.002 --tolerance=1e6 --solver=dassl --outputFormat=mat --variableFilter=.*
Consensus about the option names might be reached by following the naming of the Modelica experiment annotation.
comment:10 Changed 9 years ago by rfranke
With r25220 the simulation executable at least survives a call by OMEdit.
comment:11 Changed 9 years ago by rfranke
It not only survives, it also works and the results can be plotted in OMEdit!
There is one remaining issue: the Cpp backend generates an executable with the name OMCpp<model>Main and a shell script with the name <model> that calls the executable and provides simulation settings. Under Linux an additional symbolic link to the shell script is created (see also r25203). This way OMEdit finds the executable under Linux, but not under Windows. The algorithmic debugger does not find it at all.
Would you mind if I remove the shell scripts and the link and directly generate an executable with the name <model> instead?
The experiment settings would go into the main function -- note that some of them are mandadory, like the path of the runtime environment. If someone needs to change the settings, then he/she can also do this in the file OMCpp<model>Main.cpp.
comment:12 Changed 9 years ago by niklwors
we need the bat file, because we have to set the path variable for dll search path under windows. We can also easily change simulation parameter without rebuild the model.
comment:13 Changed 9 years ago by mwalther
We had a similar issue with our Jenkins test server, running with a python test suite. If you type something like "subprocess.Popen(<model> ...)" in python, than it searches for an executable named <model>. But if it does not find one, it automatically searches for a file named "<model>.sh" and executes it. But this was not working on windows, because python does not search for "<model>.bat".
Anyway, maybe such an solution can be implemented in OMEdit? First search for an executable named "<model>" an if this fails, search for an skript named "<model>.bat" or "<model>.sh".
comment:14 Changed 9 years ago by rfranke
Or, if <model>.bat is needed, then generate <model>.bat and <model>.exe such that options passed via <model>.bat would override the default options built into <model>.exe.
comment:15 Changed 9 years ago by niklwors
if that bat file and the exe file have the same name, CevalScript.mo can not call the bat file, which is needed to start correctly the simulation.
comment:16 Changed 9 years ago by rfranke
This might be the reason for some strange observations. OMEdit builds <model>.exe if selecting the C runtime. New simulations never delete old files, but just generate new files in the same OMEdit folder. Meaning that after changing to the Cpp runtime, there find:
<model.exe>
OMCpp<model>Main.exe
<model>.bat
comment:17 Changed 9 years ago by adrpo
One solution (a bit weird) would be to generate Model.exe also for CPP runtime which lauches Model.bat.
In CevalScript.mo we use the name of the model without bat or exe to be Linux friendly but we could add that for Windows so I don't think that's a problem (just an if).
comment:18 Changed 9 years ago by rfranke
I was thinking about extending the Windows makefile with some rm -f <model>.exe to clean it up.
From my side it would be great if CevalScript.mo distinguished .bat and .exe, so that we can make the Cpp runtime more in line with the C runtime.
comment:19 Changed 9 years ago by adrpo
- Cc adeas31 added
I would suggest to do it when we build a new model, clean Model.exe when a new model named "Model" is compiled be it for C or Cpp runtime. I will add that to CevalScript.mo to clean up Model.exe, Model, Model.bat, Model.cmd when a new model called "Model" is called.
Niklas, do you think it will work fine if we have Model.exe (instead of OMCppModelMain.exe) and Model.bat generated for Cpp runtime and run Model.bat when the Cpp runtime is active when simulate command is called.
Also, I talked with Adeel and we need a new API to check the "simCodeTarget" setting from OMEdit and look for Model.bat if "Cpp" is set. I will add that.
comment:20 Changed 9 years ago by niklwors
I recognized that we already distinguish between the bat call for the cpp runtime and the exe call for the c runtime. I will change the name for the exe file, that we have Model.exe and Model.bat.
comment:21 Changed 9 years ago by niklwors
Im not sure if the hudson test will work with this changes. Because in the script we call
./[Model] and we have a file [Model] and [Model].sh on linux
comment:22 Changed 9 years ago by adrpo
We'll see what happens in Hudson when the builds start working again.
comment:23 Changed 9 years ago by rfranke
I will extend the OMCpp<model>Main.cpp with the default options, so that a call to the executable without arguments will lead to the same result as a call trough <model>.sh. This is needed for OMEdit anyway. Arguments from <model>.sh will override the builtin args.
comment:24 Changed 9 years ago by adrpo
Seems that there are some issues in Linux. I'll try to fix them as soon as possible.
comment:25 Changed 9 years ago by rfranke
comment:26 Changed 9 years ago by rfranke
comment:27 Changed 9 years ago by rfranke
- Owner changed from somebody to rfranke
- Status changed from new to assigned
comment:28 Changed 9 years ago by rfranke
- Resolution set to fixed
- Status changed from assigned to closed
Something like this patch should turn the crude error into a warning message:
SimulationRuntime/cpp/SimCoreFactory/OMCFactory/OMCFactory.cpp
po::command_line_parser(argc, argv).options(desc).allow_unregistered().run();