Michael Cooling wrote: >> because if connections don't have directionality, then it makes no >> sense in the language to say >> that a connection is from A to B, as opposed to from B to A, and we >> wouldn't want to force users to duplicate information and provide both >> > > Oops I didn't mean to imply directionality. I shouldn't have used the > words 'from' and 'to', sorry. It's not the language that I want to > change. > > >> I'm not sure what you mean there. In CellML 1.1, there can be attributes >> like public_interface="in" private_interface="out", I have used >> something more like public_interface="yes" or public_interface="no" >> here, thereby removing the directionality - in and out correspond to >> yes, none corresponds to no. >> > > Ah I see. I suspect just having an optional public_interface="yes" > would be the way to go, private="yes" being always > implicit. I.e. private by default, and public includes private. As you > say this will no doubt be discussed later. >
This particular aspect has already been discussed. See http://www.cellml.org/pipermail/cellml-discussion/2008-January/001144.html and the follow on discussion for why public and private interfaces are not analogous to public and private in most object orientated programming languages, and why public does not imply private. By default, we have public_interface="no" private_interface="no", which means that the variable cannot be used outside of the component. public_interface="yes" means that encapsulating components can connect to the variable, while private_interface="yes" means that encapsulated components can connect to the variable. > >> The mathematical model you get from this would be sub-optimal without >> some intelligence on the part of software tools - there would be two >> state variables with identical rates and initial values for the >> concentration of b and the concentration of y >> > > This is why I am wary of such convenience components....they imply an > interface that doesn't really exist - I think they can be useful but > since one never > knows what might get connected to what.... > Removing directionality, and using sets for the list of all fluxes mean that it doesn't matter what the flux set is connected to behind the interface. The duplication of state variables is unfortunate, but it doesn't actually have any theoretical implications for the correctness of the model, if both state variables have the same initial values and rates (which they would, since they are the sum over the same set of fluxes). This means that the model should just work in all cases. > If one tries to use them as an interface to the system that MUST be > used (not that you were doing this) > then you limit the usefulness of your model...essentially you are > assuming that your interface is sufficient for all future > requirements. Yes, and that is a good assumption if you provide everything on the interface. > Even for ion channels, that might not be true in the future. > I think duplications may also be resolved by chosing a particular substance_b > (ie human decision) at model aggregation-time facilitated by tools > identifying this situation. > I don't think we want to do that manually. The duplication is only a problem because it artificially inflates the dimensionality of the model, creating a performance problem, and the algorithm to detect this artificial inflation of dimensionality and merge the state variables for computational purposes should be tractable if we limit it to the case where identical variables are being put through an identical equations, rather than going for a more general and costly isomorphic mathematical structure detection. Best regards, Andrew _______________________________________________ cellml-discussion mailing list [email protected] http://www.cellml.org/mailman/listinfo/cellml-discussion
