PEtab-dev / PEtab

PEtab - an SBML and TSV based data format for parameter estimation problems in systems biology
https://petab.readthedocs.io
MIT License
60 stars 12 forks source link

allow formulation of additional constraints #375

Open LarsFroehling opened 4 years ago

LarsFroehling commented 4 years ago

It would be good to be able to include constraints on functions of parameters. e.g par1 = par2 + par3 where only par2 and par3 are to be estimated but bounds on par1 are available as well.

LarsFroehling commented 4 years ago

e.g in the following model: https://github.com/Benchmarking-Initiative/Benchmark-Models-PEtab/issues/5

LarsFroehling commented 4 years ago

Just as an initial suggestions: Have a separate table for this with the following columns:

constraintId

[constraintName]

constraintFormula

lowerBound -given lower bound

upperBound -given upper bound

[timeLowerBound]

[timeUpperBound]

JanHasenauer commented 4 years ago

Thanks for the suggestion!

I'm not sure what you mean with "plain-text formula". This would have to follow a certain standard, right?

Might be easier to leave this to SBML and only allow for parameters, states and assignmentRules.

I would only make lower or upper bound mandatory. Indeed, in optimisation the default constraint is something like g(x) < 0. We could also use this here. Then we would not need to specify bounds, but bounds would be contained in the SBML model (or the "plain-text formula").

@yannikschaelte @dweindl @LeonardSchmiester Opinions?

LarsFroehling commented 4 years ago

"plain-text formula" was meant like the observableFormula in the observables table. But I agree, using only SBML would be enough.

LeonardSchmiester commented 4 years ago

I guess it would be more consistent to formulate the constraint in the additional constraint TSV file. Otherwise our idea to use SBML models without adaptations would be gone, right?

JanHasenauer commented 4 years ago

Yes, this is also what I had in mind.

dweindl commented 4 years ago

Sounds reasonable. Would also keep the constraints out of the model, especially if we plan to consider other model formats than SBML in the future.

To clarify: What may occur in the constraints? Estimated parameter and constants for sure. What about states, observables, measurements? Allowing for simulations there will make things rather complicated. But if so: how to specify the respective condition and timepoint?

LarsFroehling commented 4 years ago

At least in the model I linked above only estimated parameters and constants are used, no states, observables or measurements are needed for this. If this is what you meant.

JanHasenauer commented 4 years ago

I think we should allow for parameters and states (including assignmentRules and rateRules). observables could be done but are in my opinion not necessary.

The question with measurements is a good one. I would probably exclude that as ask users to directly specific such constraints.

Concerning states we have to distinguish the situation that a constraint has hold

  1. for all conditions and all time points (defined by lower and upper bound)

  2. for all conditions and a set of time points (defined e.g. as a list)

  3. for some conditions (which would need to be specified probably similar to the experimental data table) and all time points

  4. for some conditions and a set of time points

Given these requirements it might be a good idea to add the optional condition fields (for preeequilibration and simulation)