Hello and a happy and for sure healthy New Year to all!

Unfortunately, nobody dared to answer my question so far, so left to my own devices, I was forced to do some more trials. And I got a bit further, I just don't know for sure if it is the right direction 

Firstly, I realized that the solver selection keywords in Python either contain system_wc and system_sc. And that the example code of HelloWorld_cs_fit is setup for a system by using system_wc; sc being strongly coupled and wc being weakly coupled. The solver that I tried to force the use of was the CVODE solver, for strongly coupled systems sc.... so that was the first miss. Setting the system up as a SC system, I was able to trigger the use of the CVODE solver ("oms.solver_sc_cvode" = CVODE with adaptive stepsize). Now, the initial issue is solved: I can feed "virtual" measurement data from a simulation using a higher order solver with fine timesteps (which would be similar to real world data that is semi-continously sampled but only given to OMSysident in e.g. 0.1 s intervals) and OMSysIdent is solving the correct parameters.    As the system is very simple, it is no real difference whether the system is called as SC or WC, I assume?

Secondly, the log file however throws errors when the system is defined as a SC system, even when the parameters are identified correctly. The errors are related to the destruction of the system at the end of the job - the results are not affected by this. I am just unsure as to how this might have other consequences...?

Sat Jan 02 00:05:29 2021 | error:   [fmi2logger] HelloWorld (logStatusError): fmi2Terminate: Illegal call sequence. fmi2Terminate is not allowed in Initialization Mode state.

Sat Jan 02 00:05:29 2021 | error:   [terminate] Termination of system "HelloWorld" failed

Sat Jan 02 00:05:29 2021 | error:   [terminate] Termination of system "HelloWorld_cs_Fit.root" failed

Sat Jan 02 00:05:29 2021 | error:   [fmi2logger] HelloWorld (logStatusError): fmi2Terminate: Illegal call sequence. fmi2Terminate is not allowed in Error state.

Sat Jan 02 00:05:29 2021 | error:   [terminate] Termination of system "HelloWorld" failed

Sat Jan 02 00:05:29 2021 | error:   [terminate] Termination of system "HelloWorld_cs_Fit.root" failed

Sat Jan 02 00:05:29 2021 | info:    Logging completed properly

Thirdly, when I revert to defining the system as weakly coupled, I have another three solvers available:
"oms.solver_wc_ma" = default master algorithm with fixed step size,
"oms.solver_wc_mav" = master algorithm with adaptive stepsize, and
"oms.solver_wc_mav2" = master algorithm with adaptive stepsize (double-step).

As the ODE solver had adaptive timestepping, I figured one of the mav solvers would do the job, to correctly identify the system parameters from a low-resolution sample of a high-resolution (simulated or mesured semi-continuous) signal. However, both solvers have issues with the system at hand. The mav solver throws the error

The adaptive step solver requires components (e.g. FMUs) that can rollback their states. None of the involved components in this model provide this functionality.

Well, and the mav2 works without errors, also the destruction works fine, but I identifies the parameters wrong - the a parameter in the example is estimated to about 0.95 whereas it should be 1.0. This is not satisfactory...

I hope this additional information triggers someone to comment on this. Thank you,
Thomas.

Title

Hello forumists,
I started to work with OMSysIdent, that I was able to build and setup fully functional along with OMSimulator. I am fiddling around with the HelloWorld_cs_Fit example, and I had to find out that it works fine when you are feeding it measurement data coming from a first order Euler simulation of the HelloWorld example. When data from e.g. a DASSL solver based simulation is fed, the parameters are not determined correctly. I assume this is due to the fact that OMSysIdent is using OMSimulator in the setting that triggers the use of the Euler solver while doing the parameter identification. So the cure seemed clear to me: just set OMSimulator to use the solver that is used to generate the "measurement" data, e.g. DASSL or CVODE. I read somewhere that CVODE is supported by OMSimulator, so I set it to use CVODE by adding 

oms.setSolver("HelloWorld_cs_Fit.root", oms.solver_sc_cvode)

to the HelloWorld_cs_Fit.py script. I also changed the measurement data values to resemble what the CVODE solver results would look like. However, no change in behaviour - it seems like this setting is completely ignored. I would appreciate some comments in this regard, especially concerning the following questions:

1) Is the combination of OMSysIdent with OMSimulator capable of using a different solver than first order Euler, especially something with higher orders?
2) Do I have to make different settings, e.g. in other files or via commandline, not in the python script?

Looking forward to your hints, thank you so far -
Thomas.