2D table extrapolation documentation clarification request

[paultjevdh]

Hello,

I use the 2D table function in Dymola to lookup a periodic function in one direction.
The documentation simply states
extrapolation = 3: Periodically repeat the table data (periodical function).
This does not mention the fact that it is assumed (by dymola) that the first and last rows of the table are identical (for example, if the tabulated function is a cosine in the u1 direction, the table should cover the values from 0 up to and including 2pi). When the table is periodically extrapolated, these rows will be overlapping.

This is a problem since it is just as justifiable to implement the phase of the cosine as an array [pi/10, 2pi/10, 3pi/10, ..., 19pi/10, 20pi/10], thus excluding the 0 at the start. This kind of table can simply be concatenated, without overlap.

It seems openmodelica behaves the same as dymola. I don't know how other programs implement this.
I think the documentation should make the distinction clear, since making wrong assumptions will lead to errors.

Best regards,
Paul van der Hulst

[beutlich]

In fact, the periodic extrapolation is independent of the continuity. There also is no assumption (by the Modelica simulation tool) on continuity.

Take this example:

model T3793
  extends ModelicaTest.Tables.CombiTable2Ds.Test6(
    t_new(
      extrapolation=Modelica.Blocks.Types.Extrapolation.Periodic));
  annotation(experiment(StartTime=0, StopTime=60), uses(ModelicaTest(version="4.0.0")));
end T3793;

The simulation shows the expected "jump" at t=50s for t_new.y.

[paultjevdh]

Hi,
The provided example does not show the issue because the table data in the example is not intended to be periodic.
What I meant is illustrated by this example:

model Test6 "Bilinear, u1 and u2 extrapolation"
  extends Modelica.Icons.Example;
  extends ModelicaTest.Tables.CombiTable2Ds.TestDer(t_new(table = [0, 0; 0, -1; 1, 0; 2, 1; 3, 0], extrapolation = Modelica.Blocks.Types.Extrapolation.Periodic));
  Modelica.Blocks.Sources.ContinuousClock clock1
    annotation (Placement(transformation(extent={{-80,20},{-60,40}})));
  Modelica.Blocks.Sources.Constant const(k = 0)  annotation(
    Placement(transformation(origin = {-70, -4}, extent = {{-10, -10}, {10, 10}})));
equation
  connect(clock1.y, t_new.u1) annotation(
    Line(points = {{-59, 30}, {-52, 30}, {-52, 16}, {-42, 16}}, color = {0, 0, 127}));
  connect(const.y, t_new.u2) annotation(
    Line(points = {{-58, -4}, {-42, -4}, {-42, 4}}, color = {0, 0, 127}));
  annotation(
    experiment(StartTime = 0, StopTime = 10),
    uses(Modelica(version = "4.0.0")));
end Test6;

The table data is meant to describe a triangle wave with period 4s. It is naively assumed that the interval of 1s between the points is implicitly repeated in the periodic extrapolation, thus that the start of the next pass through the data is at 4s.
However, the output is this:

Apparently the last point of the table virtually overlaps the first point since the output at 3s is equal to the table value, but for t>3 the output is interpolated as limit for t down to 3s = table(0) = -1.
I formulated a bit backwards in the OP, but what I meant is that to get proper output for a periodic function like this, you have to add an additional final row which contains a copy of the first row points (thus add ";4,-1")
I understand now that the way this is the way it is because the first (abscissa-) row and column need not be equidistant, thus modelica cannot know how long the interval is between the end of the table and the start of the next pass.
Still I think that an example like this should be added to the documentation to illustrate the extrapolation behaviour.

[beutlich]

The table data is meant to describe a triangle wave with period 4s.

Hm, that's not what is given in the data: u_min[1] = 0 and u_max[1] = 3, thus the period is 3s.

[paultjevdh]

And that explanation is exactly what is missing from the documentation, I think.
I know now that this is how modelica interprets the provided table definition. My point is that the documentation is too limited for a new user to convey this.
It says "Periodically repeat the table data (periodical function)". When you read that, it is easy to assume that the data would repeat after an implicit next interval: why would I need to enter the same data twice (for the first and last point) when it is supposed to repeat?. For example: I defined the table with data at points 0, 1, 2 and 3. I could assume that the next period would start at 4, the same way you would repeat/concatenate any equidistant data. That interpretation does not violate the present documentation.
My MWE clearly demonstrates that this assumption was wrong and I do need to enter the last (=first) value , but I originally had a 400 point table with a cosine-like function and in that case it was difficult to spot my modeling error.
I believe that this could have been avoided by better documentation.

[paultjevdh]

I got one more observation on the implementation of the periodic extrapolation: the method that is used does not actually result in a periodic output without special (undocumented) precautions by the user. I shifted the table in the MWE to the [4,7] interval and simulated with experiment(StartTime = 0, StopTime = 10, Tolerance = 1e-06, Interval = 0.2).
I got this output:

Extrapolation before and after the interval gives different results.
For all t<= 4, the -1 is hit at 3 s intervals, but not the 0 during the falling section.
For all t>=7, the 0 is on the falling section (at 7s + n*3s where n is integer) but the -1 is no longer reached.
This is a result of the fact that the first and last values are only included in the base interval [4,7]. For the extrapolations, one or the other is only taken as a limit value, e.g. the limit for t->4 is 0, but at t=4 the value is -1.

[beutlich]

I got one more observation on the implementation of the periodic extrapolation

This one actually is by design as there is no guarantee that the interval boundary is hit. (FYI: CombiTimeTable has this feature (by means of time events).)

[paultjevdh]

Yeah, but time is only one of so many possible inputs of a table. The MWE was not representative with regards to that aspect of my actual model.

[beutlich]

For example: I defined the table with data at points 0, 1, 2 and 3. I could assume that the next period would start at 4, the same way you would repeat/concatenate any equidistant data.

Your assumption is not valid and bases on the idea of equvidistant sample points. However, there is no such concept of equvidistant sample points within the table blocks of MSL. Sample points can be arbitrary.

Not sure how to proceed here. Feel free to open a PR against the documentation of the table blocks in master branch. Otherwise I prefer to close this issue as worksforme.

Edit: You might be interested in my notes on periodic extrapolation of the CombiTimeTable (with reliable time event detection) which does not work for the other table blocks (like CombiTable1D and CombiTable2D): https://2014.international.conference.modelica.org/proceedings/html/submissions/ECP14096893_BeutlichKurzbachSchnabel.pdf -> Section 2.2.

[paultjevdh]

I referenced this issue in my PR #4287