• Selection of variables to store and plot
• Subsample simulation for logging
• Split up the result files into several smaller ones instead of one large when simulating sequentially
• Allow to skip writing a result file
• Make buffer size adjustable

The exisitng APIs oms2_setStartTime and oms2_setStopTime creates a following section,

<ssd:DefaultExperiment startTime="0.000000" stopTime="1.000000" />

So APIs oms2_getStartTime and oms2_getStopTime are needed to read these values back.

Describe the bug
The target config-libxml2 is broken on Linux & Mac. After running the target no files are installed into 3rdParty/libxml2/install/linux.

To Reproduce
make config-libxml2

Expected behavior
All files should be installed into 3rdParty/libxml2/install/linux.

The simulation stability of a TLM composite model depends on the specified stop time in oms2_setStopTime("Demonstrator_FineGrained_fg", XXXX). A stop time of 1300s makes the model run into stability problems prior to 1s of execution; however, a stop time of 10s renders a fully stable simulation

Description

Running the testsuite on Hudson using MSVC64 makes AircraftVehicleDemonstrator produce a log-file large enough to consume all disk space.

Steps to reproduce the behavior

Run a pull request...

Expected behavior

It needs to be possible to limit the size of log-files.

The top level parameter P in FMU signal_modifyer cannot be accessed in OMSimulator and is not stored in the result file. However, when importing the FMU in other tools then P is seen and can be modified.

oms2_setRealParameter("AVSDemo.signal_modifyer:P",3) gives error: No such parameter: P

log_and_FMU.zip

Desktop (please complete the following information):

