First login?
Lost password?
 
 
cellml-discussion AT lists.cellml.org 
CellML Discussion List

Text archives Help


[cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2


Chronological Thread 
  • From: r.britten at auckland.ac.nz (Randall Britten)
  • Subject: [cellml-discussion] A list of proposed changes to semantics to makein CellML 1.2
  • Date: Thu, 10 Jan 2008 11:49:37 +1300
I don't think we would need attribute values like "public_private" or
"both", since I think "public" access should imply "private" access, similar
to say c++ or Java's use of those terms.





From: cellml-discussion-bounces at cellml.org
[mailto:cellml-discussion-bounces at cellml.org] On Behalf Of Poul Nielsen
Sent: Sunday, 23 December 2007 10:25 p.m.
To: CellML Discussion List
Subject: Re: [cellml-discussion] A list of proposed changes to semantics to
makein CellML 1.2



Yes, the scheme that I proposed would not allow variables to 'pass through'
the public_interface and private_interface of a component. I imagine that
this could be inconvenient in some situations. We could enable this by
adding a fourth value, 'public_private', to the attribute list.



Best wishes

Poul



On 2007 Dec 22, at 20:21, Jonathan Cooper wrote:





On Sat, Dec 22, 2007 at 11:19:52AM +1300, Poul Nielsen wrote:

I think that Jonathan is correct - the concept of 'in' and 'out'

does not make sense in a declarative description. One way to remedy

this would be to remove the 'public_interface' and

'private_interface' attributes from the <variable> element and

replace them with an 'interface' attribute which could assume values

"public", "private", or "none". This is a pretty fundamental change

to the specification but I think that it better reflects the

declarative intent of CellML model descriptions.



How would that work for a component like B below, which has both a public

and private interface for the same variable?



Jonathan.





On 2007 Dec 22, at 03:20, Jonathan Cooper wrote:



On Thu, Dec 20, 2007 at 12:30:32AM +0800, David Nickerson wrote:

* The current specification says:

"A variable with either a private_interface or public_interface

attribute

value of "in" must be mapped to no more than one other

variable in the

model. [ Note that a similar restriction does not apply to

variables with

interface values of "out". An output variable can be mapped to

multiple

input variables in various components in the current model. ]"



The problem with this is that it doesn't properly account for

mappings where a variable is forwarded into an encapsulated

block. As

an example, consider the following encapsulation hierarchy (higher

components encapsulate lower ones)...



A

|

B

/ \

C D



Suppose that component A has, for variable v,

public_interface="none", private_interface="out", and B has for

variable v, public_interface="in", private_interface="out"

(connected to A), and C and D have public_interface="in",

private_interface="none", both of which are connected to B.



There is no reason why this should not be valid. However, the

specification contradicts itself on whether this is allowed. On

one

hand, because B has private_interface="out", it "can be mapped to

multiple input variables in various components in the current

model.", but because it has a public interface of in, it "must be

mapped to no more than one other variable in the model".



This can be fixed by firstly defining the interpretation of

connections and interfaces, and then adding constraints based on

that which actually describe which connections are allowed to each

set of variables.



will be interesting to see how such a definition ties in with the

idea

of input variables becoming output variables based on the way the

components are hooked together :)



Indeed.



The use of "in" and "out" on interfaces very strongly implies that

connections have a directionality, and this is also reflected in the

quote from the specification above - it assumes that variables are

only

defined in one place, and hence it doesn't make sense to import a

variable (via an "in" interface) from multiple locations. It does

however make sense to export a variable to multiple locations, or

forward

an imported variable to multiple locations (the example Andrew gives).



If we don't want connections to have directionality, then I think this

requires quite a major change in the specification, even if only to

avoid

user confusion. For example, I would want to deprecate the use of

"in"

and "out", and instead allow public_interface="yes" or

public_interface="no" (perhaps a synonym for "none") and similarly for

private interfaces. The terms used in the language then reflect the

nature of the interfaces - if connections are bidirectional, then it

doesn't make sense to talk of an "in" interface, since it may function

either as input or output depending on the other components in the

system.



Jonathan.



--

Jonathan Cooper MSN: msn at jonc.me.uk www: jonc.me.uk/



We are tribbles of Borg. Prepare to be replicated.

_______________________________________________

cellml-discussion mailing list

cellml-discussion at cellml.org

http://www.cellml.org/mailman/listinfo/cellml-discussion



_______________________________________________

cellml-discussion mailing list

cellml-discussion at cellml.org

http://www.cellml.org/mailman/listinfo/cellml-discussion



--

Jonathan Cooper MSN: msn at jonc.me.uk www: jonc.me.uk/



I haven't lost my mind... It's backed up on tape somewhere.

_______________________________________________

cellml-discussion mailing list

cellml-discussion at cellml.org

http://www.cellml.org/mailman/listinfo/cellml-discussion



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.cellml.org/pipermail/cellml-discussion/attachments/20080110/a472bcb5/attachment-0001.htm



Archive powered by MHonArc 2.6.18.

Top of page