Simulation executable generated with +simCodeTarget=Cpp fails if called by OMEdit

[rfranke]

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.

[rfranke]

Something like this patch should turn the crude error into a warning message:

SimulationRuntime/cpp/SimCoreFactory/OMCFactory/OMCFactory.cpp

@@ -55 +55 @@
           ("alarm,a", po::value<unsigned int >()->default_value(360),  "sets timeout in seconds for simulation")
           ("output-type,O", po::value< string >()->default_value("all"),  "the points in time written to result file: all (output steps + events), step (just output points), none")
           ;
-     po::command_line_parser(argc, argv).options(desc).allow_unregistered().run();
      po::variables_map vm;
-     po::store(po::parse_command_line(argc, argv, desc), vm);
+     po::parsed_options parsed = po::command_line_parser(argc, argv).options(desc).allow_unregistered().run();
+     vector<string> unrecognized = po::collect_unrecognized(parsed.options, po::include_positional);
+     if (unrecognized.size() > 0) {
+         std::cerr << "Warning: unrecognized command line options ";
+         std::copy(unrecognized.begin(), unrecognized.end(), std::ostream_iterator<string>(std::cerr, " "));
+         std::cerr << std::endl;
+     }
+     po::store(parsed, vm);
      po::notify(vm);
 
      string runtime_lib_path;

[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.

[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.

[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.

[rfranke]

The test is running. My machine isn't particularly fast, but I'm getting a lot of green messages in the console :-)

[adrpo]

Good. Don't worry about the failing test. Is actually succeeding and I'll update it.

[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.

[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.

[rfranke]

With r25220 the simulation executable at least survives a call by OMEdit.

[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.

[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.

[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".

[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.

[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.

[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

[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).

[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.

[adrpo]

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.

[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.

[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

[adrpo]

We'll see what happens in Hudson when the builds start working again.

[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.

[adrpo]

Seems that there are some issues in Linux. I'll try to fix them as soon as possible.

[rfranke]

r25299 and r25300 should solve the Linux issues

[rfranke]

r25301 adds support for OMEdit override. See comment:9 above.