James Lawson wrote: > Dear All, > > This email is aimed at anyone who has comments, but we particularly want > to draw Matt's attention. > > In the CellML meeting yesterday I brought up the issue of replacement of > reaction components with straight math. At present PCEnv isn't handling > reaction components well - models which use reaction components aren't > integrating, for one. There are also issues with math elements not being > picked up if they are under role elements. Andrew has written a script > to pull these math elements up a level so that they're a direct child of > the component, not the role element. The script also defines delta > variables as rate * stoichiometry. Running this script on the models > which contain reaction components has cleared up most of the errors with > undefined delta variables, so now many of the models with reaction > components can now be loaded in PCEnv. The problem is that *none of > them* will integrate properly. I am making the assumption that this > effect is due to the reaction component, not the models, since it is so > widespread among many very different models. > Have you actually looked at what exactly is happening? Is this an overflow where quantities are getting so big they go to infinity because you have a loop which doesn't have any self-regulation?
I presume that the model that is being generated from the reactions by my script would be exactly identical to what you would enter if you recreated the model by hand (assuming that the entered rate laws are an accurate representation of the paper). If the rates were specified using one of the common formulae for enzyme rates, you would get product inhibition and these overflows wouldn't happen, but I think that perhaps the entered rate laws are too simple. Obviously, getting rid of the reactions is the overall goal, but I don't see any reason why you would be better to re-create the models from scratch, rather than starting from the original model with reactions, running it through my script to generate equations for this, and then fixing any problems such as rate laws which don't represent what the authors of the paper actually used and/or result in species getting exponential increases to such high concentrations they overflow the floating point representation. > I'm going to start rebuilding models without reaction components. > However, one of the primary issues around this is that the information > represented by the attributes defined in the reaction components is, > while not essential for computation of the model, definitely something > that we want to keep. For example, what species are reactants, products, > catalysts, activators, inhibitors (and what kind of inhibitor,) etc. > Ideally, these attributes would be recorded as metadata. We don't as yet > have this facility, however. > My script could generate metadata as well if required. However, as Poul suggested at the CellML meeting, feedback from Matt on exactly what metadata we should generate it and where that metadata should be stored (I think it preferably should be in the model, but Matt might have a different opinion). > So the questions are: > 1.) what to do with this data meanwhile > 2.) how to redesign reaction descriptions using a combination of math > and metadata. > > One of the reasons we're seeking your input Matt, is that ontologies > such as BioPAX could be really useful in providing a framework for how > we assign metadata to reactions, in a biological sense. Also, Sarala > mentioned in the meeting yesterday that she was using BioPAX to describe > reactions in her work. > > Regarding the first question, some of the ideas that were suggested were: > a.) use commenting to describe the attributes of each reaction > b.) keep the files (well, we already do anyway,) that describe the > models in terms of reaction components and refer back to them later when > we have the facilities to enter metadata on reactions to the models > which have been rebuilt without the reaction components. > > So if anyone has any comments on this, they'd be much appreciated. > > James > > _______________________________________________ > cellml-discussion mailing list > [email protected] > http://www.cellml.org/mailman/listinfo/cellml-discussion > Best regards, Andrew Miller _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
