Menu
▾
▴
Re: [sbml-dynamic] Draft Specification for Dynamic Structures Package
|
From: Chris J. M. <my...@ec...> - 2014-10-07 14:24:22
|
On Oct 7, 2014, at 8:13 AM, Kepler, Thomas B. <tbk...@bu...> wrote: > Hi, Chris and colleagues. > > In this discussion, there seems to be an implicit dichotomy “continuous/stochastic”, but the appropriate dichotomies, I think, are “continuous/discrete” and “deterministic/stochastic”. One can have all four 2x2 combinations. And these can be applied at the level of individual processes: Cellular differentiation might be modeled as a discrete event (either stochastic or deterministic) while cell motion is modeled as continuous (either stochastic or deterministic). > You are correct. Our preferred modeling formalism is discrete/stochastic. > You have mentioned the CBO several times and pointed to the paper, saying, “The mission is to bring multi-cellular modeling folks to SBML.” Is that really the mission? Did the SBML have a hand in developing the CBO? > No, but they are open to working with us. Various people from SBML community have participated in multi-cellular modeling meetings where CBO was discussed, as well as, what it would take for this community to be able to use SBML. These discussions indeed were what was driving me in the development of the dyn package. Indeed, I've given several talks at Harmony/Combine which include ideas from these discussions for the development of the dyn pacakge. Arguably, we should have just started a new package, but at the time, it was decided that the goals of dyn could be extended to meet the needs of the community. However, a new package name would have likely made this change in goals more clear. > There is a substantial problem that the dyn package at one time seemed designed to address: the change of the topology of the state space, which, by definition must be discontinuous. Thus, having “Event” as the primary mechanism seems appropriate. But for cell motion for example, modeled continuously, there is no corresponding event, whether the motion is stochastic or deterministic. > I disagree. An event can be used for motion when movement is modeled as a discrete change in state where the state change is the position of a cell in space. We have already developed a simulator that works in this way. > I was not able to make the COMBINE meeting to participate in the discussion regarding the spatial package, but if “spatial” cannot accommodate cell motion, then it seems misnamed. > I disagree. The goal of spatial modeling was not to model multi-cellular systems. The goal of spatial modeling was to model the cell as not simply a "well-stirred" bag of stuff. The spatial package is for representing the cell spatially, so you can model the diffusion of species within the cell using PDEs. It does this quite well. I really think the best way forward is to rebrand what we are doing as "multi-cellular" modeling. While doing multi-cellular modeling can be done in a limited fashion in core, it does not really handle well what people in this field are doing. Chris > Best wishes, > Tom > > Thomas B. Kepler, Professor > Department of Microbiology > Department of Mathematics & Statistics > Boston University School of Medicine > 72 E. Concord St., L504D > Boston MA 02118 > Voice: +1 617 638 4124 > > From: Chris J. Myers [mailto:my...@ec...] > Sent: Tuesday, October 07, 2014 9:42 AM > To: The SBML L3 Dynamic Structures package discussion list > Subject: Re: [sbml-dynamic] Draft Specification for Dynamic Structures Package > > > I agree velocity is probably a bad concept here, but the time frame in which the movement occur and the direction should be defined (which combined are something like a velocity). You do not have a quantity in your model framework which says 'velocity', but I am sure you have an internal model reference time (at least the time of the ode model within the cell which triggers the events). Even if you assume your movement to occur 'instantaneous', this is important information about the model. In addition you have a delta x, the distance a cell should move if the movement is triggered. Delta x is defined by some multiple of your grid size (in the simplest case just to the next grid point). > So as far as I understand your implementation your 'velocity' is therefore v=gridsize/delay, with gridsize=distance between neighboring grid points. > > We don't typically build ODE models. Our models are usually stochastic, so time of these events is usually given as a random distribution. > > > This crucial information of the process should be encoded: > - time to perform process: instantaneous or some delta t (delay) > - direction: random selection of one free adjacent position (in case of grid this translates to one of the neighbouring free locations, in case of continuous this translates to the selection of a random vector pointing to a free adjacent position) > This is definitely not part of the first version, but this information should be encoded for the events. > > > Agreed. We do currently encode this information in our events. We actually have five types of movement events. One for each direction in a 2-D grid and one for a random direction choice. We can encode this in the current specification by having five events where each update the position of a compartment accordingly. > > Chris > > > The best, > Matthias > > > We are hoping that our open way of describing things will enable our tools and others to describe things in the way that is most natural to them, and after gaining some experience, we do hope things will eventually coalesce around some agreed upon forms. > > I suggest that you perhaps have a look at this paper on the Cell Behavior Ontology: > > http://www.ncbi.nlm.nih.gov/pubmed/24755304 > > This is the closest thing to a standard representation for these types of models. It is even more loose in the semantics than we are. Namely, terms can be backed up by code rather than any mathematics at all. > > [2] > The semantic encoding should be clear enough so one could translate them in a working simulation. As far as I understood the approach it only encodes the single cell events. > But somewhere the additional information for the geometrical layout (1D, 2D, 3D) and the initial conditions has to be encoded (i.e. where in the geometry are cells located), so that a simulation can be performed. > The Compartment extensions should enable the layout to be specified, we believe. At least, this is the goal. > Regarding to the simulation? Are there any tools which would support running the basic examples (5.1, 5.2)? > Not yet though we hope to have some support soon. Our tool does some multi-cellular modeling with grids, but it currently uses custom annotations. We hope to start using the package constructs soon. Harold's group is also designing a tool which plans to use this package. This is the typical package development path in SBML. Namely, prototypes are done with custom annotations, this leads to a package specification and discussion, this leads to library support, and finally tools start to experiment with it. Only after at least two implementations exist, is a package considered released. Therefore, you may consider everything in the document open to discussion and change. We would be happy to try to tighten the semantics, but initial attempts to do this have been difficult. > I do not want to sound to negative. I think it is exactly the right approach to start with the semantic encoding, but the long term goal should be running simulations from the encoded information. > We agree. Our goal is that simulations in different tools using the same model should be arguably consistent, if not precisely the same. We hope that we are on the path, and we value all feedback that we can get on this. > > By the way, if you are implementing such a tool, we would also value to hear of your experiences trying to encode your models using these ideas. > > Thanks for your feedback. > > Chris > > > Greetings Matthias > > On Wed, Oct 1, 2014 at 7:30 PM, Chris J. Myers <my...@ec...> wrote: > Just to add a bit to Harold's response. The challenge we face with this package is that multicellular modeling tools are so varied that it was deemed very difficult to come to a single mathematical formulation that would work for all tools. We do not want to prescribe one formalism as this would likely preclude exchange between these tools. For example, cell movement in a tool that is lattice-based means moving on lattice point over while in non-lattice it would not move in such a discrete fashion. > > We hope that gradually we may be able to add tighter mathematical meaning through the CBO definitions, but we think for now it is best to create something very general to experiment with until we see how it will work for people. > > Cheers, > > Chris > > > On Oct 1, 2014, at 9:10 AM, Harold Gomez <Har...@gm...> wrote: > > > Hi Dr. König, > > Thank you for your feedback! -it's really exciting to hear back from the community. I will try to address the concerns you raised in your email regarding the approach used in the package. > > Section 4.2. of the specification points out that while all SBase-inheriting elements can have a CBO term, CBO-annotated Events now have specific simulation semantics. Though preliminary, we do provide a small list in section 4.2.4 spelling out these semantics for dynamic cellular behaviors such as death, division and movement events. The following is an example from this list for Cell Death: > A CBO term for Cell Death as value for a cboTerm attribute indicates that the Event defines, by means of a Trigger subobject, the mathematical conditions under which cell death is to take place. When the applyToAll Event attribute is set to “false”, the presence of this CBO termalso dictates that SBML model components whose id or metaid is referenced by a DynElement in the ListOfDynElements subobject have to be removed from the model. When the value of applyToAll is “true”, all model elements are removed. > In essence, what we are proposing with this package is to define what happens to the model (semantically) as a result of the cellular behaviors that are mentioned in your email, not mathematically. The Dynamic Structures package does not explicitly encode mathematically what happens for each behavior as this has proven to be problematic since different modeling tools may use widely different mathematical and spatial frameworks (e.g., cellular potts vs 3D center-based) to represent modeling elements in space, and how cellular events like movement/division affect the model. To address this, our solution (reflected in the current spec) was to provide a set of constructs so that modelers can specify: 1) which elements are involved, 2) where they are in space, and 3) offer simulation semantics for how CBO-annotated Events should be simulated. > > Best, > > On Wed, Oct 1, 2014 at 8:56 AM, Matthias König <kon...@go...> wrote: > Hi Harold, > here some short feedback, as far as I understood the approach. I am no expert, so please correct me if I am completely wrong about things. > > My main problem with the approach is that it is not clearly defined (mathematically) what happens with the model components after an event of a certain type. There has to be a clear mathematical definition for what a CBO term means for the future of the model. > > For instance 'cell death': > What does it mean mathematically? > Are all the substance amounts vanished from the model balance after cell death? Or are the substance amounts of the cell afterwards in the compartment adjacent to the cell that died (exterior)? What does this mean for mass balance for the complete model? > > For instance 'cell division': > What are the volumes of the new cell? Half of volume of the dividing cell or the equal to the standard volume of the cell? How are substances distributed between the two cells? What about unequal division? > What happens to the sizes of internal compartments? What if a cell model has surface area and volume? How is it divided (based on surface or volume) and what happens to the other quantity (again mass balance)? > > A good example for this uncertainty in what is happening is the example > "5.1 Example of using dynamic events" > I understand that it is a cell which can divide or die depending on certain conditions fulfilled in the model (Events). But if I had to implement the model in software I could imagine a multitude of different ways with widely different results for simulation. In my opinion the dyn package must clearly encode the rules which are applied given an event or at least define the mathematical rules associated with a CBO term. > > Matthias > > > On Tue, Sep 30, 2014 at 4:40 PM, Harold Gomez <Har...@gm...> wrote: > Hi everyone, > > I would like to share with you the latest draft specification for the Dynamic Structures package, which was expanded to accommodate some of the feedback received during COMBINE. As usual, we welcome further feedback. > > Best, > -- > Harold Gómez > Bioinformatics PhD. Candidate, Boston University > Graduate School of Arts & Sciences > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > sbml-dynamic mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-dynamic > > > > > -- > --------------------------------------------------- > Matthias König > Computational Systems Biochemistry > Institute of Biochemistry > Charité - Universitätsmedizin Berlin > http://www.charite.de/sysbio/people/koenig/ > Tel: + 49 30 450 528 197 > Tel: + 49 176 81168480 > --------------------------------------------------- > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > sbml-dynamic mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-dynamic > > > > > -- > Harold Gómez > Bioinformatics PhD. Candidate, Boston University > Graduate School of Arts & Sciences > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________ > sbml-dynamic mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-dynamic > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > sbml-dynamic mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-dynamic > > > > > -- > --------------------------------------------------- > Matthias König > Computational Systems Biochemistry > Institute of Biochemistry > Charité - Universitätsmedizin Berlin > http://www.charite.de/sysbio/people/koenig/ > Tel: + 49 30 450 528 197 > Tel: + 49 176 81168480 > --------------------------------------------------- > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________ > sbml-dynamic mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-dynamic > > > ------------------------------------------------------------------------------ > Slashdot TV. Videos for Nerds. Stuff that Matters. > http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk > _______________________________________________ > sbml-dynamic mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-dynamic > > > > > -- > --------------------------------------------------- > Matthias König > Computational Systems Biochemistry > Institute of Biochemistry > Charité - Universitätsmedizin Berlin > http://www.charite.de/sysbio/people/koenig/ > Tel: + 49 30 450 528 197 > Tel: + 49 176 81168480 > --------------------------------------------------- > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________ > sbml-dynamic mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-dynamic > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk_______________________________________________ > sbml-dynamic mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-dynamic |
