Incorrect report of Arraytype mismatch

[georg.schneider@…]

Hello!

I encountered some buggy behaviour when checking a model in our library BuildingControlLib. We defined an array in a submodel as (pseudo modelica syntax)

model myModelA

Real myArrayName[:,5] ;

end myModelA;

and modified it by some similar defined array

model myModelB

myModelA inst( myArrayName = myArrayB );
Real myArrayB[:,5];

end myModelB;

As far as I know it is equally allowed to define an array either

Real[:,5] myArray ;

or

Real myArray[:,5] ;

Please correct me if I am wrong and it would be interesting if this is a bug or not. The model runs fine in Dymola 2017.

The library is hosted on github: ​https://github.com/TechnicalBuildingSystems/BuildingControlLib

The error occurs when checking model

BuildingControlLib.BuildingControl.VDI3813.ApplicationFunctions.Examples.TesterTimeProgramEnergyMode

With error message in OMEdit console:

Type mismatch in modifier of component timeProgramEnergyMode.functionality.weeklyScheduleinputIntervalsAndValue, declared type Real[:,5], got modifier timeProgramEnergyMode.functionality.PAR_WSCH of type #T_UNKNOWN#.

[georg.schneider@…]

Invesitigating further on the issue the cause is likely not the array definition.

We compile an array parameter from integer array slices. Apparently this causes the problems.

Example with problem:

Real mySlice[5] = {1,1,1,1,1}
Real myArray[:,5] = {mySlice,{1,1,1,1,1}}

Example without problem:

Real myArray[:,5] = {{1,1,1,1,1},{1,1,1,1,1}}

Best

Georg

[Per Östlund]

I made a minimal model that shows the issue. The issue seems to be a redeclare modifier that uses a parameter that in turn uses parts of the redeclared element. I'm pretty sure we already have a ticket with the same issue, but I can't find it right now. But this is unlikely to be fixed in the current frontend, so I'm assigning it for the new frontend (where it already seems to work, except for some unrelated issues due to some not yet implemented functionality).

[georg.schneider@…]

Thanks! the minimal model looks fine.

If there is a complementary issue please merge or delete this one.

[Francesco Casella]

With the NF, flattening TimeProgramEnergyMode currently gives:

[1] 20:19:39 Translation Error
Internal error Instantiation of Test.TimeProgramEnergyMode failed
with no error message.

[Per Östlund]

With the fixes in 0c48541 and 427f498b the TesterTimeProgramEnergyMode model now simulate successfully using the new frontend (using compiler flag -d=newInst). If you wish to try it out you can use the nightly builds (the mentioned fixes should be in the next nightly build), but be aware that the new frontend is still not feature complete.