Chronological Thread 

< Chronological >      < Thread >

---

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.

---

• [cellml-discussion] on a CellML format, Taishin Nomura, 08/22/2007
  • [cellml-discussion] on a CellML format, David Nickerson, 08/22/2007
    • [cellml-discussion] on a CellML format, Alan Garny, 08/22/2007
    • [cellml-discussion] on a CellML format, Taishin Nomura, 08/23/2007

---

Archive powered by MHonArc 2.6.18.