Issue with CombiTimeTable in NF

[Francesco Casella]

Please check ​ScalableTestSuite.Elementary.Tables.Models.CombiTimeTable. The following error is generated

[OpenModelica/OMCompiler/Compiler/BackEnd/BackendDAECreate.mo:1121:9-1121:82:writable]
Error: Internal error function lowerKnownVarkind failed
Error: Internal error BackendDAECreate.lowerKnownVar failed for   protected model 
Modelica.Blocks.Types.ExternalCombiTimeTable combiTimeTable.tableID = 
Modelica.Blocks.Types.ExternalCombiTimeTable.constructor(
"NoName", if false and combiTimeTable.fileName <> "NoName" and not Modelica.Utilities.Strings.isEmpty(combiTimeTable.fileName)
then combiTimeTable.fileName 
else "NoName", combiTimeTable.table, combiTimeTable.startTime / combiTimeTable.timeScale,
combiTimeTable.columns,
Modelica.Blocks.Types.Smoothness.ConstantSegments, combiTimeTable.extrapolation) 
"External table object";

I'm not sure what is the root cause, but this issue affects all the models using CombiTables in the MSL also.

[Francesco Casella]

This issue is now solved. The model now breaks because of this error:

[CodegenCFunctions.tpl:6355:13-6355:13:writable] Error: Template error: ASUB non-scalar linspace(5.026548245743669, 0.0, 10)[(1:10)[10]]. The inner exp has type: Real[10]. After ASUB it is still an array: Real[10]..

which I guess is related to lack of function evaluation.

[Per Östlund]

Replying to casella:

This issue is now solved. The model now breaks because of this error:

[CodegenCFunctions.tpl:6355:13-6355:13:writable] Error: Template error: ASUB non-scalar linspace(5.026548245743669, 0.0, 10)[(1:10)[10]]. The inner exp has type: Real[10]. After ASUB it is still an array: Real[10]..

which I guess is related to lack of function evaluation.

I assume the issue for this particular error message might be the (1:10)[10] used to subscript the expression. Evaluating the function would of course fix the issue, but we shouldn't be creating such subscripts in the first place.

[Per Östlund]

Fixed in 9dd00c3, the issue was that the NF stores the full type in a range expression while the old only stores the element type. Using the element type when creating the DAE makes the backend able to simplify expressions such as these correctly. The model now fails due to #4863.