NF cannot evaluate structural parameter during NFTyping.typeComponents

[Francesco Casella]

There are over 50 models in the Buildings library that fail for the same reason, see, e.g., ​Buildings.ThermalZones.Detailed.BaseClasses.Examples.InfraredRadiationExchange. The NF reports

[Buildings latest/HeatTransfer/Data/OpaqueConstructions.mo:9:4-11:111:writable]
Error: Could not evaluate structural parameter (or constant): 
irRadExc.datConExt.layers.nLay which gives dimensions of array: material.
Array dimensions must be known at compile time.

Fixing this issue would improve the coverage of Buildings substantially.

[Francesco Casella]

Andrea.Bartolini provided me a MWE to reproduce the same error (also attached)

package TestRecord
  record CalcData
    parameter Integer N = 1;
    Real[N] val;
  end CalcData;

  model M1
    input CalcData calcData;
    Real x[calcData.N];
  equation
    x = calcData.val.^2;
  end M1;

  model M2
    constant Integer Nact = 5;
    CalcData calcVal(N=Nact);
    M1 m1(calcData = calcVal);
  equation
    calcVal.val = fill(time,Nact);
  end M2;
end TestRecord;

When you try to compile M2, you get

[1] 23:01:21 Translation Error
[TestRecord: 4:5-4:16]: Could not evaluate structural parameter (or constant): 
m1.calcData.N which gives dimensions of array: val. 
Array dimensions must be known at compile time.

I suspect the issue is the same that plagues the Building library, which often uses record to hold datasheets, which may contain structural parameters for array dimensions.

As far as I understand this model is perfectly legal. Dymola accepts it also in pedantic mode.

[Francesco Casella]

See also #6126.