Simulation from OMEdit fails for Cpp runtime under Windows

[Rüdiger Franke]

The following model simulates under Linux and from command line under Windows.

model TableTest
  extends Modelica.Blocks.Tables.CombiTable2D(
      table = [0.0,   1.0,   2.0,   3.0;
               1.0,   1.0,   3.0,   5.0;
               2.0,   2.0,   4.0,   6.0]);
  annotation(uses(Modelica(version="3.2.2")));
end TableTest;

The 32bit Windows release of OpenModelica produces the following error when attempting to simulate the model from OMEdit:

C:/Users/Someone/AppData/Local/Temp/OpenModelica/OMEdit/TableTest/TableTest.exe -port=64319 -logFormat=xmltcp -override=startTime=0,stopTime=1,stepSize=0.002,tolerance=1e-6,solver=dassl,outputFormat=mat,variableFilter=.* -r=C:/Users/Someone/AppData/Local/Temp/OpenModelica/OMEdit/TableTest/TableTest_res.mat -w -lv=LOG_STATS -inputPath=C:/Users/Someone/AppData/Local/Temp/OpenModelica/OMEdit/TableTest -outputPath=C:/Users/Someone/AppData/Local/Temp/OpenModelica/OMEdit/TableTest

Simulation stopped with error in simulation manager: Simulation failed for C:/Users/Someone/AppData/Local/Temp/OpenModelica/OMEdit/TableTest/TableTest_res.mat with error in simulation manager:
Could not initialize system
Could not read start values. Current variable reference is 1
Simulation process failed. Exited with code 1.

Following observations are made:

• the simulation does not always fail. Press Re-Simulate to see the crash then
• the simulation runs from Tools -> OpenModelica Command Prompt (when omitting the -port option)
• when called from OMEdit, the simulator builds up a lot of memory for about 1 second, before it exits
• the Linux version warns about unknown -inputPath and -outputPath options -- these warnings don't appear under Windows

Looks like a newly introduced problem (e.g. caused by changed logging, new subdirectories in OMEdit folder, specifics of Windows build, ...).

[Adeel Asghar]

OMCompiler/SimulationRuntime/cpp/Makefile.omdev.mingw:84

USE_LOGGER="false"
ifeq ("$(USE_LOGGER)","true")
  USE_LOGGER_COMMAND=-DUSE_LOGGER:BOOL=ON
else
  USE_LOGGER_COMMAND=-DUSE_LOGGER:BOOL=OFF
Endif

This will always disable the Logger. So I guess Logger never worked on Windows.
It goes for all the other options set there in the makefile.

I changed it to,

USE_LOGGER=true

And got the following in OMEdit.

And this in terminal,

There are still some messages missing in OMEdit and I am guessing its because port is not properly closed when simulation executable is finished.

Someone need to look into this. In Windows we don’t have configure script so one need to pass these variables from top level.
Also inputPath and outputPath needs to be implemented as they are done for C runtime ​https://github.com/OpenModelica/OMCompiler/commit/1be2a07fd09f6bc5eab46ffcd568011d99d007be

[Rüdiger Franke]

The new options -inputPath and -outputPath appear like overkill. The latter also duplicates -r. OMEdit with Cpp seems to work even though the Cpp simulator ignores the new options. What is the use case for these options -- yes, new subdirectories were introduced, but the simulator still has a current directory. Should the new options possibly be removed again?

Commit ​da270f8 finalizes the Cpp logger (which should close the socket) and it changes the USE_LOGGER to "true" in OMCompiler/SimulationRuntime/cpp/Makefile.omdev.mingw.

Nevertheless today's nightly Windows build has USE_LOGGER=false. Can please someone with access to a Windows build system fix that?

Btw. Interestingly a repeated simulation works for the example today. Still I observe a strange behavior of the Variables window: it suddenly disappears when I try to resize it, or it cannot be resized unless the main window gets maximized; afterwards it can be resized. This, along with previously failing resimulate, sounds like a memory issue.

[Adeel Asghar]

