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

Text archives Help


[cellml-discussion] on a CellML format


Chronological Thread 
  • From: alan.garny at dpag.ox.ac.uk (Alan Garny)
  • Subject: [cellml-discussion] on a CellML format
  • Date: Wed, 22 Aug 2007 05:10:26 +0100
> -----Original Message-----
> From: cellml-discussion-bounces at cellml.org [mailto:cellml-discussion-
> bounces at cellml.org] On Behalf Of David Nickerson
> Sent: 22 August 2007 03:27
> To: CellML Discussion List
> Cc: taishin at izanami.bpe.es.osaka-u.ac.jp
> Subject: Re: [cellml-discussion] on a CellML format
>
> 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...

I would also agree with Taishin and David's assessment, and for what it is
worth, COR does too (i.e. it generates some errors upon opening such a
file)...

Alan.



Archive powered by MHonArc 2.6.18.

Top of page