OME fails to translate a model due to assigning min, max and nominal to dummy boolean (New frontend)

[filip.jezek@…]

The new frontend wrongly generates max min and nominal values for generated boolean. The boolean is created for generated WHEN condition.

Translation log:

ADAN_main.ADAN_main_AdanVenousRed_Safaei_Experiments_simple_phi_base_02nls.c: In function 'initializeStaticDataNLS2715':
ADAN_main.ADAN_main_AdanVenousRed_Safaei_Experiments_simple_phi_base_02nls.c:531:92: error: 'BOOLEAN_ATTRIBUTE {aka struct BOOLEAN_ATTRIBUTE}' has no member named 'nominal'
   sysData->nominal[i] = data->modelData->booleanVarsData[4].attribute /* $whenCondition5 */.nominal;

ADAN_main.ADAN_main_AdanVenousRed_Safaei_Experiments_simple_phi_base_02nls.c contains:

void initializeStaticDataNLS2715(void *inData, threadData_t *threadData, void *inSystemData)
{
  DATA* data = (DATA*) inData;
  NONLINEAR_SYSTEM_DATA* sysData = (NONLINEAR_SYSTEM_DATA*) inSystemData;
  int i=0;
  /* static nls data for $whenCondition5 */
  sysData->nominal[i] = data->modelData->booleanVarsData[4].attribute /* $whenCondition5 */.nominal; <<< HERE IS THE ERROR
  sysData->min[i]     = data->modelData->booleanVarsData[4].attribute /* $whenCondition5 */.min; <<< HERE IS THE ERROR
  sysData->max[i++]   = data->modelData->booleanVarsData[4].attribute /* $whenCondition5 */.max; <<< HERE IS THE ERROR
  /* static nls data for heartComponent.aorticValve.passableVariable */
  sysData->nominal[i] = data->modelData->realVarsData[147].attribute /* heartComponent.aorticValve.passableVariable */.nominal;
  sysData->min[i]     = data->modelData->realVarsData[147].attribute /* heartComponent.aorticValve.passableVariable */.min;
  sysData->max[i++]   = data->modelData->realVarsData[147].attribute /* heartComponent.aorticValve.passableVariable */.max;
  /* initial sparse pattern */
  initializeSparsePatternNLS2715(sysData);
}

Related #5476 (but the tearing is not disabled), #4686 (but not fixed), #3045 (but passing check and still the same output).

Using the not-so-old dev nightly:

Connected to OpenModelica v1.16.0-dev-102-g5c1a0234a (64-bit)
Connected to OMSimulator v2.1.0-dev-147-g36ec2c7-mingw

[filip.jezek@…]

Testing model, not working ATM. Requires Physiolibrary.

[Per Östlund]

This doesn't look like a frontend issue, it looks more like a code generation or possibly simcode issue.

[Francesco Casella]

@mahge930, would you mind having a look?

Thanks!

[Mahder Alemseged Gebremedhin]

Replying to casella:

@mahge930, would you mind having a look?

Thanks!

Of course. This is more of a simulation code related issue. It is not always easy to tell what the intention of the code is but I will try and figure it out.

/* static nls data for $whenCondition5 */
  sysData->nominal[i] = data->modelData->booleanVarsData[4].attribute /* $whenCondition5 */.nominal; <<< HERE IS THE ERROR
  sysData->min[i]     = data->modelData->booleanVarsData[4].attribute /* $whenCondition5 */.min; <<< HERE IS THE ERROR
  sysData->max[i++]   = data->modelData->booleanVarsData[4].attribute /* $whenCondition5 */.max; <<< HERE IS THE ERROR

All of these seem to be pointless operations here. Since they variables are updated immediately by the next three statements. Maybe they are not needed at all.

I will look in to it.

[Mahder Alemseged Gebremedhin]

Oh never-mind. I overlooked the increment i++. The lines are not pointless actually. I will see.

[Francesco Casella]

Replying to mahge930:

Oh never-mind. I overlooked the increment i++.

I love C++ ;)

[Mahder Alemseged Gebremedhin]

This turned out to be a back-end issue. The Boolean variable $whenCondition5 is picked as an iteration variable for the NLS in question.

I am reassigning this to Karim. He has agreed to investigate it more.

---

I will at least move the i++ to a new statement.

[Martin Sjölund]

I have this happen for Integers as well as Booleans. We need to make sure only reals are iteration variables because fixing the code generation is of course wrong (the NLS does not know if that only value 1 is true/false; it will try with 0.33337).

[Francesco Casella]

See also #5797

[filip.jezek@…]

BUMP - any news on this? This prevents us from dissemninating the model into the community, as now it works in proprietary software only.

Can you at least suggest a workaround?

Thanks a ton in advance!

[Francesco Casella]

@Karim, @AnHeuermann, see comment:6.

I guess this should be an easy fix, just avoid picking when conditions as iteration variables. In fact, does it ever make sense to pick any auxiliary $XXXX variable as iteration variable?

[filip.jezek@…]

The same issue is reported here. ​https://github.com/OpenModelica/OpenModelica/issues/6977

Mahder suggests using --tearingMethod=minimalTearing compilation flag which workarounds this particular problem (but maybe introduces other one, needs more investigation]

[Andreas Heuermann]

Closing this issue, because it's a duplicate of ​https://github.com/OpenModelica/OpenModelica/issues/6977 and I like GitHub issues more ;-)

[Francesco Casella]

For the record, we haven't yet switched to GitHub for issue tracking.

I am monitoring all issues on trac and I'm using it for project management at the moment. Using both systems at the same time would be a nightmare. Please do not open issues on GitHub yet until we have properly retired trac.

Thanks!

[filip.jezek@…]

@casella well this is a whole other discussion, but I hope the github's 1335 open issues (being issued and closed on regular basis - see ​https://github.com/OpenModelica/OpenModelica/issues?q=is%3Aissue+is%3Aclosed ) won't mess your planning :)

For a non-insider its hard to tell which system to use and the github would be my first choice, as the sources are already kept there. On top, there are project management tools bundled (e.g. kanban cards tied with the issues), so I would cautiously recommend switching to github entirely as soon as possible.

[Francesco Casella]

Replying to filip.jezek@…:

@casella well this is a whole other discussion, but I hope the github's 1335 open issues (being issued and closed on regular basis - see ​https://github.com/OpenModelica/OpenModelica/issues?q=is%3Aissue+is%3Aclosed ) won't mess your planning :)

We have initiated the transition already. Adrian recognized that all existing PRs on github had numbers below 1000 and all tickets on trac had numbers above that. So he imported all trac tickets as placeholders in order to issue new PRs and future issues above the highest trac ticket numbers. So, basically, we do not overlap the two numberspaces. But currently they are just placeholders. Except a few tickets that were opened there. I guess they'll have to wait for a while...

For a non-insider its hard to tell which system to use and the github would be my first choice, as the sources are already kept there. On top, there are project management tools bundled (e.g. kanban cards tied with the issues), so I would cautiously recommend switching to github entirely as soon as possible.

I agree.

@adrpo, can we try to complete the transition before the end of 2020? Otherwise this is going to be messy.