OMPython using different Non Linear Solver than OMEdit, simulation failure

[ibeyers]

Hi, I have an issue that has me absolutely stumped, any help is appreciated. I have a model, which simulates perfectly in OMEdit, using the default simulation setup (no overrides!), but refuses to simulate when accessing it through OMPython. I think I have managed to locate the issue, but can't solve it.

When simulating in OMEdit, at time=0, the non-linear system is successfully solved by using the mixed solver, as per the log:

SOLVING NON-LINEAR SYSTEM USING MIXED SOLVER (Newton/Homotopy solver)

Attempting to simulate the same model via OMPython fails, because kinsol is used, which is unable to solve the initialisation problem. Note, I use absolutely no simulation overrides, so really attempting to replicate the exact same simulation. Log output:

LOG_STDOUT        | info    | Using sparse solver kinsol for nonlinear system 0 (413),
|                 | |       | because density of 0.09 remains under threshold of 0.10.
LOG_NLS           | info    | | KINSOL: Using linear solver method klu
...
LOG_ASSERT        | debug   | Solving non-linear system 413 failed at time=0.

I have attempted to force OMPython to use the mixed non-linear solver:

mod=ModelicaSystem("path/to/my/lib/package.mo","model.path")
mod.simulate(simflags='-nls=mixed')

and to lower the density threshold, to force the usage of a different non linear solver:

mod.simulate(simflags='-nlssMaxDensity=0.05')

Both did not change anything, kinsol still ends up being used and the simulation fails. Does anyone know why this is the case? Or why is the solving behaviour so different? I would expect an API to have the same defaults as the program it is trying to access? Any ideas for a workaround are much appreciated! Cheers

---

OpenModelica v1.22.1 OMPython 3.4.0 Python 3.11.7 Spyder IDE 5.4.3 Win 10

[ibeyers]

So, I found a quickfix: As I said, the model simulates without problem in OMEdit, so in the simulation setup in the "GeneraI" tab, I checked the options "save translation flags in model" and "save simulation flags in model" and ran it. This added the following annotation to the model file:

annotation(
    __OpenModelica_commandLineOptions = "--matchingAlgorithm=PFPlusExt --indexReductionMethod=dynamicStateSelection -d=initialization,evaluateAllParameters,NLSanalyticJacobian",
    __OpenModelica_simulationFlags(lv = "LOG_STDOUT,LOG_ASSERT,LOG_STATS", s = "dassl", variableFilter = ".*"));

When subsequently running from OMPython, the model now simulates successfully.

Evidently, there must be some differences between the OMEdit and OMPython defaults for compiling and solving behaviour, which didn't show up to me until now. Cheers

[arun3688]

@ibeyers I can see that you have used so many commandLine settings before simulating your model and you have to set those options in OMPython before simulating and the way to do it is something like below

mod=ModelicaSystem("path/to/my/lib/package.mo","model.path" , commandLineOptions="-d=initialization,evaluateAllParameters,NLSanalyticJacobian --matchingAlgorithm=PFPlusExt --indexReductionMethod=dynamicStateSelection")

and this should work in OMPython as well.

[casella]

@arun3688 the problem is that when one runs a simulation in OMEdit those flags are somehow taken as default choices - probably OMEdit sets them silently when before calling the translateModel() function.

It would be nice to have consistent default throughout the whole suite of tools (OMEdit, OMPython, OMMatlab, OMNotebook, etc.).

@adeas31 can you comment on the status with OMEdit? Are those flags silently applied by OMEdit but not part of the OMC defaults?

[bilderbuchi]

It seems something weird is going on with command line parameters. We also see a behaviour difference between OMEdit and OMPython, in that a Model in OMEdit simulates successfully, but using ModelicaSystem, we get an "Internal error function generateSymbolicJacobian failed". So, it seems When we pass commandLineOptions='--generateSymbolicJacobian=false' to the ModelicaSystem constructor, we still get the same error, although symbolic jacobians should be deactivated now?! (I don't have an MWE, yet---I'm hoping there's an MSL model or something that shows the same behaviour---and have not yet tried the workaround with model annotations)