[cellml-discussion] on a CellML format

[David Nickerson]

Hi Taishin,

Firstly, I think most people on the team list are also on the 
cellml-discussion list so I'm dropping off the CC to the team list. Rest 
on my comments inline below...

Taishin Nomura wrote:
> Dear all,
> 
> We had a discussion on CellML format in response to the comment
> made by Bandall. In our discussion, we tried to illustrate structure 
> of coupled_pendulum.cellml. We are not sure whether or not you are
> interseted in this discussion. Nevertheless, we would like to make 
> this clear so that we can continue our effort to completely support 
> cellml API since we believe it has a definite meaning.
> 
> A dominant part of the file we are going to argue may be like fig. 1 
> shown temporalily at
> http://www3.bpe.es.osaka-u.ac.jp/~suzuki/coupled_pendulum.pdf
> This page will be closed when dicussion stops.
> 
> The corresponding structue may roughly be represented in fig. 2
> as a schematic diagram.
> 
> Then, possible implication of "private_interface" and "public_interface", 
> based on our understanding, is added to the diagram as fig. 3, 
> where 
> red lines indicate "public_interface" 
> and 
> blue lines "private_interface".
> 
> Can we share the understanding of this diagram?

yep - very nice diagrams!

> Suppose yes, then we have several questions and comments.
> 
> # On a Redundant definition of the initial value
> The initial value of 
> <variable name="b"> at <component name="Pendulum"> 
> and 
> <variable name="b"> at <component name="PendulumLowerSegment">
> are defined redundantly as indicated by fig. 4. 
> Is there any reason for this redundant definition?
> Please let us know. This is becuase if these two redundantly
> defined initial values are not identical, it may cause a problem.

definitely, as you describe the model the initial_value attribute for 
the b variable in the Pendulum component is not only redundant it is 
invalid CellML. (you can't have an initial_value if any of the 
interfaces is 'in'.)

> Note that we are aware of the fact that 
> <variable name="b"> at <component name="Pendulum"> 
> implies
> <variable name="b"> at <component name="PendulumLowerSegment"> 
> using <connection> property.
> We are also aware of the fact that
> the redundant definition of 
> <variable name="b"> at <component name="Pendulum"> 
> and 
> <variable name="b"> at <component name="PendulumLowerSegment">
> is natural and necessary to allow other components to utilze
> <variable name="b"> of <component name="Pendulum"> which is encapsulated. 

yep - that all makes sense.

> # Policy on location of definition of equations and initial values
> For example, 
> <variable name="a_angular_velocity"> is defined both 
> in <component name="Pendulum"> 
> and 
> in <component name="PendulumUpperSegment">. 
> This is okay for the same reason mentined above. 
> However, in this case, the initial value is defined 
> in <component name="Pendulum">, but no definition of equations, 
> while
> the equation is defined in <component name="PendulumUpperSegment">, 
> but no definition of the initial value.

I think you have name="Pendulum" and name="PendulumUpperSegment" swapped 
around, but again this is invalid CellML. Since variable 
a_angular_velocity (and also b_angular_velocity) has a private interface 
of 'in', it is invalid to define the differential equation 
d(a_angular_velocity)/dt in the Pendulum component.

> Regarding this sort of distributed definitions of properties of 
> an object, we would like to know your policy. Of course, 
> the current situation is fairly lax and the user can define a property
> anywhere within an encapsuled component, even in a component 
> in the encapsulated component. However, it could be a source of 
> errors if we have to deal with a complicated model with many
> properties and components.

I think this is because the model you are describing is invalid. This 
kind of distributed definition of properties is invalid CellML (as far 
as I can tell). Only the component which "owns" a variable (i.e., the 
component in which the variable is defined with no interface of "in") is 
allowed to alter the variable's value - either with an initial_value or 
some mathematical equation.

> # An alternative way to describe the pendulum (A proposal)
> Fig. 5 is an alternative structure to describe the pendulum. 
> It seems that this is natural in the following sense:
> every <variable> such as 
> <variable name="a_angular_velocity">
> or
> <variable name="b_angular_velocity">
> has both the initial value and the equation together.
> Then, the encapsulted <component name="Pendulum"> plays a 
> simple role to put 
> <component name="PendulumUpperSegment"> 
> and
> <component name="PendulumLowerSegment">
> together within a single component.
> 
> There may be other kinds of structure such as a case 
> illustrated in Fig. 6. 

Both of these look correct to me, although the one in Fig. 5 seems more 
natural to me :-)

Looking back, I see this is the PCEnv test model that Randall mentioned 
a while back. And looking at that original code it certainly looks like 
an invalid model to me...and passing it through Jonathan's validator 
(https://chaste.ediamond.ox.ac.uk/cellml/) that seems to agree with me...


Hope that helps clear things up,
David.