PySBPetab sets incorrect value for edata.reinitializeFixedParameterInitialStates

[FFroehlich]

prevents use of reinitialization with multithreading pysb models? 💩

[dweindl]

@FFroehlich : Can you provide some more details?

[FFroehlich]

petab problem defines preequilibration conditions with different parameters, but edata.reinitializeFixedParameterInitialStates is not set to true.

[dweindl]

You are right. However, I am not sure if this is currently well-defined in PEtab. If there are states/species in the condition table, then it's clear what to do. But for parameters, not really. Needs clarification there in my opinion.

[FFroehlich]

You are right. However, I am not sure if this is currently well-defined in PEtab. If there are states/species in the condition table, then it's clear what to do. But for parameters, not really. Needs clarification there in my opinion.

Pretty much makes PySB-Petab de facto unusable for me.

[dweindl]

Pretty much makes PySB-Petab de facto unusable for me.

Maybe you want to make a proposal on how that should be handled...

[FFroehlich]

Pretty much makes PySB-Petab de facto unusable for me.

Maybe you want to make a proposal on how that should be handled...

Extend parameter table by an optional column that indicates whether changing this parameter through a condition should trigger reinitialization of all states that have initial states depending on this parameter.

[dweindl]

Extend parameter table by an optional column that indicates whether changing this parameter through a condition should trigger reinitialization of all states that have initial states depending on this parameter.

Sounds fine for the moment, but I'm wondering how compatible that would be with the (hopefully soon implemented) case of having multiple simulation conditions in a row, beyond just preequilibration/presimulation. I guess one would want to have that setting for each change of parameters then.

Specifying species/patterns for reinitialization as done for PEtab/SBML would not work for you? (currently not possible here, but if it were...)

[FFroehlich]

Extend parameter table by an optional column that indicates whether changing this parameter through a condition should trigger reinitialization of all states that have initial states depending on this parameter.

Sounds fine for the moment, but I'm wondering how compatible that would be with the (hopefully soon implemented) case of having multiple simulation conditions in a row, beyond just preequilibration/presimulation. I guess one would want to have that setting for each change of parameters then.

Specifying species/patterns for reinitialization as done for PEtab/SBML would not work for you? (currently not possible here, but if it were...)

Hmm patterns would probably work, but thats conceptually a bit tricky to do since a pure reinitialization approach would affect network generation. For example, for a drug, I would not add and initial to the model, so the reinitialization would have to add an initial to the model. Accordingly, things like model generation may not behave as expected, as the generated model will probably depend on the specified condition. I can easily see that causing trouble.

[dweindl]

Hm, wouldn't you add an Initial(..., 0.0) for anything that will have a non-zero amount due to reinitialization anyways?

For the proposed extra "triggersReinitialization" column, how would you handle that for multiple parameter changes (e.g., simulation phase 1, simulation phase 2, simulation phase 3)? With one column there, you could not reinitialize the state only once (e.g., you could not only reinitialize at beginning of phase 2, while not reinitializing for phase 3). Adding multiple columns would require that you always have the same type of experimental setup.

[FFroehlich]

Hm, wouldn't you add an Initial(..., 0.0) for anything that will have a non-zero amount due to reinitialization anyways?

I would argue you wouldn't, unless you specifically build the model for the purposes of petab. Initial(..., 0.0) will mostly just create a larger network which contains species that are always zero. I would argue that most models contain a parametrized initial that can be changed by changing parameter values.

I think the general dogma should be that experimental conditions shouldn't be encoded in the model and I would argue that allowing condition parameters to change the model would violate that assumption. So it would have to be enforced that patterns for reinitialization may only refer to species that are already contained in the model.

For the proposed extra "triggersReinitialization" column, how would you handle that for multiple parameter changes (e.g., simulation phase 1, simulation phase 2, simulation phase 3)? With one column there, you could not reinitialize the state only once (e.g., you could not only reinitialize at beginning of phase 2, while not reinitializing for phase 3). Adding multiple columns would require that you always have the same type of experimental setup.

I agree, I don't think that can be implemented.

[FFroehlich]

It should be noted though that without unit transformation baked into petab, setting initial values by explicitely by specifying pattern abundances is not very convenient. My model has everything in uM, but ligand concentrations are specified in ng/ml, which have to be converted. With parameterized initials, I can use expressions to do the transformation and specify the condition in a familiar units. Without this transformation, numerical values get pretty unwieldy.