Making initial values more ergonomic

[fivegrant]

We should consider putting a new property initial : bool for each parameter in the model.

Currently, it's not impossible to figure out. You can compare petri["model"]["states"][some index]["initial"]["expression"] to petri["model"]["parameters"][some other index]["id"]. Knowing if a parameter is an initial value is essential to understanding the model and it is somewhat obfuscated with the current design.

cc @brandomr @bgyori @mehalter

[bgyori]

I understand what you mean; the issue with doing that is that it restricts expressions that can be used as initial conditions. In some models, initial conditions don't have a one-to-one relationship with a specific parameter. They are sometimes derived from multiple parameters, possibly including ones that are involved in the model's dynamics. So the choices are either to do what you suggest but change "expression" to something less general or keep the current definition in which case one cannot cleanly classify parameters as initial conditions.

[brandomr]

@bgyori will there ever be cases for petrinets where we couldn't reliably infer what are initial conditions based on the state names?

If not, then we can leave as is.

If there are indeed such cases we should discuss a bit more since Uncharted intends to show initial conditions somewhat differently than parameters in the HMI.

[fivegrant]

WFM as long as the parameter names are identical to the expression names

[bgyori]

I think there might be a bit of confusion here, let me try to clarify. The expressions for initial conditions are defined within each state so there is no reference to a state ID/name necessary. The expressions can contain a formula that refers to one or more model parameters. Sometimes, these model parameters are trivially representing an initial condition specific to a given state. However, the parameter's name is still arbitrary, it can be anything like S0, S_init or initial_susceptible. This is because the state's initial expression formula refers to the parameter, not the other way around.

What I mentioned above, however, is that sometimes the expressions are not trivially referring to a single state-specific initial condition. For example, you might have a model with a parameter N representing the total population, and the initial expression for susceptible population can be 0.8*N or even x*N where x is also a model parameter. In some cases, initial expressions make use of parameters that govern model dynamics. For instance, models sometimes define initial conditions based on steady states, and formulas for steady states typically depend on dynamical model parameters. This means that generally one cannot always cleanly designate a model parameter as an initial condition.

If we decide to throw away the generality above and restrict the representation to a one-to-one mapping between a state and a dedicated initial condition parameter, then we can do what @fivegrant suggests and mark these parameters as initial conditions.

[brandomr]

Thanks for the clarification. Understood--we have updated the HMI designs accordingly so can close this.