SSP use from OMEdit causes Infinite loop while showing messages

[max-privato]

Description

I have a Work-in-progress ssp.
When I run it OMEdit enters an infinite loop in showing error messages and to see them I must get a screen print and copy somewhere.
Even if the model has mistakes, this behaviour is unexpected.

Sorry for not creating a MWE, but I don't have time now. In case of need, I could try next week.

Steps to reproduce the behavior

Load ErrorLoop.ssp and run it

Expected behavior

Screenshots

Version and OS

OM: 1.18-deb 224, Win10 64 bit

• Version: [OMSimulator --version]
• OS: [e.g. Win10, 64bit]

ErrorLoop.zip

[lochel]

@arun3688 can you please test it on Windows?

[arun3688]

@lochel I tested and it is running into infinite loop with the following error

>>> OMSimulator ErrorLoop.ssp                                                                                                                                 
warning: GRU_TER (): fmi2SetupExperiment: tolerance control not supported for fmuType fmi2ModelExchange, setting toleranceDefined to fmi2False              
info:    maximum step size for 'GruTerOne.Root': 0.100000                                                                                                   
info:    Result file: GruTerOne_res.mat (bufferSize=10)                                                                                                     
                                                                                                                                                            
[CVODE ERROR]  cvInitialSetup                                                                                                                               
  Initial ewt has component(s) equal to zero (illegal).                                                                                                     
                                                                                                                                                            
error:   [doStep] SUNDIALS_ERROR: CVode() failed with flag = -22                                                                                            
                                                                                                                                                            
[CVODE ERROR]  cvInitialSetup                                                                                                                               
  Initial ewt has component(s) equal to zero (illegal).                                                                                                     
                                                                                                                                                            
error:   [doStep] SUNDIALS_ERROR: CVode() failed with flag = -22                                                                                            
                                                                                                                                                            
[CVODE ERROR]  cvInitialSetup                                                                                                                               
  Initial ewt has component(s) equal to zero (illegal).                                                                                                     
                                                                                                                                                            
error:   [doStep] SUNDIALS_ERROR: CVode() failed with flag = -22                                                                                            
                                                                                                                                                            
[CVODE ERROR]  cvInitialSetup                                                                                                                               
  Initial ewt has component(s) equal to zero (illegal).                                                                                                     
                                                                                                                                                            
error:   [doStep] SUNDIALS_ERROR: CVode() failed with flag = -22

[arun3688]

@max-privato Could you change the solver to euler and test it, It is working for me

As a workaround you can continue to use Euler solver and we try to fix the problem with cvode

[arun3688]

@AnHeuermann can you look into the error messages with cvode solver

[max-privato]

As a workaround you can continue to use Euler solver and we try to fix the problem with cvode

ok. Thank you.
I'm impressed that it works so well. It is a rather complex model with several non-linearities, hystereses, homotopy at initialization, etc.
It is my first serious ssp test, and is a very good starting point!
It is only slow in comparison with Dymola. Probably cvode will be much faster.

[AnHeuermann]

From what I understand from the CVODE sources the input consistency checks for the first step are failing because the initial error weights have a component equal to zero.

I can see that we have

relativeTolerance: 0.000100
absoluteTolerance:
               1e-06
                  0
                  0
                  0
                  0
                  0
                  0
                  0
                  0
                  0
                  0
                  0
                  0
                  0
                  0
                  0
                  0

With scalar tolerances (1e-4 , 1e-6) the simulation runs successfully.

So why are the tolerances 0? Because some nominals are 0, which are used to comupte the absolute tolerance.

states_nominal of GruTerOne.Root.Interface:
    states_nominal[0]: 1.000000
states_nominal of GruTerOne.Root.GRU_TER:
    states_nominal[0]: 0.000000
    states_nominal[1]: 0.000000
    states_nominal[2]: 0.000000
    states_nominal[3]: 0.000000
    states_nominal[4]: 0.000000
    states_nominal[5]: 0.000000
    states_nominal[6]: 0.000000
    states_nominal[7]: 0.000000
    states_nominal[8]: 0.000000
    states_nominal[9]: 0.000000
    states_nominal[10]: 0.000000
    states_nominal[11]: 0.000000
    states_nominal[12]: 0.000000
    states_nominal[13]: 0.000000
    states_nominal[14]: 0.000000
    states_nominal[15]: 0.000000

So the FMU GruTerOne.Root.GRU_TER is not according to the specification, see fmi2GetNominalsOfContinuousStates from FMI Specification 3.2.2 Evaluation of Model Equations.

I will add a check if the nominals of an imported FMU are greater then 0.
But this will only give a better error report. The FMU is still wrong and needs to be fixed. From the modelDescription it seems that it is a Dymola issue (generationTool=Dymola Version 2021 (64-bit), 2020-05-13).

[AnHeuermann]

I could of course add something like

if illigealNominals
  use some default scalar tolerances

and only issue a warning instead of a hard error.

[lochel]

Thanks @AnHeuermann. The new error messages state the issue rather clear. Should we add a flag to use the default scalar tolerances in case of illegal nominal values?

[AnHeuermann]

That could work for this issue but has the potential to crash with strange errors for other models. Having a nominal of 0 is a problem. The absolute tolerance doesn't matter that much.

We could set nominal values to 1 for the problematic ones and continue with that. But of course if the FMU is expecting them to be different we could run into problems.
I can implement that if you want.

[lochel]

I agree with your argumentation, so no need for further changes and I'll close this issue. @max-privato please feel free to reopen the issue if there is more to do.

[max-privato]

In fmi2GetNominalsOfContinuousStates from FMI Specification 3.2.2
I read:

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.

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 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?

Yes, the FMU is created using Dymola from a Modelica package we developed. I tried to create the same FMU using OM, but had an error when importing the fmu back, for which I'll open a separate ticket.

[lochel]

The next nightly build should contain all the required changes.