You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
OMPython using different Non Linear Solver than OMEdit, simulation failure #194
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:
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
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:
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
@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
@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?
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)
I'm having similar issues where my model runs in OMEdit, but I can't make it run using the ModelicaSystem class. However, it works if I only use OMCSessionZMQ and sendExpression. I'm using OMPython 3.6, is this issue resolved in OMPython 4.0?
Yes, it is related to the changes done in #350. We improved ModelicaSystem, earlier the flag --generateSymbolicLinearization is always enabled. Now we only set the command line options that are provided by the user. However, if there are no command line options then we set --linearizationDumpLanguage=python and --generateSymbolicLinearization which is perhaps added to facilitate the linearization. Perhaps @arun3688 knows more.
@arun3688 adding these flags by default to ModelicaSystem is not correct. Maybe we should add them only when calling ModelicaSystem.linearize, and remove them once linearization is done.
Activity
ibeyers commentedon Jan 22, 2024
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:
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 commentedon Jan 22, 2024
@ibeyers I can see that you have used so many
commandLinesettings before simulating your model and you have to set those options in OMPython before simulating and the way to do it is something like belowmod=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 commentedon Jan 22, 2024
@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 commentedon Aug 22, 2024
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 seemsWhen we pass
commandLineOptions='--generateSymbolicJacobian=false'to theModelicaSystemconstructor, 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)
j-emils commentedon Nov 12, 2025
I'm having similar issues where my model runs in OMEdit, but I can't make it run using the ModelicaSystem class. However, it works if I only use OMCSessionZMQ and sendExpression. I'm using OMPython 3.6, is this issue resolved in OMPython 4.0?
adeas31 commentedon Nov 12, 2025
@j-emils try 4.0 and see if it works. If it does not then please try to make a MWE so we can debug the issue.
j-emils commentedon Nov 17, 2025
@adeas31, it didn't work with 4.0. However, I changed to using the latest master, and then it works.
adeas31 commentedon Nov 17, 2025
Yes, it is related to the changes done in #350. We improved
ModelicaSystem, earlier the flag--generateSymbolicLinearizationis always enabled. Now we only set the command line options that are provided by the user. However, if there are no command line options then we set--linearizationDumpLanguage=pythonand--generateSymbolicLinearizationwhich is perhaps added to facilitate the linearization. Perhaps @arun3688 knows more.@arun3688 adding these flags by default to
ModelicaSystemis not correct. Maybe we should add them only when callingModelicaSystem.linearize, and remove them once linearization is done.See https://github.com/OpenModelica/OMPython/blob/master/OMPython/ModelicaSystem.py#L380
adeas31 commentedon Dec 2, 2025
Works as expected now.