Opened 5 years ago
Closed 5 years ago
#5696 closed defect (fixed)
[RUNTIME] Allow to combine -override and -overrideFile as otherwise it won't work from OMEdit
Reported by: | Adrian Pop | Owned by: | Lennart Ochel |
---|---|---|---|
Priority: | high | Milestone: | 1.14.0 |
Component: | Run-time | Version: | |
Keywords: | Cc: |
Description
Currently OMEdit uses -override to override the start, stop, etc:
C:/temp/TestOverride/TestOverride.exe -port=51307 -logFormat=xmltcp -override=startTime=0,stopTime=1,stepSize=0.002,tolerance=1e-6,solver=dassl,outputFormat=mat,variableFilter=.* -r=C:/temp/TestOverride/TestOverride_res.mat -w -lv=LOG_SOLVER,LOG_STATS -inputPath=C:/temp/TestOverride -outputPath=C:/temp/TestOverride
If one would add to OMEdit simulation flags:
-overrideFile=c:/home/adrpo33/dev/override.txt
the simulation will exit with error as you cannot currently combine -override
with -overrideFile
Change History (5)
comment:1 by , 5 years ago
comment:2 by , 5 years ago
Some input from olivleno:
About your proposed solution:
Suppose one has setup his model to be initialized from a file.
Then he is running the simulation in OMEdit and want to fine tune the parameters by changing the values and running the simulation.
I'm not sure when and how OMEdit is using override to set values, but I'd assume that according to your proposal the user would get an error message, e.g. parameter xy is already overiden by a file.
Then the user would have to remove xy from the file until he has figured out a better value. Then he will have to restore previous condition of the file. As long he's only changing one parameter at a time this might work. But if he's performing a full blown parameter study or optimization then he's in trouble.
The proposed solution might be easy to implement but is for sure not user friendly.
Another question is, if it might collide with other parameter changing modules like OMOptim?
In the scenario above I'd propose that instead of an error, a warning is given saying: The modified parameter xy will overrule the value from the file abc.txt. It's easier for the user to remove an undesired modification, if he wants the file to dominate, than the other way round.
comment:3 by , 5 years ago
PR: https://github.com/OpenModelica/OpenModelica/pull/591
implements this now, you can use both -override and -overrideFile and you get a warning if the same variable is used again.
adrpo33@ida-0030 MINGW64 /c/home/adrpo33/dev/OMTesting/override $ cat override.txt b=5 c=6 adrpo33@ida-0030 MINGW64 /c/home/adrpo33/dev/OMTesting/override $ ./TestOverride.exe -override=stopTime=1,b=1 -overrideFile=override.txt -lv=LOG_ALL | grep overrid LOG_SOLVER | info | using -override=stopTime=1,b=1 and -overrideFile=override.txt LOG_SOLVER | info | read override values from file: override.txt LOG_SOLVER | info | -override=stopTime=1,b=1 LOG_SOLVER | info | -overrideFile=b=5,c=6 stdout | warning | You are overriding variable: b=1 again with b=5. LOG_SOLVER | info | override b = 5 LOG_SOLVER | info | override c = 6 LOG_SOLVER | info | override done!
Not sure how this is handled in the C++ runtime, I will have a look.
comment:4 by , 5 years ago
Milestone: | Future → 1.16.0 |
---|
comment:5 by , 5 years ago
Milestone: | 1.16.0 → 1.14.0 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
See also:
https://www.openmodelica.org/forum/default-topic/2116-issue-with-simulation-flag-override-omedit