Isn't x(fixed = true) a violation of this rule from https://specification.modelica.org/master/synchronous-language-elements.html#initialization-of-clocked-partitions?

Attribute fixed cannot be applied to variables in clocked partitions. The attribute fixed is true for variables to which previous is applied, otherwise false.

Ouch. So, how are initial conditions specified for such clocked partitions?

That's a valid question, but more work on the specification side is needed to answer it. Until then, I would just find it best to avoid breaking one of the few simple rules we have.

By the way, System Modeler also warns about underdetermined initialization where PI.x was automatically selected to be initialized from start, so it is not only in Dymola that this example will not run as cleanly as we'd ideally want it to.

I should also mention that System Modeler is lacking a check for

Attribute fixed cannot be applied to variables in clocked partitions.

so I can't tell how close the rest of the MSL is to complying with the rule.

After some more thinking I think the specification got a bit messed up when trying to clarify.

Basically I don't see how we can get this to work as desired for MSL with the current specification:

• All examples in MSL should have fully defined initial conditions.
• Clocked components should have neither initial equations, nor fixed; https://specification.modelica.org/master/synchronous-language-elements.html#initialization-of-clocked-partitions

However, going back to 3.5 the rule for initial equations and fixed only applied to "clocked discrete-time partitions", which are now called "discrete-time sub-partitions". That should be restored, and we can see that example in https://specification.modelica.org/master/synchronous-language-elements.html#solver-methods has fixed=true.

Obviously we will later clarify initialization for "discrete-time sub-partitions".

The "having fully defined initial conditions" is a strong requirement for tool-independent behaviour. If this is not possible with the current specification, I agree at relaxing/changing it. @HansOlsson would the proposed changes to the code OK with your proposed change to the MLS?

With the proposed change to the specification there is no need to update this model at all, as the restrictions apply equally to initial equations and fixed=true.