Dear LucianI'd like to start by keeping a distinction between a CellML <model>, which I'll denote with angle brackets, and a model in the way people use that word (which can be a very slippery and ambiguous term).
As you say, you can partition variables (and mathematics) into components, and you can also place components (wrapped in <model>s) in different files. In CellML, a model and a component are not equivalent concepts - models may also encompass none, one or many unit definitions, information on the hierarchical grouping of components, annotations, and connections between component variables.
The question about creating two separate models in a single <model> is interesting. I enclose a cellml file that does this. Time is not an implicit concept in Cellml so as you will see in this <model> I have two time variables, t1 and t2. I essentially have (in one component, even) two models, one tracking the change in A over t1, and one tracking B over t2.
While it is possible to do this, most models I have seen simply have one time variable. But in CellML it is possible to have many.
As a slight tangent, as well as importing the same component to get multiple 'copies', I do know one researcher who uses cut-n-paste to achieve the same goal . That seems potentially bad to me, but for that researcher there are other constraints.... my point is that there is another possible way, even if few choose to take it (for good reason).
Connecting two variables up with different initial conditions is something of a contradiction. Perhaps think of the <connection> element as declaring a statement of equivalency. When time = 0, we would be declaring that two unequal quantities are in fact equal.... I haven't tried it but I would expect OpenCell to report that the model is overconstrained in that case.
The question about public/private interfaces interacts with grouping (the hierarchical component structure information which may be present in a model). Have you seen the CellML spec?
http://www.cellml.org/specifications/cellml_1.1Or, you can email me if you like and I will try to answer your questions, (although I'm on leave after tomorrow morning) - sometimes it's easier and quicker just to talk to someone :).
In my work with CellML, we have certainly gone in the 'fully modularised' direction. One advantage is that modularised models can be refined independently and for large systems that is desirable. It is also possible to write a tool to 'flatten' a model should you need it (and often they are more flexible for certain tasks when flattened), whereas going the other way automatically might be more tricky (although, I think, still possible if you don't mind the potential of losing some kinds of information along the way). To some extent, I would say it depends what you are trying to do, but the modular approach seems more flexible to me, even if there is sometimes extra overhead in terms of model verbosity and processing.
Finally, would you mind sending me a preprint or similar of your Antimony paper? In theory I should have access to it, but I seem to be having some problems with that just now, and it sounds intriguing :).
Cheers, Mike. Quoting Lucian Smith <[email protected]>:
So, my current project is to translate CellML to Antimony, and take advantage of the modularity in both. So I have a couple questions about that, first, to make sure I understand CellML modularity, and second, to ask all of you how you would expect to find CellML's modules converted. So, as I understand it, there are two ways to modularize a CellML model. You can put variables into components, and/or you can put models into files. For now, there is a 1:1 relationship between files and models--one file will contain exactly one model. One model might contain any number of components, but only one copy of each. If you want multiple copies of a module, you need to put it in another file, then import that model multiple times. There is no such thing as an imported model that is not part of the model that imports it, though it's possible to import a model and not connect it to anything, thereby creating, in effect, two separate models that are running at the same time. (Well, I guess you'd still have to connect 'time' in those models. What if you didn't?) Any aspect of an element of a model is only defined once, by design. I am not sure what happens if a variable in one component is given (say) an initial value, and another variable in a different component is given a different initial value, and then the two are connected. Is that invalid CellML? Can you only connect things that have compatible public_interface bits set? At any rate, it is at least clear that the intent is to set the public_interface parts appropriately. In Antimony, each module is distinct from the other modules, much as if they had been converted to different files in CellML--they can be imported as needed into other models, but have their own separate existence, and can function as complete models on their own. Given this, I'm inclined to convert CellML components into Antimony models, 'promoting' them. My worry is that in practice, CellML components might be pretty small, and promoting each component to a full-fledged model might not make much sense. But on the other hand, if I flatten all components to a single Antimony model, all the modularity within a model will have been lost, which also seems unfortunate. So it seems like a good question to ask the CellML community--would you rather see components fully modularized, or flattened? And going back the other way, will converting Antimony modules to CellML components be enough, or would you prefer to see them as distinct CellML files/models? (This also has ramifications in the future, when SBML gets modularity, or 'hierarchical modeling', as they're calling it, so I'm sure the issue will be raised again in the future.) Thanks! -Lucian Smith _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
TwoTimer.cellml
Description: application/cellml
_______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
