allow formulation of additional constraints

[LarsFroehling]

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]

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

[LarsFroehling]

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

constraintId

• to identify and reference the constraint

[constraintName]

• for plotting etc

constraintFormula

• parameter that is an AssignmentRule target in the SBML model or
• plain-text formula consisting of symbols defined in SBML model

lowerBound -given lower bound

upperBound -given upper bound

[timeLowerBound]

• can be given if the constraint is only valid in a certain timeframe

[timeUpperBound]

• can be given if the constraint is only valid in a certain timeframe

[JanHasenauer]

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]

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

[LeonardSchmiester]

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]

Yes, this is also what I had in mind.

[dweindl]

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]

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]

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)