Clarify reinitialization for parameters in the condition table

[dweindl]

The current specifications describe re-initialization for species listed in the condition table. However, as noticed by @fbergmann, it is not clear how parameters that are targets of (implicitly or explicitly) time-dependent rules should be treated.
As those parameters are not excluded from being overwritten in the condition table, I'd say the most natural thing would be also re-iniitializing the corresponding states. Other thoughts?

[FFroehlich]

The current specifications describe re-initialization for species listed in the condition table. However, as noticed by @fbergmann, it is not clear how parameters that are targets of (implicitly or explicitly) time-dependent rules should be treated.

Speaking of, is it clear what happens to parameters that are targets of time-independent rules?

As those parameters are not excluded from being overwritten in the condition table, I'd say the most natural thing would be also re-iniitializing the corresponding states. Other thoughts?

Sounds reasonable.

[dweindl]

Speaking of, is it clear what happens to parameters that are targets of time-independent rules?

Hm. Maybe in my first question I missed the full picture. So I guess the question would be whether overriding those parameters overrides the respective rules completely, i.e. changing them to the provided constant, or whether they should just be reinitialized to the respective value and then be updated as defined by the rule.

[FFroehlich]

Speaking of, is it clear what happens to parameters that are targets of time-independent rules?

Hm. Maybe in my first question I missed the full picture. So I guess the question would be whether overriding those parameters overrides the respective rules completely, i.e., changing them to the provided constant, or whether they should just be reinitialized to the respective value and then be updated as defined by the rule.

True. I would argue that for rate rules, initial values should be reinitialized, but that for assignment rules the assigned value is replaced statically.

[fbergmann]

True. I would argue that for rate rules, initial values should be reinitialized, but that for assignment rules the assigned value is replaced statically.

You mean for assignment rules, the condition just replaces the assignment rule altogether with the value from the condition table?

[FFroehlich]

True. I would argue that for rate rules, initial values should be reinitialized, but that for assignment rules the assigned value is replaced statically.

You mean for assignment rules, the condition just replaces the assignment rule altogether with the value from the condition table?

Yes, I don't see how re-initialization would work for a time-dependent assignment rule, as the assignment rule would simply immediately overwrite the reinitialized value?

One could argue that for species dependent assignment rules, the species should be reinitialized such that the assignment matches the value specified in the condition to allow implicit reinitialization, but I don't see how this would be helpful or who would want to implement it.

[fbergmann]

One could argue that for species dependent assignment rules, the species should be reinitialized such that the assignment matches the value specified in the condition to allow implicit reinitialization, but I don't see how this would be helpful or who would want to implement it.

Agreed, the only consistent interpretation for assignment rules (that according to spec have to hold at all times), is a replacement. I just wanted to make sure. As for where this would be applicable i'm not sure.

That goes with this whole issue. I just noted that it seemed strange to single out species, but neglect compartments / parameters, as the same thing would apply to them (according to the SBML spec). Whether it would ever make sense for people to do that, i'm not sure. As to what it means, it just means that parameters with those strange things are to be counted as state variables.

[dweindl]

This has been somewhat addressed in proposal #538