Note this is already how it works in Dymola.

I'm not aware of any tool that implemented the semantic that lead to a loop for any variable with a when-clause also assigned in an initial algorithm.

As I wrote in #3472, this is also how I understand it works in OMC already.

@phannebohm, @kabdelhak, can you please confirm?

Check what happens if a normal algorithm ends up in an initial system of equations (seems only problematic if there is a when-clause for the variable as well).

At first I thought that the proposed changes of this PR only seemed relevant for obscure cases. However, investigating more the conclusion is that it would be a breaking change with unknown consequences.

The issue would occur if we have a discrete variable assigned in a when-equation (see later for when-algorithm) and also assigned in a normal algorithm.

That would mean something like:

model M1
  ... x, y;
equation
  when sample(1, 1) then
     x=integer(time);
  end when;
algorithm
   // Should x start at pre(x) or start initially?
   if (...) then
    x:=y;
   end if;
end M1;

The idea is here to solve the algorithm for y. However, if the type of the variables is Integer the problem is that such integer equations aren't guaranteed to work (only very simple integer equations are supported), and for Real the algorithm would attempt to assign a continuous-time value to a discrete variable which is not legal.

However, for an algorithm we could have a case such as:

model M2
  Real x;
  Real z(start=-100, fixed=true);
algorithm
  // initialize x to pre(x) or start(x)
  // initialize z to pre(z) or start(z)
  when ... then
     z:=foo(time, pre(z));
     x:=foo(time, pre(x));
  end when;
initial algorithm
   pre(x)=-100;
end M2;

The description states for z the fixed=true implies that we have an initialization equation pre(z)=-100;
That ensures that if the when-statement is not active z will initialize to -100 (since nothing changes it), and if the when-statement is active it will intialize to f(time, -100).

For x we currently get the same result as for z. However, if we switched initialization of variables in algorithms during initialization in general, then x would not behave the same, but instead always initialize to its "start-value (which is zero as default)" - and it would be impossible to easily replace a start-value for x by an initial equation/initial algorithm giving the same result.

At first I thought that the proposed changes of this PR only seemed relevant for obscure cases. However, investigating more the conclusion is that it would be a breaking change with unknown consequences.

Sure, that's why we need a concrete proposal that can be evaluated against existing libraries on our radars.

I don't know what kind of review that is expected of me at this time. My impression was that you @HansOlsson would test a couple of variants to see how they work, and then make a concrete suggestion for new algorithm initialization rules based on that. Once there is such a proposal that looks sensible, the rest of us can test implement it to see how it works with the libraries in our test suites.

The concrete proposal is that only "initial algorithm" is changed, so when the proposed text says "initial algorithm" it only means "initial algorithm". The alternative would have been any algorithm executed during initialization, and as indicated that would cause problems, while only providing a benefit for models that still wouldn't work - so no need to test-implement that.

The change for "initial algorithm" doesn't impact algorithms with "when", and it still keeps "initial equation" and start-attributes in sync - it also seems to be implemented in OpenModelica and Dymola.

As far as I understand (but I guess we'll need some testing) I agree with @HansOlsson's current proposal in this PR, i.e., replacing

A discrete-time variable \lstinline!v! is initialized with \lstinline!pre(v)!.

with

A discrete-time variable \lstinline!v! in a non-initial algorithm is initialized with \lstinline!pre(v)!.

which leaves open the option of using an explicit initial algorithm to initialize it. However, with this modification it is not clear to me how discrete-time variables would be initialized in initial algorithms, i.e., what value they get before the algorithm starts. I guess it should be the start attribute, and maybe this is already clear because of some other rule regarding algorithms. Maybe we should say it explicitly anyway?

See line 41.