As a fix for ticket #2909 a new directory is created inside the working directory with model name which contains the list of generated files. However, this raised a problem discussed in ticket #4583. To fix the problem -inputPath and -outputPath options are added.

Basically, the simulation executable reads and writes the files based on the its working directory. After the ticket #2909 is fixed, the working directory is the new directory that is created at the run-time. Now we have a problem that users can't provide the data files because they can't put the files in the new working directory. So in order to give the user the option to provide data files, the working directory is set to some valid directory. The simulation executable then fails to read the files since it expects the files to be in the working directory and not in the newly created directory. So the options -inputPath and outputPath are introduced.

Input path flag -inputPath is used to read the model_init.xml and model_info.json files. -f flag for model_init.xml file gets the preference over -inputPath.
Output path flag -outputPath is used to write the output files like model_res.mat, model_prof.intdata etc. -r flag for model_res.mat file gets preference over -outputPath flag.

[Francesco Casella]

@rfranke, this issue is marked as a blocker for the upcoming 1.13.0. Is this now working for you? If so, please close it, if not please update the status.

Thanks!

[Rüdiger Franke]

It seems to work when enabling logging and appropriately closing the stream

​https://github.com/OpenModelica/OMCompiler/commit/da270f8db8fe1c976cdaec3d34b430f21eb696db

and after the removal of wrong quotes in Makefile.omdev.mingw:

​https://github.com/OpenModelica/OMCompiler/commit/1453d7dd8749b799f3bed9fe7a80ffa4d9cfaf2b

[Rüdiger Franke]

Unfortunately the problem is back (or still there?); not under Linux, but under Windows with Win32 version.
The simulator runs without problem if I start it from the Command Prompt after OMEdit reported the failure. It also generates the correct results file that I can load into OMEdit afterwards.

Can it possibly be a timing issue, i.e. the input file is not yet there when OMEdit starts the simulator?

[Rüdiger Franke]

OMEdit does only fail for some models. Here two examples.

Modelica.Blocks.Examples.PID_Controller -- bad

init | error | <p>SimManager: Could not initialize system</p>
init | error | <p>SimManager: Could not read start values. Current variable reference is 9</p>
stdout | error | <p>Simulation process failed. Exited with code 1.</p>

Modelica.Blocks.Examples.Filter -- good

solver | info | <p>SimManager: Start simulation at t = 0.000000</p>
solver | info | <p>SimManager: Simulation stop time: 0.900000</p>
solver | info | <p>Simulation info from solver:</p>
...

[Adrian Pop]

Maybe some 32bit issues? On 64bit Windows the PID_Controller works fine.

stdout | OMEditInfo | <p>C:/Temp/Modelica.Blocks.Examples.PID_Controller/Modelica.Blocks.Examples.PID_Controller.exe -port=55617 -logFormat=xmltcp -override=startTime=0,stopTime=4,stepSize=0.008,tolerance=1e-06,solver=dassl,outputFormat=mat,variableFilter=.* -r=C:/Temp/Modelica.Blocks.Examples.PID_Controller/Modelica.Blocks.Examples.PID_Controller_res.mat -w -lv=LOG_STATS -inputPath=C:/Temp/Modelica.Blocks.Examples.PID_Controller -outputPath=C:/Temp/Modelica.Blocks.Examples.PID_Controller</p>
other | warning | <p>Warning: unrecognized command line options -inputPath=C:/Temp/Modelica.Blocks.Examples.PID_Controller -outputPath=C:/Temp/Modelica.Blocks.Examples.PID_Controller </p>
solver | info | <p>SimManager: Start simulation at t = 0.000000</p>
solver | info | <p>SimManager: Simulation stop time: 4.000000</p>

All the other ones in Blocks seem to work fine.
Do you have some special OMC flags in OMEdit?

[Rüdiger Franke]

No, nothing but the selection "Target Language: Cpp".

The problem appeared around the time when separate subdirectories have been introduced for each model.

[Adeel Asghar]

Well its easy to forget what settings you have set. Upload the %APPDATA%/openmodelica/omedit.ini so we can test with your settings.

