Opened 9 years ago
Last modified 7 years ago
#3454 new defect
Wrong results after the latest back end changes
Reported by: | Lennart Ochel | Owned by: | Lennart Ochel |
---|---|---|---|
Priority: | high | Milestone: | Future |
Component: | FMI | Version: | |
Keywords: | Cc: | Marcus Walther, Rüdiger Franke, Niklas Worschech |
Description
There are wrong results for the following two fmu tests after the latest back end changes (#3452):
openmodelica/cppruntime/fmu/modelExchange/1.0/CoupledClutches_FMU1_CPP.mos openmodelica/cppruntime/fmu/modelExchange/2.0/CoupledClutches_FMU2_CPP.mos
Change History (8)
comment:1 by , 9 years ago
Cc: | added |
---|
comment:2 by , 9 years ago
comment:3 by , 9 years ago
I have added a debug flag that puts all start values hard coded into the c++ code. With this modification, the c++ runtime Bouncing-Ball-FMU can be correctly imported and simulated with the c-Runtime. However, this will not fix the issue with the CoupledClutches. Who is responsible for the FMU-import and can be added to this ticket? We really need a working FMU export / import.
Besides that I've noticed that the FMU c++ import is broken. We have used the code generated by the c-runtime for the import, but it seems that the c-runtime code is not longer compatible to the c++-runtime code, especially for models with events. I think that's not an issue, because we do not really need a c++ based fmu-import in OMC. Thus I will change the c++ based FMU-tests to use the c-runtime as import-environment.
comment:7 by , 8 years ago
Milestone: | 1.11.0 → 1.12.0 |
---|
Milestone moved to 1.12.0 due to 1.11.0 already being released.
comment:8 by , 7 years ago
Milestone: | 1.12.0 → Future |
---|
The milestone of this ticket has been reassigned to "Future".
If you think the issue is still valid and relevant for you, please select milestone 1.13.0 for back-end, code generation and run-time issues, or 2.0.0 for front-end issues.
If you are aware that the problem is no longer present, please select the milestone corresponding to the version of OMC you used to check that, and set the status to "worksforme".
In both cases, a short informative comment would be welcome.
The BouncingBall-model has the same issue if it is translated to a model exchange FMU with the c++ runtime. I started to debug it and I noticed that the height "h" of the ball is wrong at the beginning. The modelDescription says the start value should be 1:
But the setReal-Function is not called for the value with reference 0, it is only called for the values with the references 5 and 6. The function setContinuousStates is called later and with calculated values (that are wrong as well), so the height of the ball is 0 at the beginning.
@lochel: Do you know why this value is not set according to the modelDescription at the beginning? Have I overlooked something?