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 
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 

>  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,

cellml-discussion mailing list

Reply via email to