Open LarsFroehling opened 4 years ago
e.g in the following model: https://github.com/Benchmarking-Initiative/Benchmark-Models-PEtab/issues/5
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]
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?
"plain-text formula" was meant like the observableFormula
in the observables table.
But I agree, using only SBML would be enough.
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?
Yes, this is also what I had in mind.
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?
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.
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
for all conditions and all time points (defined by lower and upper bound)
for all conditions and a set of time points (defined e.g. as a list)
for some conditions (which would need to be specified probably similar to the experimental data table) and all time points
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)
It would be good to be able to include constraints on functions of parameters. e.g
par1 = par2 + par3
where onlypar2
andpar3
are to be estimated but bounds onpar1
are available as well.