Constraints on spatialDistribution initialization

[henrikt-ma]

There are several requirements for the initialization of a spatialDistribution that I feel are missing in the specification:

1. That initialPoints cover the entire range from 0 to 1 (no need for tools to invent their own extrapolation mechanisms).
2. That initialPoints is strictly increasing instead of non-descending (making the initial state consistent with the rule that the buffer is never updated when x = x0 during simulation).
3. That initialPoints and initialValues are parameter expressions (would be confusing if time-varying expressions could be passed if only values at initialization are used).

Based on how spatialDistribution has been implemented in tools, could we expect that libraries are already complying with these requirements?

[HansOlsson]

I hope libraries are consistent with points 1 and 3, but Dymola 2025x does as far I can see not perform any of those checks.

Regarding 2, I assume the goal is to be able to handle sharp transients at the start (even though we don't handle it afterwards) so I don't want to require "increasing" instead of "non-descending".

[henrikt-ma]

Regarding 2, I assume the goal is to be able to handle sharp transients at the start (even though we don't handle it afterwards) so I don't want to require "increasing" instead of "non-descending".

It would be great if you could explain this in more detail, illustrated by a meaningful example.

[henrikt-ma]

Slight scope creep, but I'd also be interested in general constraints on where spatialDistriubution may be called.

Here is an example to start with:

equation
  out0 = if time > 1.0 then spatialDistribution(…) else 0.0;

How is this supposed to be updated at the accepted steps? (If we can agree that there is no clear way of how to handle at accepted steps, we don't need to worry about what to do for initialization.)

[HansOlsson]

Both delay and spatialDistribution are problematic if they are inside conditional code, unless the condition is a parameter-expression (after some thinking I realized it is not necessary to evaluate the condition).

[henrikt-ma]

Both delay and spatialDistribution are problematic if they are inside conditional code, unless the condition is a parameter-expression (after some thinking I realized it is not necessary to evaluate the condition).

Indeed. I suggest we open a PR about adding the necessary rules.

[henrikt-ma]

Regarding 2, I assume the goal is to be able to handle sharp transients at the start (even though we don't handle it afterwards) so I don't want to require "increasing" instead of "non-descending".

It would be great if you could explain this in more detail, illustrated by a meaningful example.

While I can see that one could go beyond the spatialDistribution pseudo-code, and allow stepwise changes to also enter the internal state during simulation, I'm afraid that most of the potential benefits are lost due to spatialDistribution not being an event-generating operator, as this means that discontinuities on the input side will turn into arbitrarily steep transitions on the output side. I suppose the end result would therefore end up very similar to when doing what the pseudo-code suggests, that is, to not let discontinuities enter the internal state during simulation.

[henrikt-ma]

I hope libraries are consistent with points 1 and 3, but Dymola 2025x does as far I can see not perform any of those checks.

Now that I have been thinking a bit about applications of spatialDistribution lately, I have realized that it is not enforcing that initialPoints cover the range from 0 to 1 that I would like to see, but just a requirement that the first point is strictly less than the last point.

Especially when combined with unit checking, I think that removing the normalization constraint would avoid some pretty error-prone scaling issues, issues which are particularly hard for library developers to detect due to the lack of (standardized, at least) ways to inspect the continuous internal state of a spatialDistribution.

[HansOlsson]

Regarding 2, I assume the goal is to be able to handle sharp transients at the start (even though we don't handle it afterwards) so I don't want to require "increasing" instead of "non-descending".

It would be great if you could explain this in more detail, illustrated by a meaningful example.

While I can see that one could go beyond the spatialDistribution pseudo-code, and allow stepwise changes to also enter the internal state during simulation, I'm afraid that most of the potential benefits are lost due to spatialDistribution not being an event-generating operator, as this means that discontinuities on the input side will turn into arbitrarily steep transitions on the output side. I suppose the end result would therefore end up very similar to when doing what the pseudo-code suggests, that is, to not let discontinuities enter the internal state during simulation.

After some additional thought I think we can drop that case, and just use increasing - unless someone else objects.

[henrikt-ma]

After some additional thought I think we can drop that case, and just use increasing - unless someone else objects.

Well, it turns out that in our comparisons with what OpenModelica does, we have found that they have event generation for their implementation of spatialDistribution, and then allowing equal points makes perfect sense. (I assume that they also allow equal points to enter the buffer during simulation, so that a discontinuous change on one side of the operator will come out as a discontinuous change on the other side.) According to our interpretation, however, to generate events is not in agreement with the specification, since spatialDistribution is not mentioned here.

In my opinion, event generation seems like a good feature, so in the end I'd be in favor of changing the specification to make this the correct behavior (and then keep the current non-decreasing rule for the initial points).

@casella, any comments on the OpenModelica behavior?

[HansOlsson]

Language group:

• The initialPoints should go from 0 to 1
• Event generation? Not now. Would need additional changes, and also for delay (for discrete-values types) - later issue