Comments (6)
Thanks for the feedback already! Especially the "duration" correction. For now, I made the "duration" -> "isRate" change in Tables 3 and 4, and added Feedback item 1.2.
1.2. Are you in favour of being able to specify modifications of the species' ODE, rather than the species directly? e.g. Tables 3 and 4 have "isRate". e.g. given a "relative" change: if "isRate" is "1", then the "value" gets added to the species ODE RHS. If "isRate" is "0", then the "value" gets added to the species itself.
Yes, it has use cases, e.g. the infusion rate in the examples above could be modeled with a species directly, instead of indirectly via the "infusion_rate" component.
I think there are a few interpretations of this (e.g., is the rate the value itself, or the value divided by the timecourse period duration? do we accumulate changes over timecourse periods, or reset them after each timecourse period?). We could discuss them after deciding whether to have this in the spec.
from petab.
- Are you in favor of timecourse specification -- i.e., instantaneous changes in parameter or species values, at specified timepoints?
Yes, it would help with a few modeling projects I am involved in.
1.1. Are you in favour of specifying the duration of changes explicitly? e.g. Tables 3 and 4
No, it is already covered by being able to specify the start time of the next condition.
- Are you in favor of specifying relative changes in components?
Yes.
2.1. Are you in favor of arbitrary expressions in the conditions table? e.g. Table 6
Yes.
- Which of the changes would you be OK with including in core PEtab, and which would you prefer in an official extension?
I would include all changes in core PEtab. Developers can simply choose to not support the new features, e.g. relative changes or timecourses that are more complicated that preequilibration+simulation conditions, if desired.
from petab.
@PEtab-dev/petab-editors
from petab.
Thanks for starting this discussion here, @dilpath. Thinking again of table 4, I think duration
should not be interpreted as stop time or similar. Perhaps it should be replaced with isRate
instead. 0
would indicate it is instantaneous (i.e. a Bolus dose) and 1
that it is a rate (i.e. an infusion). Why not simply add a parameter that describes the rate to the model instead of using an isRate
column? Because I think the dosing/perturbation/condition model should be independent of the biological model in a similar way the noise and observation models are independent of the biological model. This facilitates modularity/reusability. Is there any chance you could edit table 4 and comment 1.1 accordingly?
A question that remains is what to do with preequilibration conditions. Imo these could be like any other conditions, but with time set to -Inf
(no preequilibration column would be needed in the measurement table anymore (I was always wondering why it was possible to chain 2 conditions together, but not multiple -> if all (atomic) disturbances are represented in sth like table 4, and bundled together with conditionId
s like in the measurement table, than this question becomes obsolete anyway)).
Additionally, I would like to argue that whatever format is used, it should adhere to the tidy data principles, unless there is a good reason not to.
Let me also respond to your questions:
- Are you in favor of timecourse specification -- i.e., instantaneous changes in parameter or species values, at specified timepoints?
Yes, with isRate 0. But with isRate
1 it should be non-instantaneous.
1.1. Are you in favour of specifying the duration of changes explicitly? e.g. Tables 3 and 4.
No, I am no longer in favour of that.
1.2 Are you in favour of being able to specify modifications of the species' ODE, rather than the species directly?
I think both should be possible. Modifications to species (bolus doses) and ODEs (infusion doses).
- Are you in favor of specifying relative changes in components?
Yes, there are many cases where you know the amount of a substance in a pill or the rate at which an infusion adds a substance to the body, but you don't know the current amount in the body of the patient when they swallow that pill.
2.1 Are you in favor of arbitrary expressions in the conditions table? e.g. Table 6.
No, I think only two things should be allowed: Floats and Strings (i.e. parameterId
s). These parameterId
s should be set in the parameter table with estimate equals 0 or 1. If arbitrary expressions were allowed, then you would lose the ability to set estimate to 1.
3 Which of the changes would you be OK with including in core PEtab, and which would you prefer in an official extension?
No strong preferences here.
from petab.
Thanks for pushing that again.
- Are you in favor of timecourse specification -- i.e., instantaneous changes in parameter or species values, at specified timepoints?
Absolutely.
1.1. Are you in favour of specifying the duration of changes explicitly? e.g. Tables 3 and 4
No. (It sounds like this point became obsolete anyways.)
- Are you in favor of specifying relative changes in components?
Yes, both absolute and relative would ideally be possible.
2.1. Are you in favor of arbitrary expressions in the conditions table? e.g. Table 6
No strong opinion (yet).
- Which of the changes would you be OK with including in core PEtab, and which would you prefer in an official extension?
I'd like to see it as part of core PEtab, replacing the current preequilibrationConditionId
+simulationConditionId
(while keeping that functionality, of course).
from petab.
See also #581
from petab.
Related Issues (20)
- Clarification of condition table what happens if NaN is provided as a value
- Allow using observables in noiseFormula HOT 2
- Extensions: required/optional HOT 2
- Bounds documentation needs clairification HOT 2
- Specification of model time in observables file unclear HOT 2
- No Noise HOT 13
- Clarification/specification of order of condition changes required HOT 5
- Fix sphinx doc
- Add tool using PEtab
- PEtab extension for NLME HOT 15
- Update PETab to be model format agnostic HOT 4
- Allow species in `yValues` of the visualization table HOT 2
- Global vs local SBML parameters HOT 1
- No reference to paper in repository HOT 1
- Update editorial board page
- Allow formulas in condition table HOT 1
- Handling of events on parameters that are subject to condition specific values. HOT 4
- Use somewhat normalized "experiments" table instead of conditions/timecourses HOT 16
- Long formats for conditions and experiments (timecourses) HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from petab.