Description
Steps to Reproduce
Expected Behavior
Screenshots
Version and OS
- OpenModelica Version: [e.g.
omc --version or Help->About OMEdit from OMEdit]
- OS: [e.g. Windows 10, 64 bit]
- Versions of used Modelica libraries if applicable
Additional Context
OpenModelica Version: 1.26.3 (64-bit) installer, Windows 10/11
Component: OMEdit / Makefile-driven build
Summary
For a model using HelmholtzMedia 2.1.0 (CO2), simulating from OMEdit produces an .exe that crashes deterministically at t≈3.679 s with a subnormal-pow assertion in the EoS residual function. Translating + compiling the same model with the same OMC translation flags via OMC CLI (buildModel(...) → invoke generated Makefile) produces a different .exe (different size, different SHA256) that runs cleanly to the end of the simulation.
Both binaries are launched with the same runtime arguments. The OMEdit binary crashes identically whether launched from OMEdit or from a clean PowerShell. The CLI binary succeeds in both cases. So the bug is in OMEdit's build invocation, not in OMEdit's parent process or its runtime args.
Environment
OS: Windows 10/11 64-bit
OMC: 1.26.3-64bit (C:\Program Files\OpenModelica1.26.3-64bit)
Compiler: bundled clang (set via setCompiler("clang"))
Libraries:
HelmholtzMedia 2.1.0 (Span–Wagner CO2)
ExternalMedia 4.1.1
Modelica 4.1.0
Reproducer
Model: a 2-chamber double-acting compressor using HelmholtzMedia.HelmholtzFluids.CO2. Minimal repro pending; in our test it is IsothermalCompressorAll.HM.DoubleActingCycle (attached / linked).
OMEdit path (broken)
OMEdit (per omeditcommunication.log) executes the following sequence:
clearCommandLineOptions();
setCommandLineOptions("--matchingAlgorithm=PFPlusExt --indexReductionMethod=dynamicStateSelection -d=initialization,NLSanalyticJacobian");
setCommandLineOptions("--simCodeTarget=C");
setCommandLineOptions("--target=gcc");
setCompiler("clang");
setCXXCompiler("clang++");
setCommandLineOptions("+ignoreCommandLineOptionsAnnotation=false");
setCommandLineOptions("+ignoreSimulationFlagsAnnotation=false");
setCommandLineOptions("+profiling=none");
setCommandLineOptions("-d=infoXmlOperations");
translateModel(IsothermalCompressorAll.HM.DoubleActingCycle, startTime=0, stopTime=96, numberOfIntervals=500, method="dassl", tolerance=1e-6, outputFormat="mat", fileNamePrefix="DoubleActingCycle", variableFilter=".*");
OMEdit then invokes its generated Makefile externally, then launches:
DoubleActingCycle.exe -port= -logFormat=xmltcp -startTime=0 -stopTime=96 -stepSize=0.192 -tolerance=1e-06 -s=dassl -outputFormat=mat -variableFilter=.* -r=...DoubleActingCycle_res.mat -w -lv=LOG_STDOUT,LOG_ASSERT,LOG_STATS -inputPath=... -outputPath=...
Resulting binary: DoubleActingCycle.exe, 488 099 bytes, SHA256 DFCD573E….
Runtime output:
setState_pTX: d_min and d_max did not bracket the root
The initialization finished successfully without homotopy method.
DoubleActingCycle_functions.c:11830: Invalid root: (4.7585e-311)^(-1)
... (many repeats)
A Modelica assert prevents the integrator to continue.
can't continue. time = 3.679235
DASKR-- NONLINEAR SYSTEM SOLVER COULD NOT CONVERGE BECAUSE IRES WAS EQUAL TO MINUS ONE
CLI path (works)
Same model loaded, same translation flags set in the same order, then buildModel(...) instead of translateModel(...) (which performs the same translation step OMEdit does, then invokes the generated Makefile):
clearCommandLineOptions();
setCommandLineOptions("--matchingAlgorithm=PFPlusExt --indexReductionMethod=dynamicStateSelection -d=initialization,NLSanalyticJacobian");
setCommandLineOptions("--simCodeTarget=C");
setCommandLineOptions("--target=gcc");
setCompiler("clang");
setCXXCompiler("clang++");
setCommandLineOptions("+ignoreCommandLineOptionsAnnotation=false");
setCommandLineOptions("+ignoreSimulationFlagsAnnotation=false");
setCommandLineOptions("+profiling=none");
buildModel(IsothermalCompressorAll.HM.DoubleActingCycle, startTime=0, stopTime=96, numberOfIntervals=500, method="dassl", tolerance=1e-6, outputFormat="mat", fileNamePrefix="DoubleActingCycle", variableFilter=".*");
Resulting binary: DoubleActingCycle.exe, 493 219 bytes, SHA256 822651D7….
Launching that exe with OMEdit's exact runtime args (minus -port/-logFormat, which are just the OMEdit GUI log channel) succeeds:
LOG_SUCCESS | info | The simulation finished successfully.
974 steps taken, 1732 calls of functionODE, 228 jacobian evaluations
Produces a valid 267 119-byte .mat.
What we've ruled out
Model source / annotations: identical for both runs.
HelmholtzMedia source: byte-identical between user libraries copy (AppData/.openmodelica/libraries/HelmholtzMedia 2.1.0) and project-local copy. Both CLI and OMEdit see the same files.
Translation flags: explicitly reproduced OMEdit's flag sequence in CLI; CLI still succeeds.
Compiler optimization level: tested cflags = "" | -O0 | -O1 | -O2 | -O3 | -Os in CLI — all succeed.
Runtime arguments: ran CLI-built exe with OMEdit's exact runtime args including -stepSize=0.192 -lv=LOG_STDOUT,LOG_ASSERT,LOG_STATS etc. → succeeds.
Parent process: launching OMEdit's exe directly from a clean PowerShell (no OMEdit, no TCP log socket) crashes identically.
Solver: only DASSL works; IDA fails earlier (separate issue, not what we're reporting).
What we can't see
OMEdit deletes the generated .makefile, .c, .h, and .o files immediately after a successful link, so I can't directly diff the actual compile/link commands that produced the two different binaries. The reference Makefile generated by buildModel(...) is shown below (this is what works in CLI; the broken OMEdit run is presumably almost identical):
Makefile generated by OpenModelica
Platform: win64
CC=clang
CXX=clang++
LINK=clang++ -shared -Xlinker --export-all-symbols
EXEEXT=.exe
DLLEXT=.dll
CFLAGS_BASED_ON_INIT_FILE=
OMC_CFLAGS_OPTIMIZATION=-Os
DEBUG_FLAGS=$(OMC_CFLAGS_OPTIMIZATION)
CFLAGS=-municode $(CFLAGS_BASED_ON_INIT_FILE) $(DEBUG_FLAGS) -DOM_HAVE_PTHREADS -Wno-parentheses-equality -falign-functions -mstackrealign -msse2 -mfpmath=sse ${MODELICAUSERCFLAGS}
CPPFLAGS= -I"...\include\omc\c" -I"...\include\omc" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=DoubleActingCycle -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=4 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0
OMC_LDFLAGS_LINK_TYPE=dynamic
RUNTIME_LIBS=-lSimulationRuntimeC -Wl,-Bdynamic -lomcgc -lryu -lopenblas -Wl,-B$(OMC_LDFLAGS_LINK_TYPE) -lstdc++ -Wl,-Bdynamic
LDFLAGS=-L"...\lib\omc" -L"...\lib" -Wl,--stack,16777216,-rpath,"...\lib\omc" -L"...\bin" -Wl,-rpath,"...\lib" -fopenmp -Wl,-Bstatic -lregex -ltre -lintl -liconv -lexpat -lpthread -loleaut32 -limagehlp -lhdf5 -lz -lsz -Wl,-Bdynamic $(RUNTIME_LIBS)
Note the ${MODELICAUSERCFLAGS}, $(OMC_CFLAGS_OPTIMIZATION), and $(OMC_LDFLAGS_LINK_TYPE) placeholders — any of these could be set in OMEdit's child-process environment but not in mine. That would be my best guess at the root cause, but I can't verify without OMEdit retaining its build artifacts or echoing the actual compile commands somewhere.
Suggested investigation
Add an OMEdit option to keep build artifacts (.makefile, .c, .o, compile log) after successful build, for diagnostic purposes.
Have OMEdit's compile invocation explicitly dump the resolved compile/link command lines and the relevant env vars (MODELICAUSERCFLAGS, OMC_CFLAGS_OPTIMIZATION, OMC_LDFLAGS_LINK_TYPE, PATH) into DoubleActingCycle.log.
Check whether OMEdit sets any of those env vars before invoking make.
Workaround (for other users hitting this)
Translate + compile the model via OMC CLI's buildModel(...) script (using the same flag sequence OMEdit uses) and copy the resulting .exe, _init.xml, _info.json, _JacA.bin into the OMEdit cache directory (%LOCALAPPDATA%\Temp\OpenModelica\OMEdit<ModelFQN>). Then in OMEdit use File → Open Result File... to load the .mat. Do not use OMEdit's "Simulate" button — it will rebuild and overwrite the working exe with the broken one.
exe_run.txt
Description
Steps to Reproduce
Expected Behavior
Screenshots
Version and OS
omc --versionorHelp->About OMEditfrom OMEdit]Additional Context
OpenModelica Version: 1.26.3 (64-bit) installer, Windows 10/11
Component: OMEdit / Makefile-driven build
Summary
For a model using HelmholtzMedia 2.1.0 (CO2), simulating from OMEdit produces an .exe that crashes deterministically at t≈3.679 s with a subnormal-pow assertion in the EoS residual function. Translating + compiling the same model with the same OMC translation flags via OMC CLI (buildModel(...) → invoke generated Makefile) produces a different .exe (different size, different SHA256) that runs cleanly to the end of the simulation.
Both binaries are launched with the same runtime arguments. The OMEdit binary crashes identically whether launched from OMEdit or from a clean PowerShell. The CLI binary succeeds in both cases. So the bug is in OMEdit's build invocation, not in OMEdit's parent process or its runtime args.
Environment
OS: Windows 10/11 64-bit
OMC: 1.26.3-64bit (C:\Program Files\OpenModelica1.26.3-64bit)
Compiler: bundled clang (set via setCompiler("clang"))
Libraries:
HelmholtzMedia 2.1.0 (Span–Wagner CO2)
ExternalMedia 4.1.1
Modelica 4.1.0
Reproducer
Model: a 2-chamber double-acting compressor using HelmholtzMedia.HelmholtzFluids.CO2. Minimal repro pending; in our test it is IsothermalCompressorAll.HM.DoubleActingCycle (attached / linked).
OMEdit path (broken)
OMEdit (per omeditcommunication.log) executes the following sequence:
clearCommandLineOptions();
setCommandLineOptions("--matchingAlgorithm=PFPlusExt --indexReductionMethod=dynamicStateSelection -d=initialization,NLSanalyticJacobian");
setCommandLineOptions("--simCodeTarget=C");
setCommandLineOptions("--target=gcc");
setCompiler("clang");
setCXXCompiler("clang++");
setCommandLineOptions("+ignoreCommandLineOptionsAnnotation=false");
setCommandLineOptions("+ignoreSimulationFlagsAnnotation=false");
setCommandLineOptions("+profiling=none");
setCommandLineOptions("-d=infoXmlOperations");
translateModel(IsothermalCompressorAll.HM.DoubleActingCycle, startTime=0, stopTime=96, numberOfIntervals=500, method="dassl", tolerance=1e-6, outputFormat="mat", fileNamePrefix="DoubleActingCycle", variableFilter=".*");
OMEdit then invokes its generated Makefile externally, then launches:
DoubleActingCycle.exe -port= -logFormat=xmltcp -startTime=0 -stopTime=96 -stepSize=0.192 -tolerance=1e-06 -s=dassl -outputFormat=mat -variableFilter=.* -r=...DoubleActingCycle_res.mat -w -lv=LOG_STDOUT,LOG_ASSERT,LOG_STATS -inputPath=... -outputPath=...
Resulting binary: DoubleActingCycle.exe, 488 099 bytes, SHA256 DFCD573E….
Runtime output:
setState_pTX: d_min and d_max did not bracket the root
The initialization finished successfully without homotopy method.
DoubleActingCycle_functions.c:11830: Invalid root: (4.7585e-311)^(-1)
... (many repeats)
A Modelica assert prevents the integrator to continue.
can't continue. time = 3.679235
DASKR-- NONLINEAR SYSTEM SOLVER COULD NOT CONVERGE BECAUSE IRES WAS EQUAL TO MINUS ONE
CLI path (works)
Same model loaded, same translation flags set in the same order, then buildModel(...) instead of translateModel(...) (which performs the same translation step OMEdit does, then invokes the generated Makefile):
clearCommandLineOptions();
setCommandLineOptions("--matchingAlgorithm=PFPlusExt --indexReductionMethod=dynamicStateSelection -d=initialization,NLSanalyticJacobian");
setCommandLineOptions("--simCodeTarget=C");
setCommandLineOptions("--target=gcc");
setCompiler("clang");
setCXXCompiler("clang++");
setCommandLineOptions("+ignoreCommandLineOptionsAnnotation=false");
setCommandLineOptions("+ignoreSimulationFlagsAnnotation=false");
setCommandLineOptions("+profiling=none");
buildModel(IsothermalCompressorAll.HM.DoubleActingCycle, startTime=0, stopTime=96, numberOfIntervals=500, method="dassl", tolerance=1e-6, outputFormat="mat", fileNamePrefix="DoubleActingCycle", variableFilter=".*");
Resulting binary: DoubleActingCycle.exe, 493 219 bytes, SHA256 822651D7….
Launching that exe with OMEdit's exact runtime args (minus -port/-logFormat, which are just the OMEdit GUI log channel) succeeds:
LOG_SUCCESS | info | The simulation finished successfully.
974 steps taken, 1732 calls of functionODE, 228 jacobian evaluations
Produces a valid 267 119-byte .mat.
What we've ruled out
Model source / annotations: identical for both runs.
HelmholtzMedia source: byte-identical between user libraries copy (AppData/.openmodelica/libraries/HelmholtzMedia 2.1.0) and project-local copy. Both CLI and OMEdit see the same files.
Translation flags: explicitly reproduced OMEdit's flag sequence in CLI; CLI still succeeds.
Compiler optimization level: tested cflags = "" | -O0 | -O1 | -O2 | -O3 | -Os in CLI — all succeed.
Runtime arguments: ran CLI-built exe with OMEdit's exact runtime args including -stepSize=0.192 -lv=LOG_STDOUT,LOG_ASSERT,LOG_STATS etc. → succeeds.
Parent process: launching OMEdit's exe directly from a clean PowerShell (no OMEdit, no TCP log socket) crashes identically.
Solver: only DASSL works; IDA fails earlier (separate issue, not what we're reporting).
What we can't see
OMEdit deletes the generated .makefile, .c, .h, and .o files immediately after a successful link, so I can't directly diff the actual compile/link commands that produced the two different binaries. The reference Makefile generated by buildModel(...) is shown below (this is what works in CLI; the broken OMEdit run is presumably almost identical):
Makefile generated by OpenModelica
Platform: win64
CC=clang$(CFLAGS_BASED_ON_INIT_FILE) $ (DEBUG_FLAGS) -DOM_HAVE_PTHREADS -Wno-parentheses-equality -falign-functions -mstackrealign -msse2 -mfpmath=sse ${MODELICAUSERCFLAGS}
CXX=clang++
LINK=clang++ -shared -Xlinker --export-all-symbols
EXEEXT=.exe
DLLEXT=.dll
CFLAGS_BASED_ON_INIT_FILE=
OMC_CFLAGS_OPTIMIZATION=-Os
DEBUG_FLAGS=$(OMC_CFLAGS_OPTIMIZATION)
CFLAGS=-municode
CPPFLAGS= -I"...\include\omc\c" -I"...\include\omc" -I. -DOPENMODELICA_XML_FROM_FILE_AT_RUNTIME -DOMC_MODEL_PREFIX=DoubleActingCycle -DOMC_NUM_MIXED_SYSTEMS=0 -DOMC_NUM_LINEAR_SYSTEMS=4 -DOMC_NUM_NONLINEAR_SYSTEMS=0 -DOMC_NDELAY_EXPRESSIONS=0 -DOMC_NVAR_STRING=0
OMC_LDFLAGS_LINK_TYPE=dynamic
RUNTIME_LIBS=-lSimulationRuntimeC -Wl,-Bdynamic -lomcgc -lryu -lopenblas -Wl,-B$(OMC_LDFLAGS_LINK_TYPE) -lstdc++ -Wl,-Bdynamic
LDFLAGS=-L"...\lib\omc" -L"...\lib" -Wl,--stack,16777216,-rpath,"...\lib\omc" -L"...\bin" -Wl,-rpath,"...\lib" -fopenmp -Wl,-Bstatic -lregex -ltre -lintl -liconv -lexpat -lpthread -loleaut32 -limagehlp -lhdf5 -lz -lsz -Wl,-Bdynamic $(RUNTIME_LIBS)
Note the${MODELICAUSERCFLAGS}, $ (OMC_CFLAGS_OPTIMIZATION), and $(OMC_LDFLAGS_LINK_TYPE) placeholders — any of these could be set in OMEdit's child-process environment but not in mine. That would be my best guess at the root cause, but I can't verify without OMEdit retaining its build artifacts or echoing the actual compile commands somewhere.
Suggested investigation
Add an OMEdit option to keep build artifacts (.makefile, .c, .o, compile log) after successful build, for diagnostic purposes.
Have OMEdit's compile invocation explicitly dump the resolved compile/link command lines and the relevant env vars (MODELICAUSERCFLAGS, OMC_CFLAGS_OPTIMIZATION, OMC_LDFLAGS_LINK_TYPE, PATH) into DoubleActingCycle.log.
Check whether OMEdit sets any of those env vars before invoking make.
Workaround (for other users hitting this)
Translate + compile the model via OMC CLI's buildModel(...) script (using the same flag sequence OMEdit uses) and copy the resulting .exe, _init.xml, _info.json, _JacA.bin into the OMEdit cache directory (%LOCALAPPDATA%\Temp\OpenModelica\OMEdit<ModelFQN>). Then in OMEdit use File → Open Result File... to load the .mat. Do not use OMEdit's "Simulate" button — it will rebuild and overwrite the working exe with the broken one.
exe_run.txt