Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#6262 closed defect (fixed)

Incorrect start value for an input variable in an FMU exported from OM

Reported by: jean-philippe.tavella@… Owned by: lochel
Priority: critical Milestone: 1.17.0
Component: FMI Version: 1.16.0
Keywords: FMU Cc: AnHeuermann

Description

I try to export FMUs from models built with the recent library PowerSysPro developped by EDF.
For memory, this library is available here: https://bitbucket.org/simulage/powersyspro/wiki/Home
Important note: use the version 1.4 for OM (don't use the last version 1.5 due to discussion in ticket #6261).

Please refer to the package Examples.ExampleWithFMUs.
I try to export as FMUs for cosimulation from OM the two models MVPartOfMVLVNetwork and LVPartOfMVLVNetwork.
I can do that but the issue is related to the FMU built from LVPartOfMVLVNetwork as the start value for variable v_re (with causality=input) is 0 and it should be 230 (according to the model).

The FMU is correct when exported from Dymola.

Due to this issue, the FMU cannot be loaded in our open-source cosimulator DACCOSIM NG (https://bitbucket.org/simulage/daccosim/wiki/Home).

Change History (12)

comment:1 follow-up: Changed 3 years ago by casella

  • Cc AnHeuermann added
  • Milestone changed from 1.17.0 to 1.16.2
  • Owner changed from casella to lochel
  • Priority changed from high to critical
  • Status changed from new to assigned

The FMI 2.0.1 standard, page 56, states

If causality = "input" , the start value is used by the model as value of the input, if the input is not set by the environment.

I'm not sure if this doesn't happen with any inputs, or just with operator record (i.e. Complex) inputs.

@lochel, @AnHeuermann, can you please check and coordinate yourselves for the fix?

I would recommend to back-port the fix on the 1.16.0 maintenance branch, so it can be released in 1.16.2 together with some othe critical fixes.

comment:2 in reply to: ↑ 1 Changed 3 years ago by jean-philippe.tavella@…

Replying to casella:

The FMI 2.0.1 standard, page 56, states

If causality = "input" , the start value is used by the model as value of the input, if the input is not set by the environment.

I'm not sure if this doesn't happen with any inputs, or just with operator record (i.e. Complex) inputs.

@lochel, @AnHeuermann, can you please check and coordinate yourselves for the fix?

I would recommend to back-port the fix on the 1.16.0 maintenance branch, so it can be released in 1.16.2 together with some othe critical fixes.

I tested the FMU with an explicit input value in the model (not coming from a record) and it perfectly works! I now hope the case with more general input definitions will be fixed in 1.16.2 as proposed.

comment:3 follow-up: Changed 3 years ago by casella

  • Milestone changed from 1.16.2 to 1.17.0

@jean-philippe, @lochel will take care of that, but he can't do it this week, so you'll have to wait next year, you'll get it in 1.17.0 at the beginning of 2021.

comment:4 in reply to: ↑ 3 Changed 3 years ago by jean-philippe.tavella@…

Replying to casella:

@jean-philippe, @lochel will take care of that, but he can't do it this week, so you'll have to wait next year, you'll get it in 1.17.0 at the beginning of 2021.

Not a problem, the main point is to have a correction in 1.17.0.
I have a workaround for now.

comment:5 follow-up: Changed 3 years ago by jean-philippe.tavella@…

Not solved with OM 1.17.0-dev-315.

comment:6 in reply to: ↑ 5 Changed 3 years ago by casella

Replying to jean-philippe.tavella@…:

Not solved with OM 1.17.0-dev-315.

Most of our developers will resume work on Jan 11 :)

Last edited 3 years ago by casella (previous) (diff)

comment:7 follow-up: Changed 3 years ago by casella

@jean-philippe, at some point you should see a pull request by @lochel here on this topic, and eventually you'll see it merged in here. Then, you have to wait for the following day (assuming the nightly build process is not broken). You can compare the git hash of your nightly with the hashes on the commit page to see what commits you have in.

This way, you have everything under control. Except our developer's time, I mean :)

comment:8 in reply to: ↑ 7 Changed 3 years ago by jean-philippe.tavella@…

Replying to casella:

@jean-philippe, at some point you should see a pull request by @lochel here on this topic, and eventually you'll see it merged in here. Then, you have to wait for the following day (assuming the nightly build process is not broken). You can compare the git hash of your nightly with the hashes on the commit page to see what commits you have in.

This way, you have everything under control. Except our developer's time, I mean :)

Oh yes I see. Many thanks.

comment:9 follow-ups: Changed 3 years ago by arun3688

@jean-philippe This PR https://github.com/OpenModelica/OpenModelica/pull/7077 should fix the issue. I tested with the example PowerSysPro.Examples.ExampleWithFMUs.LVPartOfMVLVNetwork
and correct start values are exported to input v_re=230, you can test it tomorrow with the nightly builds

comment:10 in reply to: ↑ 9 Changed 3 years ago by jean-philippe.tavella@…

Replying to arun3688:

@jean-philippe This PR https://github.com/OpenModelica/OpenModelica/pull/7077 should fix the issue. I tested with the example PowerSysPro.Examples.ExampleWithFMUs.LVPartOfMVLVNetwork
and correct start values are exported to input v_re=230, you can test it tomorrow with the nightly builds

Nice, I will test it.

comment:11 Changed 3 years ago by arun3688

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:12 in reply to: ↑ 9 Changed 3 years ago by jean-philippe.tavella@…

Replying to arun3688:

@jean-philippe This PR https://github.com/OpenModelica/OpenModelica/pull/7077 should fix the issue. I tested with the example PowerSysPro.Examples.ExampleWithFMUs.LVPartOfMVLVNetwork
and correct start values are exported to input v_re=230, you can test it tomorrow with the nightly builds

Test done today with OpenModelica v1.17.0-dev-339-gb5efb3cab9. Issue is solved :-)

Note: See TracTickets for help on using tickets.