Follow-up to ticket #1007

[max-privato]

Description

Sorry for opening a new ticket on the same issue as #1007 , but I want to comment on that ticket, and I'm not sure that comments on closed tickets get read.
Moreover, the system does not enable me to reopen the ticket.

Ticket #1007 was closed because of
fmi2GetNominalsOfContinuousStates from FMI Specification 3.2.2.

This part of specification reads:
If the FMU does not have information about the nominal value of a continuous state i, a nominal value x_nominal[i] = 1.0 should be returned. Note that it is required that x_nominal[i] > 0.0

The first part of the sentence implies that an FMU can be without nominal values of a continuous state and in this case 1 must be assumed.

But, how the FMU tells the caller that it has not the nominal value of a continuous state? Maybe returning 0? In this case, it would be correct to set it to 1 in gru_ter, and the last part of the sentence would be interpreted that the returned nominal values must not be negative. This seems reasonable to me, even though the specification could have been clearer.

I say this also because I have hints that the fmu I included in ticket #1007 is formally correct:

• it passes check on https://fmu-check.herokuapp.com/
• it is correctly read and run by Dymola
• it is correctly read and run by OM with explicit-Euler
• it is correctly read and run by Matlab
• the FMU is created from Dymola and there is no explicit user control on x_ nominal in Dymola. I mean, mo files without nominal values for state variables are correct modelica, and users have no access to force dropping x_nominal in FMUs in Dymola. Dymola having such a huge problem would jeopardise running nearly all Dymola's FMUs in all the specification-compliant tools, which is clearly unreasonable.

Please note that in today's version the infinite loop is still there.

[lochel]

We try to respond to all comments, but a new ticket is obviously more visible. Sorry that we missed your comment.

I think the specification talks in this particular case about the exporting tool, and not the importing tool. However, it would be good to raise this issue in the FMI specification group. We can easily adapt our import if we get confirmation from the FMI specification group.

The infinite loop will disappear once the following pull request is merged: OpenModelica/OpenModelica#7407

[AnHeuermann]

How the FMU tells the caller that it has not the nominal value of a continuous state? Maybe returning 0? In this case, it would be correct to set it to 1 in gru_ter, and the last part of the sentence would be interpreted that the returned nominal values must not be negative. This seems reasonable to me, even though the specification could have been clearer.

What do yo think?

I think that the function should just return nominals=1 if the FMU has no nominals. It's easy to implement and quiet fool proof.

I must say that the FMU creating problems to SSP is read correctly in Dymola and Matlab; we'll try SystemModeler and Amesim within a couple of days. In case several other tools accept gruTer, maybe they use the same interpretation of the specification I proposed above?

Hard to tell what other importing tools are doing, but it could be that they simply don't use nominal values.

But as @lochel said, please check with the FMI specification group. Our interpretation could of course be wrong.

[AnHeuermann]

I discussed with @lochel and opened a ticket on the FMI standard: modelica/fmi-standard#1420
We will see what interpretation is correct.

[max-privato]

Thank you all for the answers.
I see that what we met is a Dymola issue. I'll get Dassault involved, quoting also modelica/fmi-standard#1420.

For OMS, in these cases, there are two options: either reject with an error or default the zero vaues to 1.0 with a warning.

OM has chosen as a general rule to be very strigtly standard compliant, and I totally agree with this position.
However, there is some difference between MO files compliancy and FMU compliancy: in case I have a modelica model which OM finds to be non compliant and rejects it, the user can change the mo text (if it is not encripted), and standard compliance is kept, and OM contributes to block spawning of dialects.

For FMI is a bit different, because the final user has not the possibility to fix the FMU (without risky tampering with xml). Moreover, An FMU returning 0 is a clear sign that the FMU author has not a value to give.
So, just in case it matters, I would be in favour of the warning solution.

However, as I said, I'll try also to contribute to fix the issue at its roots, getting Dassault systèmes involved.

[lochel]

Thanks for your thoughts. I want OMSimulator to be strictly standard compliant. However, we can introduce a flag which changes the behavior to a warning with a default 1.0 nominal value. What do you think?

[max-privato]

Thanks for your thoughts. I want OMSimulator to be strictly standard compliant. However, we can introduce a flag which changes the behavior to a warning with a default 1.0 nominal value. What do you think?

It would be perfect for me!
When you're done, can you please tell me how to load FMUs with that flag in an SSP from OMEdit?
Thank you.

[max-privato]

I've tested this morning with dev-247 and it works well.
Thank you!
I'm going to close this ticket.