I think this is fixed in r8845, but I am unsure exactly how the combi-tables should work. I changed the extrapolation method to base the value on first/last two values of the array when the value is out of range.

Thanks, this is an improvement, as the output is not forced to be zero if the input is zero.

There is still a problem, as the table output can only be defined for zero or positive values. With CombiTable1D and CombiTable1Ds it should be possible to define the output for negative and positive input values. For example the following table:

Modelica.Blocks.Tables.CombiTable1Ds combitable1ds2(columns = {2}, table = [-10,20;0,0;10,10]) ;

should give the following results:
Input,Output
-10, +20
0, 0
+10,+10

With your fix, it gives
-10,-10 (extrapolated from the positive part of the table)
0,0
+10,+10

It looks as if the negative part of the table is ignored, and the output is extrapolated for negative inputs.

I think the underlying problem is that the function ModelicaTables_CombiTable1D_init (in \c_runtime\ModelicaExternalC\ModelicaTablesImpl.c) calls omcTableTimeIni to initialise the table, and forces the 'start time' to 0.0, so the negative part of the table is never used.

Ok, I got it

str := "

model TrivialLookupTable 

  Modelica.Blocks.Tables.CombiTable1Ds t(table = [-10,20;0,0;10,10], columns = {2}); 

equation 

  t.u = time;

end TrivialLookupTable;

";

loadString(str);getErrorString();



simulate(TrivialLookupTable,startTime=-15,stopTime=15,method="euler",numberOfIntervals=12);

arr:=-15:2.5:15;

val(t.y[1], arr);getErrorString();

Now gives:

time: {-15.0,-12.5,-10.0,-7.5,-5.0,-2.5,0.0,2.5,5.0,7.5,10.0,12.5,15.0}

t.y[1]: {30.0,25.0,20.0,15.0,10.0,5.0,0.0,2.5,5.0,7.5,10.0,12.5,15.0}

Which I believe is correct