I can take a look at it tomorrow.

[Rüdiger Franke]

I deleted this file and the OMEdit temp folder and restarted OMEdit. Same problem as before. But at least the initial sizing of the Libraries Browser changed to the better.

Formerly I could change the model code, e.g. to add debug messages, call make manually and re-simulate. This option is gone since OMEdit deletes most (but not all) source files now -- it does not delete *Algloop* files, see e.g. Modelica.Blocks.Examples.Filter.

Recently I was at least able to switch to the plotting perspective and press the re-simulate button after such errors -- as said, the simulation generally works, just not for some models when called from OMEdit immediately after model compilation. This option is gone too now as OMEdit keeps this button greyed out in the case of failed simulations now.

Another annoying thing: when copying the simulation command from the OMEdit Output window and pasting it to OpenModelica Command Prompt, then I have to manually remove HTML formattings and replace spaces before being able to execute the command.

Yet another observation: sometimes it helped to disable my local McAffee firewall to make simulation from OMEdit work. Does not help now -- and some models work anyway.

[Adeel Asghar]

Replying to rfranke:

I deleted this file and the OMEdit temp folder and restarted OMEdit. Same problem as before. But at least the initial sizing of the Libraries Browser changed to the better.

Formerly I could change the model code, e.g. to add debug messages, call make manually and re-simulate. This option is gone since OMEdit deletes most (but not all) source files now -- it does not delete *Algloop* files, see e.g. Modelica.Blocks.Examples.Filter.

You can disable this option Tools->Options->Simulation uncheck Delete Intermediate Compilation Files.

Recently I was at least able to switch to the plotting perspective and press the re-simulate button after such errors -- as said, the simulation generally works, just not for some models when called from OMEdit immediately after model compilation. This option is gone too now as OMEdit keeps this button greyed out in the case of failed simulations now.

No, they should be enabled once you select something in Variables Browser but I guess in your case Variables Browser is empty.

Another annoying thing: when copying the simulation command from the OMEdit Output window and pasting it to OpenModelica Command Prompt, then I have to manually remove HTML formattings and replace spaces before being able to execute the command.

I will fix it. Sometimes its useful to copy with formatting. Maybe we should have both options i.e., copy with/without formatting.

Yet another observation: sometimes it helped to disable my local McAffee firewall to make simulation from OMEdit work. Does not help now -- and some models work anyway.

I can successfully run the examples on my machine without any problem but I have 64-bit version. I will try to test the 32-bit version.

[Rüdiger Franke]

Another annoying thing: when copying the simulation command from the OMEdit Output window and pasting it to OpenModelica Command Prompt, then I have to manually remove HTML formattings and replace spaces before being able to execute the command.

I will fix it. Sometimes its useful to copy with formatting. Maybe we should have both options i.e., copy with/without formatting.

If at least the spaces would work, one only had to remove the HTML formattings manually.

The simulation runs successfully for Modelica.Blocks.Examples.PID_Controller when I check Simulation->Simulation Setup->Interactive Simulation. Of course I get the additional warning:

Warning: unrecognized command line options -embeddedServer=opc-ua -embeddedServerPort=4841 

and the variables browser remains empty.

When running without that checkbox, didn't you change something to already read results during simulations?
Can it be related to that?

[Adrian Pop]

Tested with 32bit OMEdit, it works fine (I renamed %APPDATA%/openmodelica/omedit.ini before start):

