Describe spatialDistribution as event triggering

[henrikt-ma]

We decided to make both delay and spatialDistribution event triggering operators, but so far the specification has only been updated for delay. This PR does it also for spatialDistribution.

At least to me, trying to capture the intricacies of event triggering in the pseudo-code for spatialDistribution doesn't sound like a good idea. Instead, I'd like us to consider the option of throwing out the pseudo-code, now that it is becoming even more remote from an actual implementation.

Note that we haven't test-implemented this in System Modeler, so I am counting on others to verify that the few things I have added regarding event triggering is in agreement with what has already been "test-implemented" in other tools.

[HansOlsson]

Note that this will take some time, due to the need to check the implementations (which are more complicated than for delay).

[henrikt-ma]

I had the impression that we already had the necessary test implementations in some tools? @casella, @gkurzbach?

[HansOlsson]

I had the impression that we already had the necessary test implementations in some tools? @casella, @gkurzbach?

Well, at least it will take more time for me to check (including checking whether we have a test-implementation).

Specifically for the test-implementations it would be good to understand exactly which events are propagated (just discrete-time expressions? any change? any minimum discontinuity to avoid events bouncing back and forth and generating more and more events?)

[henrikt-ma]

Specifically for the test-implementations it would be good to understand exactly which events are propagated (just discrete-time expressions?

Just like delay, I thought it was obvious that we were not restricting this to discrete-time expressions.

However, I realize that spatialDistribution has a potential source of discontinuity which we don't have for delay, namely the change of transport direction. However, I would hope that it is the model's choice of event generation for positiveVelocity that will determine whether a change of direction should result in a discontinuity in the internal distribution. Would that make sense?

any change? any minimum discontinuity to avoid events bouncing back and forth and generating more and more events?)

I'd say we should specify this with the same level of detail as for delay. This is how it is formulated for delay, and I will add a similar statement to this PR:

It is a quality of implementation to avoid excessive generation of events by only preserving significant discontinuities.

[HansOlsson]

I notice that it was now generalized to non-Reals. I can to some extent see that it makes sense, but I'm not sure if I have seen any use-case for it - and I don't know how much extra issues it brings. It may be easier to skip that part.

However, I realize that spatialDistribution has a potential source of discontinuity which we don't have for delay, namely the change of transport direction. However, I would hope that it is the model's choice of event generation for positiveVelocity that will determine whether a change of direction should result in a discontinuity in the internal distribution. Would that make sense?

I don't know the consequence of this. I think I get the point that non-events for positiveVelocity imply that the spatialDistribution doesn't generate events and thus isn't discrete-time, even if you send in non-Reals; but there might be additional subtle issues.

[henrikt-ma]

I notice that it was now generalized to non-Reals. I can to some extent see that it makes sense, but I'm not sure if I have seen any use-case for it - and I don't know how much extra issues it brings. It may be easier to skip that part.

Yes, I found it best to put everything on the table. Based on my experience with implementing delay, it shouldn't be too difficult to support non-Real types once the discrete-time variability is supported properly.

[henrikt-ma]

I don't know the consequence of this. I think I get the point that non-events for positiveVelocity imply that the spatialDistribution doesn't generate events and thus isn't discrete-time, even if you send in non-Reals; but there might be additional subtle issues.

At least I have tried to separate the concerns of event generation within spatialDistribution itself from event-generation used externally for the determination of positiveVelocity. The key was to include the variability of positiveVelocity (not anything about event-generation per se) in the conditions for the spatialDistribution expression being discrete-time.

[HansOlsson]

@MarkusOlssonModelon and @gkurzbach state that implemented in Modelon Impact and SimulationX.
(Events if significant discontinuous change in input.)

[gkurzbach]

ok

[HansOlsson]

Suggested change

	The expressions \lstinline!in0!, \lstinline!in1!, \lstinline!out0!, and \lstinline!out1! shall all be subtypes of a common type $T$, where $T$ is either \lstinline!Real!, \lstinline!Integer!, \lstinline!Boolean!, or an enumeration type.
	Further, \lstinline!x! shall be a subtype of \lstinline!Real!, \lstinline!positiveVelocity! is a \lstinline!Boolean!, and \lstinline!initialPoints! and \lstinline!initialValues! are arrays of subtypes of $T$ and \lstinline!Real!, respectively.
	The expressions \lstinline!in0!, \lstinline!in1!, \lstinline!out0!, and \lstinline!out1! shall all be subtypes of\lstinline!Real!.
	Further, \lstinline!x! shall be a subtype of \lstinline!Real!, \lstinline!positiveVelocity! is a \lstinline!Boolean!, and \lstinline!initialPoints! and \lstinline!initialValues! are arrays of subtypes of \lstinline!Real!.

I should have realized this earlier, but non-Real spatialDistribution will cause problems for the initialValues.

Basically we normally interpolate between the initial points, but that doesn't work if the values are non-Reals.

I'm sure that it could be handled in some way, but I'm not confident that we will find all the issues before the release - and since there wasn't that much push for non-Real spatialDistribution I think it can wait.

[HansOlsson]

Suggested change

	Disregarding the event-triggering handling of discontinuities, \lstinline!spatialDistribution! for $T$ being \lstinline!Real! can be described in terms of the pseudo-code given as a block:
	Disregarding the event-triggering handling of discontinuities, \lstinline!spatialDistribution! can be described in terms of the pseudo-code given as a block:

Similarly.

[HansOlsson]

Overall good, but some issue with non-Real initial values.
Since that case seems a bit esoteric I think it is better to delay that and get the other changes.

[HansOlsson]

I also realized that this line suggest that one can write:
(, out1) = noEvent(spatialDistribution(in0, 0, x, true, {0,1}, {0,0}));
to disable event generation for spatialDistribution, similarly as for other operators.

That makes sense, but two points:

• That should preferably be clarified, as noEvent was previously described for "expressions", but multi-returning functions aren't really "expressions".
• If in0 is an integer expression it would seem that we generate a non-discrete-time integer - is that intentional? This might indicate that there might be additional problems for non-Real spatialDistribution.