ModelicaStandardLibrary icon indicating copy to clipboard operation
ModelicaStandardLibrary copied to clipboard

Insufficient dimension check in 2D tables

Open paultjevdh opened this issue 3 years ago • 3 comments

Hello, I generated a table and accidentally swapped the dimensions in the header. That was stupid, but the error message wasn't helpful either. This triggers an error like "The values of the first column of table "testTable(11,4)" are not strictly increasing because testTable(3,1) (=7.000000) >= testTable(4,1) (=-1.000000)."

Consider the model below (set the testtable_dim.txt path appropriately) and attached table file. When tableName="testTable",, the model runs fine. When the header dimensions are swapped as in the second table (tableName="testTable2",) the simulator (Dymola and OpenModelica) complains that the first column isn't strictly increasing. This error message only becomes understandable when the table is reformatted to match the table header (as in testTable3). Column 1 now reads 0 3 7 -1 -5 -9 ....

Apparently the dimensions of the table in the file are not checked against the header, but instead read as a stream, treating spaces and returns as equivalent separator characters without further checking. This means table formatting is free, as long as the total number of entries is correct (there is an error when the table is either too long or too short). I'd like to suggest that the dimensions of the table are also checked when reading it from file (together with the total number of entries), before checking sanity of the first row and column.

Best regards, Paul van der Hulst

model twod_table_test
  Modelica.Blocks.Tables.CombiTable2Ds combiTable2Ds(
    tableOnFile=true,
    fileName="C:\\Temp\\werkmap_svn\\Modelica\\MWEs\\testtable_dim.txt",
    tableName="testTable",
    smoothness=Modelica.Blocks.Types.Smoothness.LinearSegments,
    extrapolation=Modelica.Blocks.Types.Extrapolation.Periodic);
equation 
    combiTable2Ds.u1 = 4;
    combiTable2Ds.u2 = 2;
end twod_table_test;

testtable_dim.txt

paultjevdh avatar Jul 04 '22 08:07 paultjevdh

The MOS table format (i.e., of files starting with the #1 header) is rather lenient (or error-prone as you observed it) w.r.t. row and column dimension checks. By design, only the total number of elements is checked (and reported).

I recommend to use a stricter table format (e.g., CSV, JSON or MAT) as available by the ModelicaTableAdditions library. Additionally you get the latest bug fixes there. Would this be applicable for you?

beutlich avatar Jul 04 '22 18:07 beutlich

Hi, That sounds promising, but apart from the addition of a delimiter character and headerlines for csv files, there seems to be no info on how to use this. I can only assume that the file format should be the same, which gives no obvious advantages, since documentation is inherited from MSL.

Best regards, Paul

paultjevdh avatar Jul 05 '22 08:07 paultjevdh

Documentation of ModelicaTableAdditions blocks is not inherited (not possible in Modelica language), but copied and extended. You can use these table blocks just like any other block.

beutlich avatar Jul 05 '22 09:07 beutlich

Closing with applying above mentioned resolutions.

beutlich avatar Aug 23 '22 13:08 beutlich