stdout | OMEditInfo | <p>C:/OMDev/tools/msys/tmp/OpenModelica/OMEdit/Modelica.Blocks.Examples.PID_Controller/Modelica.Blocks.Examples.PID_Controller.exe -port=54598 -logFormat=xmltcp -override=startTime=0,stopTime=4,stepSize=0.008,tolerance=1e-06,solver=dassl,outputFormat=mat,variableFilter=.* -r=C:/OMDev/tools/msys/tmp/OpenModelica/OMEdit/Modelica.Blocks.Examples.PID_Controller/Modelica.Blocks.Examples.PID_Controller_res.mat -w -lv=LOG_STATS -inputPath=C:/OMDev/tools/msys/tmp/OpenModelica/OMEdit/Modelica.Blocks.Examples.PID_Controller -outputPath=C:/OMDev/tools/msys/tmp/OpenModelica/OMEdit/Modelica.Blocks.Examples.PID_Controller</p>
other | warning | <p>Warning: unrecognized command line options -inputPath=C:/OMDev/tools/msys/tmp/OpenModelica/OMEdit/Modelica.Blocks.Examples.PID_Controller -outputPath=C:/OMDev/tools/msys/tmp/OpenModelica/OMEdit/Modelica.Blocks.Examples.PID_Controller </p>
solver | info | <p>SimManager: Start simulation at t = 0.000000</p>
solver | info | <p>SimManager: Simulation stop time: 4.000000</p>
solver | info | <p>Simulation info from solver:</p>

stdout | OMEditInfo | <p>C:/OMDev/tools/msys/tmp/OpenModelica/OMEdit/Modelica.Blocks.Examples.Filter/Modelica.Blocks.Examples.Filter.exe -port=54682 -logFormat=xmltcp -override=startTime=0,stopTime=0.9,stepSize=0.0018,tolerance=1e-06,solver=dassl,outputFormat=mat,variableFilter=.* -r=C:/OMDev/tools/msys/tmp/OpenModelica/OMEdit/Modelica.Blocks.Examples.Filter/Modelica.Blocks.Examples.Filter_res.mat -w -lv=LOG_STATS -inputPath=C:/OMDev/tools/msys/tmp/OpenModelica/OMEdit/Modelica.Blocks.Examples.Filter -outputPath=C:/OMDev/tools/msys/tmp/OpenModelica/OMEdit/Modelica.Blocks.Examples.Filter</p>
other | warning | <p>Warning: unrecognized command line options -inputPath=C:/OMDev/tools/msys/tmp/OpenModelica/OMEdit/Modelica.Blocks.Examples.Filter -outputPath=C:/OMDev/tools/msys/tmp/OpenModelica/OMEdit/Modelica.Blocks.Examples.Filter </p>
solver | info | <p>SimManager: Start simulation at t = 0.000000</p>
solver | info | <p>SimManager: Simulation stop time: 0.900000</p>
solver | info | <p>Simulation info from solver:</p>

Truth is I have OMDEV variable set up and run OMEdit from mingw32 bash which sets a different temp: C:/OMDev/tools/msys/tmp/ but other than that there are no differences.

[Adrian Pop]

@rfranke, i suggest you rename %APPDATA%/openmodelica/omedit.ini and restart OMEdit.
Then if it works, you can do a diff to see what is different between the default and your renamed one.

[Rüdiger Franke]

I had deleted this file without success; but good to know where all these settings are stored.

