CellML Discussion List

Text archives Help


[cellml-discussion] on a CellML format


Chronological Thread 
  • From: taishin at bpe.es.osaka-u.ac.jp (Taishin Nomura)
  • Subject: [cellml-discussion] on a CellML format
  • Date: Tue, 21 Aug 2007 23:12:24 +0900

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?

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.

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.

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

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.


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

We are looking forward to your comment on this.
Thanks.

Best regards, Yasu Suzuki and Taishin

----------------------------------------
Taishin Nomura, PhD, Professor
Department of Mechanical Science and Bioengineering
Graduate School of Engineering Science
Osaka University
Email: taishin at bpe.es.osaka-u.ac.jp
WebSite: http://www3.bpe.es.osaka-u.ac.jp
NEW!http://groups.yahoo.co.jp/group/physiome/messages
TEL: +81-6-6850-6532
FAX: +81-6-6850-6557






Archive powered by MHonArc 2.6.18.

Top of page