• OS: Win7
• Version: OMSimulator` v0.1.0-429-gbd514e7

084d18f introduced a dependency on libxml2-dev, but the 3rdParty sources already include an XML parser: PugiXML. I would strongly suggest changing the code to use PugiXML everywhere, or ifdef the code so that either can be used. It is currently the only dependency that is not included in the project itself and might not be available for static linking on the build machine. Currently, the ARM builds are broken; as are the OM library coverage jobs.

I get the following error message sporadically when I try to add TLM interfaces.

FATAL ERROR: lua_pcall() failed: .\DemonstratorFineGrained.lua:395: attempt to call a number value (global 'input')

Sometimes the error message is followed by the following:

terminate called after throwing an instance of 'std::length_error'
  what():  deque::_M_new_elements_at_front

For example something like this:
oms2_setTLMInitialEffort("tlmmodel", "submodel:port", )

Pre-compiled binaries for 32bit Windows-MSVC were requested.

Basic progress info during simulation would be nice, and possibility to store a master CPUtime variable for plotting.

Right now, FMU-ME is only supported by the old API.

Occasionally FMUs deliver irrelevant outputs due to e.g. poor start values or initialization/stability problems. This may cause problems in downstream FMUs, e.g. that downstream cannot simulate. In some cases a min/max limit on inputs (or outputs) would solve this problem. I.e. downstream FMUs are running on limited inputs until upstream FMUs are stabilized and provides output within expected range.

The min/max limits could be an optional input argument to oms2_addConnection, e.g.:

oms2_addConnection("FMICompositeModel","FMU_A:u1","FMU_B:y1", [min max]).

FMU_A.u1 is then limited to be within the range [min max]. I guess this is only applicable for connections with Real input/output signals.

The user should be provided a warning that indicates which min/max limits have been active during simulation and for which time periods.

Describe the bug
The mingw build is missing some dependencies from the TLM simulator. Basically all libraries from OMTLMSimulator/bin/ are needed and also libxml2.dll and pthreadVC2.dll.

To Reproduce
Steps to reproduce the behavior:

1. Download latest build: OMSimulator-mingw-master.zip
2. Run OMSimulator.exe

Screenshots

Desktop (please complete the following information):

• OS: Windows 10, 64bit
• Version: OMSimulator v0.1.0-464-geaf2040-mingw

OpenModelica and Dymola can often not open OMSimulator result files. The following error is recieved when attempting to load a result file in OpenModelica

Misslyckades �ppna simuleringsresultat C:/Users/robha67/Documents/OMSim_2018_05_07/CompositeModels/Demonstrator_TLM/Engine_res.mat: Corrupt header: dataInfo matrix

Unzipping an FMU and modifying parameter values in modelDescription.xml has no effect when the updated FMU is added and used OMSimulator.

1. Unzip FMU
2. Open modelDescription.xml and modify a parameter value (seems to be the same for input start values but this has to be confirmed)
3. Zip again and rename file extension to .fmu
4. Add updated FMU to an FMI composite model and simulate

oms2_exportDependencyGraphs generates dot files with content but corresponding pdf files are blank:

oms2_initialize("AVSDemo")
oms2_exportDependencyGraphs("AVSDemo", "AVSDemo_initialUnknowns.dot", "AVSDemo_outputs.dot")
os.execute("gvpr -c "N[$.degree==0]{delete(root, $)}" AVSDemo_initialUnknowns.dot | dot -Tpdf -o AVSDemo_initialUnknowns.pdf")
os.execute("gvpr -c "N[$.degree==0]{delete(root, $)}" AVSDemo_outputs.dot | dot -Tpdf -o AVSDemo_outputs.pdf")

Prior to oms2_initialize I use exportCompositeStructure which works fine:
oms2_exportCompositeStructure("AVSDemo","AVSDemo.dot") -- generate composite model structure graph
os.execute("dot -Gsplines=none AVSDemo.dot | neato -n -Gsplines=ortho -Tpdf -oAVSDemo.pdf")

Description

Logging of integers and booleans is not working, except for parameters.

The new API is using the prefix oms2_. This is not really needed, because the old API is removed completly. Should we remove the oms2_ prefix before doing the release? I think it would make things slightly nicer.

When I try to run several simulations in sequence in a Lua script, the simulations seem to run properly but the second result file cannot be opened. My interpretation of #169 is that this should already be working. Lua example below, probably something I did wrong here? Files result_4.mat, result_5.mat, and log attached.

result_files_and_log.zip

--simulationsettings
-- *** 1s run ***
oms2_setResultFile("AVSDemo","result_4.mat")
oms2_setStopTime("AVSDemo",0.02)
oms2_initialize("AVSDemo")
oms2_setCommunicationInterval("AVSDemo", 1e-5)
oms2_stepUntil("AVSDemo", 1e-4)
oms2_setCommunicationInterval("AVSDemo", 1e-2)
oms2_simulate("AVSDemo")

-- *** 2nd run ***
oms2_setResultFile("AVSDemo","result_5.mat")
oms2_setStopTime("AVSDemo",0.02)
--oms2_initialize("AVSDemo")
oms2_setCommunicationInterval("AVSDemo", 1e-5)
oms2_stepUntil("AVSDemo", 1e-4)
oms2_setCommunicationInterval("AVSDemo", 1e-3)
oms2_simulate("AVSDemo")

-- *** End ***
oms2_terminate("AVSDemo")
oms2_unloadModel("AVSDemo")

Oacillating behavior for native FMI-based (not TLM) co-simulation of aricraft use-cases. Might be related to issue #18 "Coupling stability".

• Resultfile (mat, csv)
• get signal values (api)
• Investigate capability of getting whole time series from API

When the logging of any of the FMI submodels included in a TLM composite model is turned off using
oms2_setResultFile("ConsumerA_FMI",""), then the lua script is executed without producing any simulation results or log files. No error messages are communicated.

Needs to integrate existing FMISimulator implementation. Needs to finalize functionalities like interpolation, configuration, etc.

• Several different proposals
• Pending implementation

For traceability and to know what was actually simulated, a configuration log file should be generated (or info included in the standard log file). If separate log file, the file name may be the same as the result file but with e.g. "_config.log". This should include all available info on which FMUs were included in the simulation, solver settings, etc. Extract as much info as possible from modelDescription.xml for each FMU regardning e.g.:

• FMU name
• FMU generation date/time
• Generation tool
• Internal solver and tolerance (or solver and tolerence defined using setTolerance, if any).

In addition, OMSimulator level info should be included, e.g.:

• Master algorithm
• Communication step size(s)
• Central tolerance setting?
• Flags and other relevant settings affecting the simulation

Should work for single FMI composite models and for the case of connecting several FMI composite models using TLM.

@robbr48 Is line 380 correct?

It doesn't seem to do anything useful. And the argument tolerance of the method isn't used at all.

It seems to be unnecessary to have to explicitly call both functions sequentially. My proposal is to merge oms2_terminate into oms2_unloadModel.

@adeas31 @bernhard-thiele What do you think?

Possible call sequence: oms2_initialize -> (oms2_simulate | oms2_simulate_asynchronous) -> [oms2_reset -> oms2_initialize -> (oms2_simulate | oms2_simulate_asynchronous)] -> oms2_unloadModel

Crashes after completed simulation

Right now oms2_rename just renames the model or submodel. Once the submodel is renamed then the data structures associated to it are not updated e.g., oms_connector_t stored in oms_element_t holds the old name. Also the connections associated with the submodel should also be updated.

When warnings and errors during simulation, the log file grows rapidly (and unlimited?). Suggest to limit file size to xx Mb (or number of messages/lines, etc.), so it can be opened in text editors and doesn't fill the harddrive.

supported in FMI simulator, needs to be implemented in GUI

Seems like integer (and probably boolean?) is currently not stored. From log file: "Variable signal_modifyer.switch.u2 will not be stored in the result file, because the signal type is not supported"

Adding TLM connections to FMI models in OMSimulator (via the LUA API) is extremely time consuming for industry grade models.

One solution is to mimic the automatic generation of "fmi.config" files that was used in the previous TLM simulator version. A function that reads extracts the I/O:s from the Model description files and automatically writes the corresponding "oms2_addTLMInterface" statement to a lua file which then can be used as template for the composite model. The parameters that are availble for specification via the API could also be automatically generated and commented in the resulting lua script, i.e --"oms2_setRealParameter(...)"

I was trying to co-simulate two coupled FMUs from the FMITest library with OMSimulator.

• FMITest.VirtualLoops.MassSpringDamper.FMUModels.SpringDamper
• FMITest.VirtualLoops.MassSpringDamper.FMUModels.MassWithGravity

It was found that the co-simulation results are quite different comparing to the original Modelica reference model. OMSimulator handles initialization correctly, however, the results seem to be incorrect. I guess it might because inputs are not interpolated in OMSimulator, and I wonder if there are any plans to improve the coupling stability (similar to PyFMI maybe)? Thanks.

Value bindings are missing, signal grouping, and SSP packaging

Is your feature request related to a problem? Please describe.
TLM composite models are currently not initialized properly when initial flow variable is non-zero. The TLM node assumes zero flow at beginning, which may cause a mismatch with the submodels.

Describe the solution you'd like

• Move socket initialization from simulateTLM() to initialize()
• Read data from sockets before initializing FMU
• Add initial flow function to PluginImplementer
• Use initial flow to compute force variable ("GenForce")

Description

The process, when executing in Mac (OS 10.13.5), does not finish. The simulation works fine but the process stands by

Steps to reproduce the behavior

$ ../install/mac/bin/OMSimulator oms2_multidomaingrid_cs.lua

some log messages

info: New temp directory: "/Users/fran_jo/Desktop/OMSimulator/OMSimulator/testkth/workingTemp"
info: Result file: new_multidomain_cs.mat (bufferSize=1)
info: Simulation finished.

OMSimulator does not terminate. Ctrl+C doesn't kill the process neither

• Version: [OMSimulator v2.0.0-dev-497-g76904d9-mac]
• OS: [Mac OSX OS 10.13.5 High Sierra]

There is no API function to set the ssd_connector_geometry_t.
Implement something like this,

oms_status_enu_t oms2_setConnectorGeometry(const char* cref, const ssd_connector_geometry_t* geometry);

To reduce the number of internal steps required in variable step CS FMUs and in some cases enhance numerical stability, the master should provide functionalities for smoothing of FMU inputs.

Several approaches can be considered, e.g. various low pass filters but also use of directional derivatives when such are available. See e.g. Section 6.3 in http://ctr.maths.lu.se/na/staff/chria/phdthesis.pdf

Is your feature request related to a problem? Please describe.
Result files after TLM simulations can grow very large. User should be able to control number of samples from Lua scripts.

Describe the solution you'd like
Add an setTLMLogSamples() function to Lua API.

I am trying to run OpenModelica generated FMU on a Embedian SBC-SMART-BEE single board computer. Processor is TI Sitara AM3354 running arago yocto linux OS.
While executing the OMSimulator-Linux-ARM executable downloaded from https://test.openmodelica.org/hudson/job/OMSimulator-Linux-ARM/ I got following error:
root@smarct335x:~/testModel# ./OMSimulator
./OMSimulator: error while loading shared libraries: libomtlmsimulator.so: cannot open shared object file: No such file or directory.
Please suggest how to solve this error and also suggest correct method to use OMSimulator-Linux-ARM executable with FMU.

Right now it is possible to start the simulation using oms2_simulate_asynchronous. However, there is no way to cancel a running simulation.

To facilitate what-if simulations, the master should include a Fault Injection Block (FIB). The FIB is a master functionality that can be inserted to modify inputs of FMUs. An example of a typical FIB functionality is found in Section 3.5 of https://www.diva-portal.org/smash/get/diva2:474629/FULLTEXT01.pdf

The FIB could be an optional input argument to oms2_addConnection, e.g.:
oms2_addConnection("FMICompositeModel","FMU_A:u1","FMU_B:y1", [faultType faultValue]), with faultType as Integer and faultValue as Real. Then input FMU_A.u1 is modified according to faultType and faultValue.

@lochel, in latest build the simulation get stuck without warning/error when using oms2_setLoggingInterval. After the simulation is stuck, the result file is corrupt and cannot be opened. I've tried different combinations of oms2_setFlags (+/-fetchAllVars) at different locations.

Please see complete test case in OpenCPS repo: T6.3\Demonstrator_20180620\AVSDemo_combi_20180620.lua (toggle commenting on lines 176, 190, and 192).

Is your feature request related to a problem? Please describe.
User is not able to control log levels. Currently only fatal errors are printed.

Describe the solution you'd like
Add a setTLMLoggingLevel() function, which calls the omtlm_setLogLevel() function in OMTLMSimulator API.

Describe alternatives you've considered
It could be possible to use the logging level specified for OMSimulator.

Additional context
Logging levels available in OMTLMSimulator:
0 = Logging Disabled
1 = Fatal
2 = Fatal & Warning
3 = Fatal, Warning & Info
4 = Fatal, Warning, Info & Debug

Long simulations will result in very large result files if variables are stored at each communication point. Expanding the Lua API to such that the result file resolution can be specified is essential. This is important for all logging but this issue particulalry concerns the top level composite model logging conducted via TLM connections