Condition table not specified for parameters governed by rate rules

[matthiaskoenig]

Which problem would you like to address? Please describe.
Parameters in SBML can be either constant=True or constant=False. In case of constant=False the parameter can be either governed by an AssignmentRule or a RateRule. In case of a RateRule the parameter becomes a state variable in the ODE (analoque to species and compartments which are constant=False and governed by a RateRule or in case of species by reactions).
For such parameters which are governed by RateRules a typical condition is to set the initial value of the state variable, but this is currently not mentioned in the condition table.
See also AMICI-dev/AMICI#1750 for an example PETab problem.

Describe the solution you would like
I propose to clarify the description of the condition table, i.e.,
I.e. the more correct way for the condition table description in
https://petab.readthedocs.io/en/latest/documentation_data_format.html#condition-table
should be

The condition table specifies constant parameters, or initial values of species, compartments or parameters for specific simulation conditions (generally corresponding to different experimental conditions).

instead of

The condition table specifies parameters, or initial values of species and compartments for specific simulation conditions (generally corresponding to different experimental conditions).

Describe alternatives you have considered
An alternative is to encode the parameter as a species or compartment governed by a RateRule. While this would be supported, the semantics would be incorrect and also the units would create problems.

[matthiaskoenig]

I just saw, this is probably also related to #513

[dweindl]

Hi @matthiaskoenig, thanks for reporting. Fully agreed that there is some clarification required. We were just discussing that topic during yesterday's PEtab editor meeting. We'll follow up shortly.

[FFroehlich]

Yes that's correct. PEtab currently doesn't specify how to handle such situations in sufficient detail. We are working on updating the specification in #538, but it looks like the specific condition you mentioned isn't addressed yet, so thanks for bringing that up!