Add support for time-point specific overrides to petab.parameter_mapping

[dweindl]

petab.parameter_mapping does not support time-point specific parameter overrides. To work with the current mapping system, these measurements should be split into groups by overrides and returning them as separate conditions.

[JanHasenauer]

Wouldn't it be better to avoid the generation of additional conditions and instead duplicate the observables? This would also avoid additional simulations.

[dweindl]

Avoiding additional simulations is a good point. Besides that I don't see any (dis)advantages of the one over the other.

[dweindl]

Wouldn't it be better to avoid the generation of additional conditions and instead duplicate the observables?

Update: This will work for observableParameters and noiseParameters. However, we also want to support dynamic parameter overrides. There resimulation is inevitable. For the output parameter we should avoid it though.

(EDIT: no, this would be separate conditions anyways. so no problem there)

[elbaraim]

is there any example in the benchmark having this feature at the moment?

[dweindl]

I'd propose to do that as a preprocessing step independently of the parameter mapping functions, creating a new set of tables.

For the replicate-observable case:

Something like flatten_timepoint_specific_output_overrides(petab_problem: petab.Problem) -> None.

This would involve:

• Add test case with minimal example
• check for observables with timepoint-specific observableParameters and noiseParameters
• determine unique combinations of condition, preequilibration, observable
• within each group, look unique combination of observableParameters and noiseParameters (see also petab.lint.measurement_table_has_timepoint_specific_mappings)
• if > 1: create new observable {oldname}_{n} and noise model assignment rule in the SBML model for each of those combinations
• remove or keep (?) original rules
• replace observableId in the measurement table

[dweindl]

is there any example in the benchmark having this feature at the moment?

I think so, but don't remember which one. should be simple to construct though.
For the implementation, anyways a test case with a minimal(!) example should be added

[JanHasenauer]

There should be several examples, e.g. the Isensee model. The control condition is use in many experiments with identical time points, but the observable parameters differ.

[elbaraim]

Just need a short clarification @dweindl how to handle the case (if considered):

• different noise parameters, but
• same scaling

should it be also considered as a new replicate (e.g. obs1_1 and obs1_2)?

[dweindl]

Yes, it should.

[elbaraim]

I came up with a solution, it works for the simple test case, but I am afraid it will not support all possible models/scenarios... Could you still @dweindl have a look? Maybe you can give me some guidance 😄

[dweindl]

If it works for the test case it should be fine. I thought I considered all relevant scenarios.