Tweaking log settings seems to have an influence. I can e.g. disable LOG_STATS (don't get any logging) or enable LOG_DEBUG (get a not supported warning) or enable LOG_SOLVER (get few log lines from the solver) or LOG_INIT (get a lot of initialization messages).

... The simulation works in all those cases ?!

How can I let OMEdit keep a setting like "LOG_SOLVER" upon restart?

[Rüdiger Franke]

There is a good chance that ​PR 2805 solves the problem.

Having this ticket open again, can we please also finally solve the -input/outputPath issue for the Cpp runtime?

[Rüdiger Franke]

​PR 2807 implements -inputPath and -outputPath.

@niklwors: you may need to extend GlobalSettings for VxWorks and set the input path to

"/SYSTEM/bundles/com.boschrexroth.<%modelname%>"

[Adeel Asghar]

Replying to rfranke:

Another annoying thing: when copying the simulation command from the OMEdit Output window and pasting it to OpenModelica Command Prompt, then I have to manually remove HTML formattings and replace spaces before being able to execute the command.

I will fix it. Sometimes its useful to copy with formatting. Maybe we should have both options i.e., copy with/without formatting.

If at least the spaces would work, one only had to remove the HTML formattings manually.

The simulation runs successfully for Modelica.Blocks.Examples.PID_Controller when I check Simulation->Simulation Setup->Interactive Simulation. Of course I get the additional warning:

Warning: unrecognized command line options -embeddedServer=opc-ua -embeddedServerPort=4841 

and the variables browser remains empty.

I guess OPC-UA is not supported by the cpp-runtime so it shouldn't be possible to run interactive simulation for it.

When running without that checkbox, didn't you change something to already read results during simulations?

No.

Can it be related to that?

[Adeel Asghar]

Replying to rfranke:

I had deleted this file without success; but good to know where all these settings are stored.

Tweaking log settings seems to have an influence. I can e.g. disable LOG_STATS (don't get any logging) or enable LOG_DEBUG (get a not supported warning) or enable LOG_SOLVER (get few log lines from the solver) or LOG_INIT (get a lot of initialization messages).

... The simulation works in all those cases ?!

How can I let OMEdit keep a setting like "LOG_SOLVER" upon restart?

Such settings are stored inside the model. See for example ​__OpenModelica_simulationFlags.

[Rüdiger Franke]

Yes, the OPC UA server is tightly connected to the C runtime that makes it hard to run it with the Cpp runtime.

It seems that PR 2805 solves the problem with failed initializations (removal of an uninitialized variable that was introduced about a year ago along with a for loop iterating until an undefined end).

The remaining issue is that OMEdit does not remove *Algloop* source files after simulation, see e.g. Modelica.Blocks.Examples.Filter. Where is defined which files shall be deleted? Shouldn't this be done with make clean?

[Adeel Asghar]

Replying to rfranke:

Yes, the OPC UA server is tightly connected to the C runtime that makes it hard to run it with the Cpp runtime.

I will disable the interactive simulation for cpp runtime.

It seems that PR 2805 solves the problem with failed initializations (removal of an uninitialized variable that was introduced about a year ago along with a for loop iterating until an undefined end).

Good.

The remaining issue is that OMEdit does not remove *Algloop* source files after simulation, see e.g. Modelica.Blocks.Examples.Filter. Where is defined which files shall be deleted? Shouldn't this be done with make clean?

No there is no such make clean. OMEdit deletes the the files after the simulation except the files needed for re-simulation. I will fix it.

[Francesco Casella]

@rfranke, the latest ​Hudson testuite run reports 2829 (!) regressions due to the last two commits reportedly related to this ticket. Pretty much all (or at least a large fraction of the) .cpp simulations now fail. The reported error message is

C++ runtime not supported in this installation (HelloWorld failed)

I guess that needs some attention :)

I'm not sure why this problem was not caught earlier by the test runs of ​PR #2805 and ​PR #2807, I suggest to also investigate why this could happen: is the cpp runtime included in the PR acceptance tests?

[Adeel Asghar]

Seems like after Rudiger's changes the result file is no longer created now. I not sure though not to investigate more.

[Adrian Pop]

Replying to adeas31:

Seems like after Rudiger's changes the result file is no longer created now. I not sure though not to investigate more.

This might be the reson that that all the CPP tests in the library coverage are broken:
​https://libraries.openmodelica.org/branches/history/master/2018-11-30%2011:19:15..2018-12-02%2022:16:47.html

[Adrian Pop]

It is strange that his commits ran fine with the testsuite, as far as I know we do have some CPP tests in there.

[Adeel Asghar]

I confirm now that the result file is no longer generated. I have attached a small testcase BouncingBall.mo and BouncingBall.mos.

[Rüdiger Franke]

Really strange. Hudson did not complain. OMEdit logs successful simulation steps until the final time. But yes, there is no results file -- OMEdit fooled me by showing old results files from previous runs.

[Rüdiger Franke]

​PR 2813 should fix it.

[Francesco Casella]

Indeed it did, see ​report.

Are all other pending issues in this ticket fixed?

[Adeel Asghar]

Other issues we discussed in this ticket are now fixed now,

a078212/OMEdit
1ff9da8/OMEdit
3ab3f3d/OMEdit
6abfbe4/OMEdit