a computational framework to describe and solve temporo
TRANSCRIPT
University of New South Wales
Graduate School of Biomedical Engineering
A Computational Framework to
Describe and Solve Temporo-Spatial
Biological Models
David Chan-Wei Chang
A dissertation submitted in fulfilment of the requirements
for the degree of
Doctor of Philosophy
2009
4
Acknowledgement
The work produced in this thesis could not have been achieved without the help of many
people Irsquod like to first thank my supervisors Dr Socrates Dokos for his guidance and
support from the very beginning of this project to the write up of this thesis His attention to
details and patience has been invaluable Professor Nigel Lovell for the job opportunities
academic expertise and help throughout my candidature Without their help this project
would not have been possible I also like to thank my fellow modelling team members Ben
Bunny Hui and Amr Abed for their assistances in this project
This has been a very long and mixed journey Irsquod like to thank my friends Anna Louis
Dean Michael Mitra Shuhaida Einly Nitzan and David for making this journey a lot
smoother and more enjoyable than it shouldrsquove been I would also like to add a special
thanks to Amy and Noppadol for proof reading this thesis
I especially like to thank my parents and dedicate this thesis to them Wen-Te Chang and
Chiung-Jen Hsu for their unwavering support and encouragements I will always be in debt
to them for the opportunities that they have made possible allowing me to pursue this path
which has left me a richer person I also like to thank my sisters Lisa Julia and Christianna
for the help during these four years
5
Abstract
With the ever-increasing volume and complexity of mathematical biological models and
experimental datasets becoming available there is a strong need for a set of representation
languages which can describe and represent these models and data in standard forms and
store them in publically available repositories for universal dissemination
To help address this issue the Modelling Markup Language (MML) computational
framework was developed in this project It consists of representation languages and
application toolsets that can represent store and solve biological temporo-spatial models
The representation languages are comprised of ModelML responsible for maintaining
relational information between different external models along with the Field Markup
Language (FML) responsible for maintaining geometric field information such as
anatomical data The MML framework also utilises the existing CellML specification to
represent biological systems models With these three representation languages a temporo-
spatial model can be created re-used interchanged and shared In addition specially-
developed application toolsets provide utilities which aid in the creation and processing of
the MML models
To demonstrate the capability of the MML framework a series of simulations of cardiac
electrical activity are presented including simulations of the cardiac pacemaker (sinoatrial
node) and atrial tissue activation In the sinoatrial node simulations tissue electrical
conductivity was adjusted to observe its effect on sinoatrial node entrainment and inhibition
by the atria using several 1D 2D and 3D tissue geometry layouts and cellular
mathematical models Additional simulations were performed by modifying the magnitude
of the hyperpolarisation-activated membrane current (if) of the underlying cellular models
to observe its effect on pacemaker activation and impulse propagation into the atria The
use of the MML framework allowed these models to be constructed rapidly through its
ability to efficiently reuse and modify underlying geometric and mathematical components
6
TABLE OF CONTENT
ACKNOWLEDGEMENT 4
ABSTRACT 5
TABLE OF CONTENT 6
PART I THE MML COMPUTATIONAL FRAMEWORK 8
CHAPTER 1 INTRODUCTION 9
11 THESIS AIMS 13
12 THESIS ORGANISATION 13
CHAPTER 2 EXISTING APPROACHES 15
21 FRAMEWORKS AND SPECIFICATIONS OVERVIEW 15
22 TOOLS AND TECHNIQUES 28
CHAPTER 3 MODELLING MARKUP LANGUAGES (MML) SPECIFICATION 33
31 INTRODUCTION 33
32 THE MODELLING MARKUP LANGUAGES (MML) 34
33 GENERAL MML USAGE AND DEFINITIONS 43
34 HDF5 57
35 MML IMPORT MECHANISM 64
36 MML MATHEMATICAL OBJECTS 70
37 THE MODELML SPECIFICATION 79
38 THE FML SPECIFICATION 101
39 CONCLUDING REMARKS 137
CHAPTER 4 APPLICATION TOOLSET 139
41 INTRODUCTION 139
42 AUTHORING TOOLS 141
43 UTILITY TOOLS 155
44 PARSING TOOLS 168
45 TOOLSET SUMMARY AND DISCUSSION 186
PART II SIMULATIONS OF CARDIAC PACEMAKER AND ATRIAL ELECTRICAL ACTIVITY
USING THE MML FRAMEWORK 189
CHAPTER 5 MODELLING CARDIAC ELECTRICAL FUNCTION AN OVERVIEW 190
51 INTRODUCTION 190
52 CARDIAC ELECTRICAL FUNCTION 191
7
53 CARDIAC MODELLING 198
CHAPTER 6 CARDIAC SIMULATION USING MML 208
61 CELLML CARDIAC CELL REVIEW 209
62 1D ATRIAL CONDUCTION SIMULATIONS 218
63 2D3D MODELS OF THE SINOATRIAL NODE PACEMAKER 234
64 ARRHYTHMIA SIMULATIONS 258
65 CONCLUSION 282
CHAPTER 7 CONCLUSION 284
71 FUTURE EXTENSIONS 286
APPENDIX A QUICK AUTHORING TOOL GUIDE 290
A1 INTRODUCTION 290
A2 WALKTHROUGH 306
APPENDIX B APPLICATION GUIDELINES 318
B1 GEOMETRY PARSING 318
B2 CELLML PARSING 320
B3 MATHEMATICAL STRING GRAMMAR RULE 321
B4 UNIT CHECKING RULES 324
APPENDIX C WEB RESOURCE amp DOWNLOADABLE CONTENT 326
C1 DOCUMENTS 327
C2 FILES 327
APPENDIX D CLASS AND FUNCTIONALITY SUMMARY LIST 329
D1 ECLIPSE PLUG-IN AND PACKAGES 329
D2 MML PARSER SUMMARY 331
D3 AUTHORING TOOL SUMMARY 336
D4 UTILITY TOOL SUMMARY 337
APPENDIX E DATA FITTING METHODS 341
E1 GENERAL INTERPOLATION METHODS 341
APPENDIX F APPLICATION AND PACKAGES 351
F1 APPLICATIONS AND PACKAGES 351
APPENDIX G PUBLICATIONS 353
REFERENCES 354
8
Part I The MML Computational Framework
9
Chapter 1 Introduction
An extensive collection of biological experimental and modelling information is available
from two centuries of reductionism in biomedical science producing a rich but in most
cases unorganised source of knowledge This includes advances over the past fifty years
where significant progress in molecular and cellular biology have made possible the
understanding of physiological systems over spatial scales from nanometres to metres and
temporal scales from microseconds to seconds [1]
Human physiology is a complex and vast field From gene signalling to cellular events to
higher physiological levels of organ and tissue functionality the understanding of
numerous intricate and interdependent systems has the potential to impact on research
approaches and clinical practice including the tracking and detection of diseases and
disorders and the impact of therapeutic agents and their side effects [2] Moreover in the
future it is likely that generalised models may be made patient specific to allow for targeted
clinical interventions to better treat and manage disease in specific individuals
Figure 1-1 Biological modelling covers a wide range of temporal and spatial scales ranging from genes
to organ level structures (From [3])
10
Examples of areas of physiological research that have been the subject of intense modelling
efforts include the cardiovascular system and the respiratory system An in-depth and
integrative understanding of the heart from electrical activation to cardiac mechanics
requires knowledge spanning from the underlying ionic currents and signal transduction
pathways to tissue structure including muscle fibre orientation and composition The
respiratory system includes the lung where the exchange of oxygen and carbon dioxide
occurs Its function is strongly dependent on fine anatomical structures such as the site of
blood gas exchange via capillaries that line the walls of alveoli
These examples show the complexity of human physiology from systems biology to organ
functions and structures Such complex systems require a specialised framework that can
handle the wide range of temporo-spatial scales from molecular and cellular events to
integrative organ functions Recent advances in technology - in both clinical imaging
applications and computer science - have brought about a possible means to bridge the
differing spatial and temporal scales and create more integrative models of physiological
systems
Mathematical modelling is the foundation of physics and chemistry and is a powerful
means to describe and analyse biological systems across many different spatial and
temporal domains Such domains range from the size of large molecules and proteins to
body size and from the timescale of Brownian motion to the life span of a human [3] as
shown in Figure 1-1 A unified mathematical model that covers all such scales is
impractical however An intermediate solution is to implement a number of different
models at predetermined scales and link their parameters [4-5] Additionally biological
functions are often difficult to model due to their sheer complexity As such modellers
often introduce simplifying assumptions which they often justify as long as the error is
within an acceptable range
Biological modelling can be categorised into spatial scales that include organ and organ
systems tissues cell molecules and genome Organ-level modelling is centred around
continuum models by which the behaviour of the organ can be derived without the need to
detail all of its sub-components At this spatial level model behaviour is derived from
11
physical conservation laws such as the conservation of mass energy and charge The level
of detail that an organ model should provide is dependent on the type of problem that is
being investigated For example heart failure associated with reduced ion channel
expression requires the consideration of signal pathway transduction and its relationships
with heart mechanics whereas simple electrophysiological models can ignore these
underlying pathways Organ-level modelling may also have to consider multiple physics
specifications for example lung function is dependent on gas flow and tissue deformation
mechanics as well as blood flow in the pulmonary circuit all within the same spatial scale
A great challenge in the area of tissue modelling is the relationship between structure and
function across different spatial scales Although tissues can be modelled based on
mechanical constitutive laws that provide an average description of their mechanical
properties such an approach does not take into consideration the underlying components
that constitute the tissues For example the mechanical property of cartilage is dependent
on the underlying collagen-proteoglycan matrix Similarly for heart tissue ion channel
expression gap junction and collagen density determines the passive and active
mechanical properties of that tissue [3]
Cellular modelling shifts away from the physics of conservation laws seen in tissue and
organ-level modelling to the modelling of complex biochemistry including transport
metabolism signalling cell structure and cell life cycle Cellular modelling involves both
structural and functional modelling
Modelling provides a means to integrate knowledge It can be used to optimise models
against measurements in biological and clinical research as well as to simulate and predict
behaviours where experimentation is impractical The application of modelling in clinical
research drug development and physiological research is immense from cellular level to
tissue and to organs and organ systems The idea to integrate models from different levels
of biology is a complex problem that spans the fields of biological science to computational
biology and computer engineering
Numerous questions on how to deal with such complexity in biological modelling have
been raised [6] Even in this information age finding and creating these complex biological
12
models is still a time-consuming task A typical complex biological model may be defined
by hundred of state variables and differential equations It is a laborious task for researchers
to find the correct information code this appropriately and ensure that the model can be
solved even before they can attempt to address the core questions of their research The
internet and its rapid adoption over the past decade have been central to the design and
implementation of the computational approach to integrative biological models It has
allowed research groups to share data and collaborate more easily A standardised data
format a robust paradigm to create models of different temporal or spatial scales a set of
tools that will facilitate in the creation sharing and solving of these models are all needed
given the current technological environment and the wealth of experimental and modelling
data
A number of possible approaches have been proposed and developed including projects that
cover specific aspects of integrative biological modelling These projects include System
Biological Markup Language (SBML) [7] and CellML [8] both of which provide an
interchangeable representational language and associated tools
One framework that describes whole integrative biological models is the Physiome Project
[9] It provides a set of goals including computational tools that will aid and facilitate in the
sharing storage and representation of models and data through a set of standardised
languages and associated tools Other approaches such as E-Cell [10] or Virtual cell [11]
provide an integrated development environment for electrophysiological simulations of
cells They are examples of approaches that attempt to bridge the information gap that
exists in biological modelling by providing interchangeable data formats tools or
framework environments that facilitate the exchange of knowledge and integration of data
between different spatial and temporal scales However despite these laudable aims there
still exist very few usable specifications and tools to describe and share organ-level models
The main aim of many of these projects is to simplify the task of creating complex
biological models and allow researchers to focus on the core issue of researching and
investigating sophisticated medicalbiological related questions
13
Given the technology and computational power available today the ultimate goal of the
Physiome Project is still out of reach However there are a number of areas that can be
addressed with existing computation systems The primary goal of this study is to develop
an organ-level modelling framework that will encourage the development reuse and
sharing of biological models and their components Furthermore using this framework
enables an efficient workflow process which simplifies the creation of complex biological
models as demonstrated later in this thesis This framework includes relational and field
representation languages and relevant tools that will facilitate the creation and solving of
organ-based modelling The relational specification will utilise existing specifications such
as CellML to construct and solve temporo-spatial biological models The field specification
format will describe field-related data such as geometries or field attribute information
11 Thesis aims
The aims of this thesis are
1) To develop a novel biological modelling framework consisting of custom-
developed ModelML and FML specification languages that describes relational and
field information utilising existing technologies such as the CellML specification
2) To develop a relevant application toolset that includes authoring and utility tools
used generate solvable scripts of the biological models
3) To make available the developed open source tools and specifications on a
publically accessible internet website
4) To implement test models using the newly-developed framework consisting of
cardiac pacemaker (sinoatrial node) simulations and simulations of atrial electrical
activity This demonstrates the process of creating simple to complex biological
models quickly and efficiently enabling the investigation of issues in cardiac
electrophysiology
12 Thesis organisation
This dissertation is organised into 7 chapters
In chapter 2 a description of existing representation languages and biological model
solvers is presented Chapters 3 and 4 present the specification and application components
14
of the modelling markup language (MML) framework used in this study In chapter 3 the
component breakdown of the MML framework is discussed followed by the design and
implementation of ModelML FML and related specifications In chapter 4 the application
component is presented including the tools and methods used and the specific application
toolset developed to fulfil the goals of the modelling framework This includes an authoring
toolkit parsing tools and utility tools
In chapters 5 and 6 the application of the MML framework is demonstrated through the
implementation of models of the cardiac sinoatrial node (SAN) and atria Chapter 5
provides a basic overview of SAN electrophysiology and presents related simulations on
the SAN and atria In chapter 6 further test simulation studies are presented including a
review of usable CellML models from the CellML repository1 and other sources [12]
Simulation studies of various tissue conductivity values to elicit certain behaviours of the
SAN including entrainment and suppression as well as simulations of atrial propagation
caused by alteration of SAN properties are also presented These test simulations show how
the MML framework can easily interchange cardiac cell or geometric models to create the
desired simulation scenarios
Chapter 7 summarises the outcome limitations and potential future work of this research
project
1 httpmodelscellmlorg
15
Chapter 2 Existing Approaches
21 Frameworks and specifications overview
211 The Physiome Project
The Physiome Project2 was proposed at the 32nd World congress of International Union of
Physiological Science (IUPS) in Glasgow UK Its stated goal is to ldquodevelop integrative
models at all levels of biological organisation from genes to the whole organism via gene
regulatory networks protein pathways integrative cell function and tissue and whole organ
structurefunction relationsrdquo [13] To achieve this the Physiome Project aims consist of
providing a method to acquire and store all aspects of biological information into a database
environment construct a descriptive and quantitative model that integrates this knowledge
and to organise collaborations that target specific areas of integrative biology[14] In
summary the Physiome Project modelling framework can be separated into three steps the
biological understanding of the model the mathematical expression of that understanding
and the computational environment that will allow the mathematical formulation to be
solved and shared[9]
To achieve these goals the computational development can be further categorised to
include the development of a complex database environment that stores all aspects of
biological data This database should be capable of communicating with other existing
databases creating relational information between different sets of data and be publicly
accessible and searchable so that the information can be used by other research groups To
achieve such a database environment in where heterogeneous databases are required to be
integrated and communicate with each other the concept of ldquoindependencerdquo from software
engineering is required ldquoIndependencerdquo refers to separating the ldquoimplementationrdquo details
from ldquointerconnectionrdquo details This requires a data interchange format between different
storage entities or software applications[6] As such to implement the goals of the
Physiome Project suitable interchangeable representation languages for different levels of
biology are required This allows models to be shared across different media collaborating
groups and software applications
2 httpwwwphysiomeorgnz
16
Figure 2-1 The original Physiome project proposed representation languages AnatML to represent
organ systems FieldML to represent organs TissueML to represent tissues and CellML to represent
cellular models (From [15])
Initially a number of standardised representation languages were proposed by the
Physiome Project as shown in Figure 2-1 These included AnatML to describe Organ
Systems FieldML to describe Organ models TissueML to describe tissue models and
CellML to describe cellular models[9] An omission was made in the original Physiome
paradigm of multi-cell modelling where each cellrsquos internal behaviour and output
determine its macroscopic properties This information can be used to simulate cell to cell
interactions Multi-cell modelling is important in areas such as biomechanics or cardiac
mechanics where the cell structure may change over time
Currently only CellML is implemented and adopted by a number of application and
academic research groups There is however some limitations to this initial design
17
Physiome representation languages are based on biological hierarchy although this may be
intuitive to biologist there are a number of issues with regards to computational design
mainly that there are overlaps of data between different representation languages A newer
paradigm that focused on relational field and mathematical data was suggested in the
CellML 2007 workshop these are assigned to ModelML FieldML and CellML
representation languages respectively[16] This approach attempts to decouple biological
semantics from the mathematical model where biological concepts are added as an external
source of information This will promote modularity and dependency between different
categories of data which encourages reusability and efficiency
SemSim3[17] (Semantic simulation) is an ontological based framework with the aim of
facilitating sharing reuse and modular construction of biological models To achieve this
biological models in other formats need to be converted into the SemSim The SemSim
model components (code words and modules) are annotated against standardised reference
ontologies This allows models to possess biological meanings and allows computational
algorithms to distinguish compose decompose and perform analysis on different models
based on these ontological standards Using this approach to map standardised definitions
onto biological models SemSim allows multi-scale and multi-domain approaches to model
construction
SemGen[18] is a software tool that allows existing biological models to be converted into
the SemSim model and annotated with semantic data and converts the SemSim model into
an executable format to solve for SemGen currently only supports JSimrsquos4 Mathematical
Markup Language format as both the input model and for output simulation
Currently both SemSim and SemGen are under active development It is possible that more
procedural languages such as Matlab or Fortran and declarative languages such as CellML
or SBML can be supported The approaches of the Physiome Project and SemSim are very
different in an attempt to provide a solution to a common problem The use of ontology
could potentially give SemSim a greater flexibility in describing all types of models over
different scales and domains However the need to define a data structure to contain these
3 httpsitesgooglecomsitesemanticsofbiologicalprocessesprojectssemsim
4 httpwwwphysiomeorgjsim
18
types of information is still required and a method to annotate these languages must be
implemented In theory SemSim and the languages and computational resources proposed
by the Physiome project could be utilised together to create composite models
The current status of the development of the representation languages in the Physiome
Project includes the active development of CellML and FieldML with CellML already
available for use The motivation behind this thesis is driven by the limitations that
currently exist in the Physiome Project including a lack of tools and representation
language to describe temporo-spatial biological models
212 CellML
CellML5 was originally designed as a standard format for defining and exchanging
biological systems models[19] however its flexibility also allows it to store a wide array of
mathematical models It is capable of describing model structure mathematics and
metadata information
CellML models consist of a network of interconnected components where a component is
the smallest functional unit of a CellML model Each component may contain variables and
equations with variables connected to form a complex network system CellML also allows
one model to import and reuse components and units from other CellML models through
the use of the ltimportgt tag [8] CellML provides units and metadata support to describe
models and adopts a number of standardised languages including MathML and RDF
CellML currently has a stable specification released (v11) To facilitate the usage of the
CellML specification a number of tools and a public repository are provided The public
tool includes an application programming interface (API) that allows users to access and
process CellML documents from their own software Other applications such as authoring
tools ldquoOpenCellsrdquo and a number of validations and utility applications are provided to
assist in the creation and processing of CellML models (httpwwwcellmlorgtools)
5 httpwwwcellmlorg
19
The CellML repository6 currently contains over 400 biological models that range from
electrophysiology to metabolism model types [20] The aim of this repository is to provide
curated published models for public use Curation of a model is classified into 4 levels
ranging from a non-curated model a model that is consistent with the mathematics in the
original paper a model that has been checked for typography unit and parameter values
and correctly runs on a number of solver software including PcENV and COR to reproduce
the result from the original paper and the final curation level which states that the CellML
model satisfies the physical constraints such as conservation of mass etc The curated
models provide a usable and tested model available for use
The Physiome Project attempts to provide an overall approach to integrative biology
however there are numerous projects and tools which target specific types of biological
model In the following sections common cellular and systems biology models similar to
CellML will be reviewed These include systems biology tools such as SBML and other
alternatives Another area important to biological modelling is field representation
including field representation languages such as FRL AFL and FieldML
With an increasing amount of experimental data becoming available on genes proteins and
interactions between different molecular species there has become a need to describe share
and analyse how all these contribute to the function of a cell The general objects that can
be described in system biology includes molecular species which participate in any
interactions these can be from DNA to macromolecules Also included are the interactions
of species and the pathways of that interaction as well as the compartments which describe
the location of where the interaction may occur System biology has become important in
biological modelling and represents a major research focus as to how this type of
information can be represented
The Systems Biology Markup Language (SBML)7 is an XML representation language
describing biochemical reaction including cell signalling pathways metabolic pathways
gene regulation and many others [7] The initial goal of such a representation language was
to allow existing simulation software to communicate with each other SBMLrsquos primary
6 httpmodelscellmlorg
7 httpwwwsbmlorg
20
goal is to serve as a ldquoLingua Francardquo defined as ldquoa language systematically used to
communicate between persons not sharing a mother tongue in particular when it is a third
language distinct from both persons mother tonguesrdquo In short SBML is designed to be an
exchange format and not a universal language to describe a quantitative model SBMLrsquos
stated goal is to provide a data format to be shared between software applications without
rewriting a model for each software - a collaborative format for research groups that can be
used in different software environment and ensuring a model is independent of a specific
softwarersquos lifecycle
SBML is perhaps the closest related representation language to CellML in terms of what
can be represented The basic components of SBML consist of function definitions unit
definitions compartment definitions species type parameter initial assignment rule
constraint and reaction SBML like CellML employs MathML to describe mathematical
content however SBML limits the MathML syntax usage compared to CellML
MathML[21] is a mathematical representation language created by the World Wide Web
Consortium (W3C) SBML lacks the general flexibility of CellML in terms of
mathematical model representation as it is primarily aimed for systems biology Both
SBML and CellML support ordinary differential equation modelling SBML currently
supports events trigger and time delays whereas CellML does not Neither SBML nor
CellML currently support partial differential equation modelling however the incorporation
of FieldML with CellML may change this SBML has greater third party support by many
databases including KEGG8 and Reactome
9 and support with over 100 software systems
213 Other representation languages for systems biology
In a 2007 review of system biology representation languages[22] it was noted that there
were over 85 XML based system biology representation languages The review noted
common systems biology representation languages containing either available data or tools
for use including PSI MI BioPax CML EMBLxml INSD-seq Seq-entry BSM HUP-
ML MAGE-ML MzXML Mzdata and AGML Many of these system biology languages
provide data structure support or linkage methods to describe only a certain combination of
8 httpwwwgenomejpkegg
9 httpreactomeorg
21
interactionspathways compartmentsspecies or experimental setup and results A common
focus of these languages is the handling of ontologies Ontology in systems biology is used
as a common terminology definition that promotes reuse sharing and portability Many of
these languages including SBML support the use of external ontologies from Open
Biomedical Ontologies10
(OBO) as a means to standardize the concept from these
representation languages The review also noted that these languages vary considerably in
the way they use XML For example the same type of information expressed in one
language may take considerably more XML content in another Furthermore the method to
represent information can vary greatly including not fully using the XML structure
capabilities such as using semicolons in text strings to separate data in an element rather
than inserting this data as elements of the XML structure This can be seen in languages
such as INSD-seq and FRL A major disadvantage of this is that a secondary parsing tool is
required to separate the data after the XML parser has processed the document
CellML is a flexible mathematical model representation language Similarly SBML and
many other systems biology representation languages provide representation capabilities
for certain areas of cellular modelling with all these representation languages exhibiting
some degree of overlap The strength and weakness of these languages can be measured by
the scope of the representation including ontology support and support in terms of the data
and application that the framework provides The design and implementation of these
representation languages such as the utilisation of XML format also factor These are the
requirements that can determine the suitability of a representation language for use
However many of these system biology languages are not within the scope of this current
research topic Nonetheless future work could involve integrating system biology
representations such as biochemical modelling and multi-cell modelling into the spatial
domain using the MML framework described in this thesis
214 Field representation
Another area relevant to biological modelling is fields A field can be defined as variation
of a property over space and time which can be described using analytic or numeric
methods Analytic representation uses equations to represent a field in a domain Numeric
10
httpwwwobofoundryorg
22
representation involves a supplied set of points or additional data with interpolating
functions to construct the desired field Field information is used to construct temporo-
spatial domain problems including spatial information of geometric models of anatomical
objects There are a number of open and commercial formats to describe geometric objects
However the scope of field representation generally exceeds geometric representation
format schemes currently available
A field representation language is required to facilitate interaction between modelling
information applications and research groups with regards to field data Currently there
are two representation languages for fields FRLAFL[23] and FieldML[24]
FRL and AFL refers to Field Representation Language and Abstract Field Layer
respectively[25] Abstract Field Layer provides an abstract interface that is independent of
the field representation method the AFL provides a consistent interface to the data such
that the tool developers do not have to worry about the specific implementation of the field
representation scheme FRL is a combination of XML and the HDF5 based representation
format that is responsible for the concrete representation and storage of the data AFL and
FRL are based on layer architecture In theory AFL can be used with other field
representation schemes
FRL uses the file system directory to store and organise the file data As such directory
names follow a rule of using ldquofrlrdquo or ldquoddfrdquo to specify the property of the data (ie FRL
XML or HDF5 file) held in that folder FRL supports the representation of analytic and
numeric fields and field boundaries as well as boundary conditions In FRL XML format
the highest element is ltfrlgt which may contain a field (ltfieldgt) definition or a composite
(ltcompositegt) element which describes a field composed of other fields In FRL a field
definition may contain the name of the field the dimension of the domain and the
coordinate system It may describe the interpolation functions using either analytic or
numeric methods A field definition can also contain boundary and boundary condition
information
There are a number of design and implementation issues that should be noted
Mathematical expressions are declared using strings In some circumstances data are
23
separated using commas while stored as an attribute of an XML element Although some of
these issues can be overcome by the use of supplied applications third party developers
will need to parse the XML DOM structure and analyse the text stored in the XML
structure to retrieve the basic data components The file system structure of FRL introduces
a dependency on the vendor operating system and issues when transferring FRLAFL
models This may introduce extra complexity when FRL is stored on a database that does
not support a directory hierarchy scheme The composite element in FRL could potentially
be used to link external sources such as CellML to fields in FRL however this has not yet
been implemented As such FRL has limitations in reusing external data sources and the
mechanism for referring to them This is related to the lack of support for universal
resource identifier (URI) and XLink which provides a standardised method to reference
different types of data resources (ie web address) These issues will have to be addressed
in our field language design
The FRLAFL project also consists of a solver framework and field visualisation platform
The solver framework can be used to solve a lumped-parameter model across a spatial
domain The Cellular mathematical model is hard-coded in Although it is possible to use
CellML and SBML data format to supply the required information no support for this
feature has been implemented yet The result can be visualised using the Visiome[26]
software platform
FieldML[24] is a companion representation language intended to complement CellML[27]
FieldML11
is in its early stage of development and as such the specification is not yet
complete and not available for use The main goals and concept of FieldML are to represent
fields including finite element fields with element order basis functions as well as
generalised fields using a hierarchical architecture As described in [24] this is achieved by
using a ldquofield typerdquo abstract class In the current concept of FieldML actual fields are
derived from this abstract class allowing fields to be operated on by other fields This
abstraction also allows parameters and domain objects to be treated as fields as well In
FieldML (domain fields) domains are divided into sets of objects and continous coordinate
systems where field definition can reside in FieldML supports real and complex scalars as
11
httpwwwphysiomeprojectorgxml_languagesfieldml
24
well as vector and matrixtensor field values The current FieldML conceptual design also
allow hierarchal meshes as well as fields which allows encapsulation separating field and
namespaces allowing models and sub-model to exist without interference
Part of the FieldML project is to eventually provide an API and associated development
tool as part of an open source development FieldML currently supports limited
functionality including regions which contain objects of a model field definitions and
attribute representation The development of FieldML is currently closely associated with
the API development which is linked to the CMISS (solver) and CMGui (visualisation)
software development (httpwwwcmissorg) Although it is intended that FieldML will
utilise XML the FieldML development team has noted that FieldML is an API and
software library designed with flexibility in mind and can be described using multiple data
formats[28] The implementation of an integration between FieldML and CellML is yet to
be released however it has been suggested that in the long term CellML and FieldML may
merge However in the mean time FieldML will utilise many concepts from the CellML
specification
There is a need to represent field in a standardised manner A field representation language
can have a number of uses including representing anatomical objects and geometries as
well as field attributes or attribute information associated with experiments This allows
the information to be interchanged and integrated across different domains and mediums
The current progress of field representation development is in its early stages and current
goals are to integrate field representation languages with other representation languages to
create multi-layer model representations FieldML at the time of writing this thesis was
not available for use while the FRLAFL framework has several limitations including its
inability to incorporate external data such as CellML limitations in its ability to provide a
mechanism for describing geometric models In addition the utilisation of XML data
representation and the requirement of file system may be problematic when sharing the
model itself These are some of the concerns that will need to be addressed in the
development of a field representation language such as that described in this thesis
25
Underlying these biological modelling representation languages are the data formats A
data format specifies how the information is encoded and stored into a computer storage
device Data formats play an important role insofar as they dictate how the data is stored
processed and shared This in turn affects the data design supporting applications
development the usage of the language by different users and the performance of the
representation language In the following section some common data formats available for
biological modelling and bioinformatics will be summarised including the advantages and
the limitations of each format and the applications in terms of biological modelling
215 Data representation
XML (eXtensible Markup Language)[29] is a web standard which is a Standard
Generalised Markup Language (SGML) based language which aims to describe data
objects in a format that is compatible across a range of platforms and applications It is both
machine and human readable and is easily exchanged through the internet XML
documents are made up of data storages referred to as entities These entities are created
from various tags defined within the XML XML can also be seen as a loosely structured
set of rules which allow users to define store and organise data As a result of its
popularity XML is widely supported by a vast range of applications and supporting tools
for its creation presentation and manipulation which makes it a suitable format for
biological representation languages [30-31]
Although XML is an accepted standard for documents on the internet it possesses both
advantages and disadvantages in describing mathematical biological models XML is an
attractive approach as a framework for a representation language because it is highly
flexible It is conceptually simple yet powerful allowing developers to define standard
specifications It is also easily exchangeable through the internet with a wide range of
applications protocols and supporting formats available such as DTD Schema and XPath
query There are also other mature XML standards available to incorporate into the
developerrsquos specification such as MathML for describing mathematical expressions
XLINK for linking XML documents together or Resource Descriptive Format (RDF) that
can be used to describe the metadata of a model However XML may not be suitable for
describing large numeric datasets due to the text based nature of this data format
26
JSON[32] stands for Javascript Object Notation it is a light weight data interchange format
that can represent simple data structures and associative arrays Although JSON is part of
the Javascript programming language it is considered to be a language independent data
format JSON is currently used primarily to transfer data over networks and is an
alternative to XML JSON and XML share many similar features including simplicity in
data representation interoperability and are self-describing However there are also a
number of differences JSON is more suitable as a data exchange format while XML is
suited to document exchange since JSON is not extensible like XML JSON cannot define
new tags or attributes to represent data JSON and XML both lack the ability to represent
binary or large numeric datasets efficiently
Other alternative data formats include simple flat files Such files are commonly used to
interchange information often stored as field name followed by the value Flat files are a
very simple solution which lack referencing type vocabulary controls and contextual
information about the structure of the data stored An example popular format is CSV
(comma-separated version) Abstract Syntax Notation One (ASN1) is another file format
used to exchange binary data which offers description of the data structure and data type
support ASN1 can only be processed and read by parsers due to the binary nature of the
file format Furthermore there is no support for queries in ASN1
The major weakness of open data formats such as XML or JSON is the ability to handle
and support large numeric datasets Large numeric datasets are often found in field models
and represent a critical design decision on how to handle this data There are a number of
file data formats tailored towards numeric representation including Hierarchal Data Format
(HDF) Common Data Format (CDF) and Network Common Data Format (NetCDF)
HDF is an open-source self describing numeric data storage format created by the National
Center of Supercomputing Application (NCSA) The latest HDF version is HDF5
(httpwwwhdfgrouporgHDF5) Like XML HDF5 allows the creation of complex
relationships between data but unlike XML data is stored in binary from and the whole file
does not have to be parsed to access certain elements of the file HDF was created with
large complex esoteric heterogeneous and efficient IO access in mind and this format is
27
employed by numerous scientific organisations to describe numeric data or image sets
HDF consists of hierarchical groups and n-dimensional datasets Each dataset can contain
simple data types such as integer String or float or complex compound data types
Common Data Format12
is a self describing format and software package management
system that is capable of storing scalar or multi-dimensional datasets developed by the
National Space Science Data Center (NSSDC) CDF is essentially a scientific data
management package that allows the user to manage and manipulate the data without
worrying about the lower level machine IO management CDF supports compression and
multiple encoding methods Its data model consists of two basic objects data and data
attributes One major difference between CDF and HDF is CDFrsquos lack of a grouping
mechanism
The Network Common Data format (NetCDF)13
represented a deviation from the CDF
development It is based on the same data model design as CDF but implemented additional
features and is not compatible with CDF format and libraries NetCDF was developed by
the National Center for Atmospheric Research as a set of software management packages
and an independent self-describing data format for storing and sharing scientific data The
latest NetCDF 40 release allows the user to create HDF5 files allowing access to HDF5
features not available in NetCDF including unlimited dimensions and large file size
support
The need for a numeric data format is clear in field representation XML and similar
alternatives are inefficient in storing large numeric datasets Another approach is to adopt a
binary based representation format which requires a library to access and manipulate it
This can be both an advantage and disadvantage as it introduces an extra layer of
abstraction and may add to the complexity of the design however the lower level
implementation between machine and IO is hidden from the user and developer The
current formats all provide a feature rich class of libraries capable of creating editing and
manipulate numeric data A combination of XML and binary numeric data format is an
ideal approach to describing contents that may contain large numeric datasets
12
httpcdfgsfcnasagov 13
httpwwwunidataucaredusoftwarenetcdf
28
22 Tools and techniques
Applications play an important role in computational biology since they facilitate the
creation simulation and understanding of the biological models Most modelling
application tools can be categorised into authoring solver and analysis Authoring tools aid
in the creation manipulation and validation of a model written in a representation language
Even though data formats such as XML are human readable it is often tedious and time
consuming to manually edit and validate models written in these representation languages
by hand Authoring tools play an important role in aiding the user to construct and
comprehend a model In principle a well-defined model can be stored shared andor
solved In this respect there are a number of solver applications which differ in
methodology and scope including ordinary differential equation (ODE) solver as well as
partial differential equation (PDE) solvers for spatial-dependent models Once the model is
solved analysis applications can help in visualising and interpreting the result set
There are some common approaches by CellML FieldML FRL and SBML in the toolsets
which they provide including the provision of an API that can access and write the
respective format Furthermore many projects such as CellML and SBML are comprised of
an active community which provides authoring and visualisation tools These tools play an
important role in the adoption and utilisation of the respective project or representation
language For example CellML provides a range of tools from its internal development
team as well as third party support including editors validation support online repository
code generators simulators and the CellML API package[16]
CellML editors include Cellular Open Resource (COR) [33] and Physiome Cellular
Environment (PCEnv)14
which provide editing and visualisation capabilities Validation
supporting packages ensure that a CellML document is correct in relation to XML syntax
specification rules including units as well as logical relations between different CellML
components Unit correctness is an important aspect of biological modelling especially in
integrative biological models where imported sub models may be composed in different
units Currently there are a number of tools which check for unit correctness in CellML
14
httpwwwcellmlorgtoolspcenv
29
including COR JSim15
PCEnv and PyCML16
[34] These tools vary in their ability to
perform automatic conversions of units they also vary in their capability to generate code
from CellML and perform simulations
The solver application is perhaps one of the more crucial elements of biological modelling
The section below will focus on cell related solvers temporo-spatial solvers and other
solvers that used for biological models
There are two common numeric approaches to solving temporo-spatial models the finite
difference method (FDM) and finite element method (FEM) The finite difference method
is a numeric approach to solving partial differential equations using the mathematical form
of
to approximate derivatives known as finite difference The finite element
method attempts to find an approximate solution to partial differential equations by
breaking up the spatial domain into elements representing piecewise continuous functions
of the dependent variables
With advances in computation and solving methods FEM has become a much more
attractive option in solving over large and complex geometries
COMSOL Multiphysics17
and MSC Patran18
are typical finite element solver software
Each of these applications consists of authoring tools a range of sub solvers and post-
processing analysis components Both of these applications allow the user to input a
geometric model either through CAD-style or boundary modelling The governing PDEs
and boundary conditions are then referenced to the geometric entities which can then be
solved for Both COMSOL and MSC are designed to model across a wide range of
disciplines including electrical physics structural mechanics and chemical domains They
can also be used to solve biological models such as electrical activity of excitable tissues or
mechanical deformation of soft tissues
15
httpwwwphysiomeorgjsim 16
httpschasteediamondoxacukcellml 17
COMSOL Inc Palo Alto CA USA 18
MSC Software Corporation Santa Ana CA - USA
30
There are also a number of free and open source finite element solvers including CMISS19
and Continuity20
CMISS stands for ldquoContinuum Mechanics Image analysis Signal
processing and System Identificationrdquo created by the Bioengineering Institute at the
University of Auckland CMISS is capable of finite element boundary element and
collocation solver techniques targeted towards complex biomedical problems It consists of
a 3D visualisation platform modelling capabilities and remote features allowing it to be run
on high performance computation platforms[15]
Continuity is a finite element solver targeted also toward bioengineering and physiological
problems It was developed by National Biomedical Computation Resource (NBCR) and is
capable of multi-scalar simulations in areas of cardiac biomechanics biotransport and
electrophysiology Similar to CMISS Continuity consists of a visualisation toolset and
client-server backend which allows Continuity to be adopted on high performance
computational platforms Although these finite element solvers do not match some of the
features and tools provided by their commercial counter parts (such as automated mesh-
generation) they are targeted towards bioengineering problems which may be beneficial in
many biological applications
There are a number of freely available tools that target cellular biology including E-Cell
Virtual Cell and Biotapestry which provide sophisticated integrated development
environments to model and solve cellular models with particular reference to
electrophysiological process
The E-Cell21
System is designed to model and simulate a complex system such as a
biological cell [10] It consists of a modelling environment simulation environment and
analysis toolkit The motivation for the development of the E-Cell System is to develop a
framework that is capable to model and simulate based on the complex non-homogenous
nature of a cell ldquorather than emerging complexity from homogeneity and a few principles in
physics and chemistry characterize biologyrdquo The major focus of the E-Cell System is to
develop solver theories and algorithms that are suitable for Cell model simulation
19
httpwwwcmissorg 20
httpwwwcontinuityucsdedu 21
httpwwwe-cellorgecell
31
Similarly Virtual Cell[11 35] is another modelling system for biological cells Unlike E-
Cell it is able to map experimental data to models through spatial mapping Its main
purpose is to refine the initial conditions and governing equations of the model using
experimental data provided Virtual Cell is able to solve or export the mathematical
equations into VCML CellML SBML and Matlab data formats for solving Virtual Cell
data consists of both governing mathematical equations compartment models which
constitute the ldquophysiologicalrdquo aspect of the cell simulator and simulation protocols which
determine what is solved for Although Virtual Cell can export the mathematical data into
CellML or SBML there is no current support for any relational or geometric
interchangeable representation format However Virtual cell can export geometry in STL
or AVS file formats
Biotapestry22
is a genetic regulatory network application platform It provides
functionalities in building visualising and simulating large scale network models A major
focus of this platform is to simplify the complexity in model building and comprehension
by employing a modular modelling architecture BioTapestry represents models in a multi-
level hierarchy The first level is the full genome level that describes all the inputs into a
gene The second level is the ldquoView From All Nucleirdquo which is a subset of the top level
This level allows the top level to be categorized into different regions of behaviours Lastly
the lowest level describes a specific state of the network at a particular time and place
Biotapestry provides support for SBML and is aiming to support 3D models of developing
organisms
Many zero-dimension problems can be solved by mathematical packages that can solve
systems of differential andor algebraic equations Matlab23
and Octave24
are general
purpose packages that can solve a wide variety of mathematical equations and also provide
analysis and scripting environments The main disadvantage of these general purpose
solvers it that they cannot readily be used to solver higher dimensional spatio-temporal
problem
22
httpwwwbiotapestryorgquickStartQuickStarthtml 23
httpwwwmathworkscomproductsmatlab 24
httpwwwgnuorgsoftwareoctave
32
Sundial25
is a solver package ldquowith the goal of providing robust time integrators and
nonlinear solvers that can easily be incorporated into existing simulation codesrdquo It is
intended to solve relatively simple problems on one CPU PETSc26
on the other hand is a
solver library that is designed to solve for more complex mathematical problems performed
on multiple CPU architectures
All the above solvers interact with the user through a programming interface Many solvers
provide their own scripting languages which allow the user to directly program the
mathematical problems into the solver
There are a wide range of post processing applications available that can help analyse
simulation results These range from complex visualisation packages to simple statistical
analysis and graphing software Many commercial finite element solvers provide their own
analysis toolset A few notable visualisation packages include CMGui27
Amira
Visualisation tool28
and Visiome29
which can display the result of the simulation visually as
colour gradients over the geometric representation
Other analysis tools include the CellML parameter optimization software developed at the
Graduate School for Biomedical Engineering University of New South Wales[12] for
fitting action potential waveforms to CellML electrophysiological models
25
httpscomputationllnlgovcascsundialsmainhtml 26
httpwwwmcsanlgovpetscpetsc-as 27
httpwwwcmissorgcmgui 28
httpwwwamiraviscom 29
httpsourceforgenetprojectsvisiome
33
Chapter 3 Modelling Markup Languages (MML)
Specification
31 Introduction
The biological modelling framework developed in this thesis attempts to provide a
temporo-spatial modelling structure that consists of modelling markup languages (MML)
comprised of ModelML and FML as well as supporting applications for the creation
manipulation and visualisation of the models and utility parsing and solver support for
tissue electrophysiology problems ModelML is used to describe relational information
between different sources of data while FML is used for field information of a biological
model The main purpose of this framework is to provide a set of specifications to facilitate
the representation exchange and reusability of model components over the internet
Models constructed using the MML Framework can then be imported to numeric solvers to
generate model simulations The MML approach is focused on organ-level modelling that
can take cellular ODE models described in CellML and span these across different spatial
or temporal scales using ModelML and FML
This chapter will outline the design and implementation of the ModelML and FML
representation languages and how these languages can be applied to certain scope of
integrative biological modelling
34
32 The Modelling Markup Languages (MML)
321 Overview
The primary aim of the Modelling Markup Languages is to provide a set of interchangeable
representation format to describe an organ level temporo-spatial model To achieve this a
number of components in this framework have to be designed and implemented including
the representation language and supporting applications that will facilitate the use of these
languages
The MML Framework can be separated into two different layers as shown in Figure 3-1
the application layer and the data layer The application layer consists of the solver MML
parser and application The purpose of this layer is to aid in the creation and solving of the
MML models
Solver
Application amp Libraries
ParserAPI
FMLCellML
Application Layer
Data Layer
ModelML
Figure 3-1 The MML framework is separated into application and data layers The application layer
consists of Solvers general applications and API while the data layer consists of ModelML CellML
and FML
To solve an MML model a solver is required typically an independent solver application
such as COMSOL Multiphysics To convert the MML model into a solvable form a parser
program is required to read the MML model and convert it into a readable script of the
specific solver
35
Mathematics
Groupings
Subdomain Boundary
ModelML
CellML FML
Figure 3-2 The ModelML language is responsible for handling relational data that is primarily focused
on mapping geometric data from FML to mathematical model from CellML
The applications range from support utilities which import or export MML models to
authoring tools that aid in the creation or manipulation of MML models It is important to
develop a set of core support and authoring applications that will enable MML models to be
created and solved
The Data layer in the MML Framework consists of ModelML FML and CellML to create
a biological model which maps cellular models onto the spatial domain The model
information is delegated into the following components
FML (Field Markup Language) is a possible substitute for the currently undefined
FieldML[27] which would contain field information A field is defined as a physical
property that varies over space and possibly time It is usually described in terms of
tensor vector or scalar quantities and can range from global model geometry information
through to spatially-varying tissue properties such as cellular parameters
The primary purpose of ModelML is to describe the relational information of multi-scale
models as shown in Figure 3-2 specifically the relationship between CellML and FML
This setup allows governing mathematical equations and information to be associated with
36
field data Furthermore ModelML is responsible for mapping variables between different
CellML or FML documents This allows different CellML or FML documents to be used
together to create a temporo-spatial model In addition ModelML contains metadata for the
general model description and application solver setup if desired
Both ModelML and FML share a common syntax subset responsible for handling import
and handling of external documents metadata descriptions and general mathematical object
declarations The use of common syntax simplifies the design and usage of these languages
The MML specification is built around modularity which separates relational and overall
construct information cellular models and field or geometric models into separate
components This encourages cellular models and field or geometric models to be reused
resulting in the more efficient construction of temporo-spatial models more quickly and
efficiently The MML specifications are designed with interoperability with CellML in
mind including reuse of units and metadata Furthermore FML and ModelML adopt
common standards such as MathML[21] to describe mathematical content This simplifies
the interchangeable characteristics of MML where common standards with already
available tools can be used to simplify development and adoption of the MML
specification
322 Common MML specification
The MML framework is a multi-component language and tool each component performs a
specific function However due to the close interactions between the languages a common
set of specifications is required to ensure implementation and usage
Both ModelML and FML are built on the same abstract class which share similar
properties As such they will share some common syntax including the import branch and
declaration branch as well as metadata support The import branch provides syntax which
allows the local document to import and access external models this approach allows
CellML interaction and the breaking up of large complex models into simpler and more
manageable components The declaration branch provides the facility to declare
independent mathematical objects and units with these declarations used locally or
externally through the use of import Metadata provides annotation support for the
37
specification it allows the author to provide extra information about the data within the
documents This component is particularly important for internet storage search and
transfer
The MML framework also attempts to adapt common features of CellML such as units and
the metadata specification to simplify application development and interaction and also
decrease the complexity of the overall framework
323 ModelML
The MML framework is built around the interaction between different specifications which
describe biological models To achieve this a mechanism is required to link and group the
different groups of information together and provide an interface to attach additional
information to this relationship Furthermore ModelML has to map variables between
different documents together This may include dependent and independent variables for
PDEODE systems or spatial variables from geometric descriptions into cellular models
This task is left to ModelML as shown in Figure 3-3
Figure 3-3 ModelML is responsible for importing external models and provide variable and relation
mappings between these external models
38
The main purpose of ModelML is to encapsulate data that describes the relational
information of a biological model construct and describe the mathematical system and
variable mappings As such ModelML will be required to import external CellML models
and map the mathematical models onto spatial domains described in FML It will provide
the naming and the path identifier of objects between different models ModelML will also
be required to organise the mathematical structure of any imported mathematical models
This is necessary since the naming or the equation systems may not be compatible
ModelML provides facilities to organise naming and equations to ensure operability
between different imported CellML models
There are two main components in the ModelML specification the grouping branch and
the system branch The grouping branch is where relational declaration occurs It is where
mathematical objects are linked to geometric objects and facilities provided to attach
additional information to these links For example when mapping an ODE model that
describes membrane voltage onto a geometric surface additional information can be
attached such as membrane conductivity values or an external current stimulus to the
particular geometric regions
The System branch describes the overall mathematical structure and important variables of
the temporo-spatial model This branch allows different CellML models using different
variable names to work together The system branch allows naming changes to CellML
models and grouping of different ODEs from CellML models into alternative ODE
systems The System branch is also used to map spatial variables from FML into the
ModelML namespace or CellML documents This branch is used by the parsing application
to determine how the overall model is constructed and solved
The document import or mathematical object declaration is handled by the MML import
and MML declaration branch respectively In addition to the Metadata specification from
the common syntax specification ModelML also has a Protocol metadata branch Protocol
is used to describe information related to the solver application such as the default solver
for this model or other solver application dependent information Protocol is completely
39
optional and is intended only as a means to ease the conversion between the XML
documents to solvable format
In summary ModelML will provide the following functionality
- Import and use CellML and FML models
- Provide facilities to manipulate or invoke external models in different forms
- Encapsulate relational information of biological models between the spatial
and mathematical equation domains
- Contain mathematical information not found in either CellML or FML
- Provide solver metadata information
- Overall mathematical or variable mapping information
324 FML
A field can be described as the spatial variation of a physical quantity assigned to points in
space A field can be used to describe a geometric object or spatially-varying attributes
such as pressure temperature or stress In the MML framework biological modelling data
are delegated into mathematical models field models and relational models FML is tasked
with describing field models
FML was designed to describe field information there are two types of field data that can
be stored Generally FML is used to describe geometric models and provide naming
mechanisms that will allow ModelML or other FML documents to import or access data
within the model FML can also be used to describe attributes of regions within FML This
can be used for visualisation storing result sets or describing additional field information
within the geometric model
40
Figure 3-4 Each FML model contains a frame of reference object A frame describes the dimensional
property and encapsulates the field information (geometric representation method and cell objects)
that exists within this frame
FML is constructed using frames and cells as shown in Figure 3-4 A frame of reference is
a space wherein cells can reside A cell is a predefined topology with a list of coordinates
and optional attributes A cell can be a point line or curve or it can be a user defined
interpolation function A cell can be used to describe a geometric object by geometric
modelling methods such as surface boundary or mesh modelling A cell can also be used
to define a region of space and have attributes attached to it to describe addition field
properties such as temperature voltage etc
FML provides a number of different geometric modelling methods to allow the user
flexibility in the way the model can be described An important feature of FML is to allow
41
user defined interpolation function declarations in MathML These functions can be used to
describe curves or surfaces with a list of supplied points
FML is a combination of the XML and HDF5 specification Field data by nature are
typically large numeric datasets not well suited for storage within XML Although field
information can be solely stored within XML FML allows numeric datasets to be stored in
external HDF5 documents with all naming mechanism and topological information stored
within XML document
In summary the goal of the FML specification is to
- Describe geometric information
- Describe field attribute information
- Provide spatial dimension information
325 CellML
CellML[19] is a general XML-based descriptive standard It can be used to describe any
systems model and is not limited only to cellular models It describes the model structure
mathematical information and metadata CellML also employs other XML standards such
as RDF[36] XLink[37] and MathML[21] ensuring a wider range of support tools
available
CellML (Figure 3-5) consists of basic entities called components these components
encapsulate mathematical information including variables and equations through MathML
syntax Components in CellML are inter-connected they interact with each other through
the connection entities that are defined within the CellML document CellML also consist
of a complete set of metadata specification and units support The CellML representation
language employs the object orientation concept of reusability and inheritance through
encapsulation and import entities within its framework[8]
42
Figure 3-5 The CellML specification contains a number of different objects including units
components which consist of variable and equations connections and grouping CellML also contains a
separate metadata specification
The advantage of using CellML in conjunction with the MML framework is the maturity of
the specification and its capability to describe cellular models[38] as well as the active
development by the CellML community to include a wide range of tools and applications
available for use The CellML website30
also contains a repository31
[39] with over 400
curated[20] models available for use and testing The curation of CellML documents is
categorised into four stages 1) not curated 2) consistency with original journal paper 3)
mathematical correctness and ability to be run in an appropriate simulation environment
which produces the correct results and 4) satisfaction of physical constraints such as law of
charge conservation etc The availability of curated models allows the construction of
MML models easier Furthermore constructing new CellML documents is simplified with
the tools and applications made available in this thesis
30
httpwwwcellmlorg 31
httpmodelscellmlorg
43
33 General MML usage and definitions
A number of features are shared across FML and ModelML These include how multiple
tags of the same name are stored how units are described and how units and metadata are
set up
331 UML modelling
Unified Modelling Language (UML) is used to provide a class diagram representation of
the XML specifications in MML This allows the ready display of relationships and
conceptual classes in the MML framework
An XML element can be modelled as a class object In UML a class is represented by the
following diagram
Class1
There are two types of relationship that are modelled using UML generalisation and
composition The generalisation relationship shows that the one class is a specialized class
of the other For example if People is modelled as a class this class can be inherited or
generalised by a sub-class Student thus creating a parent child relationship The parent is
known as the supertype or super class and the child as the subtype or sub class In UML
the generalisation relationship is represented by a white triangle on the end of super class
line
People Student
The composition relationship describes a ldquohas ardquo relationship between two classes In the
example below the UML diagram indicates that a Plane can have zero or more Engines
This relationship is used to represent XML elements and the relationship between its child
44
elements A composition is represented by a black diamond at the end of the line point to
the container class
Plane Engine
332 MML objects overview
Most syntax in MML (FML ModelML documents and Common syntax such as the
Declaration or Import branches) is considered to be a generalisation of an abstract ldquoMML
Objectrdquo as shown in Figure 3-6 These objects share similar properties such as the ability
to contain ltannotationgt or ltprotocolgt elements
MML Object
ltannotationgt
ltprotocolgt
1
1
ModelML Object FML Objects Common Syntax Objects
Figure 3-6 FML and ModelML syntaxes are derived from an abstract MML object class
representation The MML object may contain annotation to describe metadata and protocol to describe
application specific metadata
333 MML namespace scope and object naming
Every identifiable object in an MML document must have a unique string identifier within
its own namespace The string identifier must contain only word characters including
alphanumeric and underscores ([A-Za-z0-9_] in regexp)
45
A namespace scope can be considered as a container where child objects declared within
share a common namespace and can be referenced A namespace may contain child
namespace scopes the child scope can see the parent objects but details are hidden from
objects in the parent level Multiple namespaces generally exist in MML models (master
documents and imported documents) The namespace mechanism allows objects to be
referenced from external sources without name collisions
Common Namespaces includes
- MML root objects (local name space)
o Named Objects
- Imported objects
A uniquely identifiable object allows it to be referenced by other MML objects (if rules
permit) A referenced object reflects all the properties of the original object A named
object is declared through the attribute name with a legal unique identifier A referencing
object declares an attribute ref that points to an existing identifier in a reachable
namespace
ltmml_object name=rdquoobj1rdquogt hellip hellip ltmml_object ref=rdquoobj1rdquogt
Namespace scopes are hierarchical in terms of levels such that object identification always
starts at the lowest level (local scope) and proceeds to the higher level scopes until the
object referenced is found Generally the XML document itself is considered to be a local
namespace scope but within that document certain XML elements may declare new
objects as its own namespace these objects are only visible and accessible to itself unless
otherwise specified Objects within its own namespace may reference each other directly by
its unique identifier
MML Reference Object Name
46
External namespaces have their own unique identifier These namespace identifiers are
declared by the main XML document (ie ltimportgt declarations) To reference an object
from another name scope a path system similar to XPath is used In the MML path system
MML Reference (namespace identifier)(object name)
Because of the network nature of CellML components the namespace does not apply to
CellML To reference a variable or equation from a CellML document the following
method is used
CellML Reference (namespace identifier)(Component Name)(object name)
The name space mechanism allows local and external objects to be referenced and reused in
the local document This encourages reusability and grouping of common data into
individual documents allows the ability to import external documents such as MML and
CellML
334 List containers
Groups of the same XML tags are often encapsulated under a common list tag These list
tags are generally named as lttag_listgt where tag is the child tag name
ltbezier_curve_listgt ltbezier_curvegt ltbezier_curvegt ltbezier_curve_listgt
By encapsulating XML elements with the same name or logical property under one
common parent allows easier readability but also searching and categorisation
functionality A similar approach was adopted by the SBML[7] specification
335 Units
Units will be described using the CellML 10+ specification They are declared under the
declaration branch and are referenced by the attribute ldquounitrdquo
ltunits name = ldquocelcius_per_metrerdquogt
ltunit units = ldquocelciusrdquo gt
ltunit units = ldquometrerdquo exponent = ldquo-1rdquo gt
ltunitsgt
47
CellML allows the reference of SI units (described in Table 3-1) without explicitly
declaring the ltunitgt object Users however can define their own unit types with the unit
tag Newly created units may require the use of some of these optional attributes offset
prefix exponent and multiplier The offset attribute is used to define a constant for the
conversion between two units It is only necessary in cases similar to converting Fahrenheit
and Celsius where the constant 320 is needed The default value for offset is 00 The
prefix attribute pre-multiplies the unit with the defined value it is generally used for
defining a new unit that is an SI scale factor of another already defined unit The default
value for the prefix is 0 The exponent attribute raises the unitrsquos value to a power equal to
the value of the exponent attribute which must be a floating point number Its default value
is 0 The multiplier attribute is used to pre-multiply the quantity to be converted by any real
scale factor The default value is 10
ampere farad katal lux pascal tesla
becquerel gram kelvin meter radian volt
candela gray kilogram metre second watt
Celsius henry liter mole simens weber
coulomb hertz litre newton sievert dimensionless
joule lumen ohm steradian
Table 3-1 Supported SI units in CellML Specification 11
Units play a crucial role in ensuring model correctness Different biological models can be
created in different units even though they may describe the same phenomena A modelrsquos
equation can be unit equivalent but not unit equal Unit equivalence refers to cases where
the units (SI) are the same but the ratio factor between the standard units is different This is
especially important in integrative biological modelling where a model can be made up of
different models with different unit scales Incorporating unit support ensures that units
48
between different documents can be tracked and validated If appropriate the application
layer could use the unit information and convert the biological model to ensure unit
correctness
49
336 MML metadata support
The general definition of Metadata is defined as data about data Metadata is used to
provide additional information about the resource such as name date or description In
CellML and MML this represents a very powerful and convenient utility By providing
metadata information about the model contained within the XML document it allows the
ability to categorise search and track changes to these documents
CellML metadata are described using existing standards wherever possible These public
standards includes Resource Description Framework (RDF)[40] Dublin Core[41-42]
vCard[43] and BQS CellML also includes a set of its own metadata elements[44]
The Resource Description Framework is a W3C specification designed to handle metadata
for the World Wide Web RDF itself does not provide the mechanism to describe metadata
but a framework on how the metadata can be stored known as the subject-predicate-object
expression or ldquotriplerdquo in RDF terminology RDF allows metadata to be stored in a number
of different ways however to ensure consistency the CellML specification has set out one
way to describe metadata using the RDF framework
The Dublin Core is a metadata element set consisting of standardised identifiers which
allows resources to be more easily searched across different domains such as the World
Wide Web The Dublin Core is widely used to describe online media such as video audio
or composite media defined by International Organisation for Standardization in 2003 as
ISO Standard 15836 and NISO Standard Z3985-2007 The major advantage of using the
Dublin Core is the widely accepted identifiers which allow easier integration of tools
In CellML information about people is stored using the vCard specification vCard was
originally suggested on a note created by Renato Iannella from the Distributed Systems
Technology Center at University of Queensland vCard was used by CellML primarily
because during that time it was the only RDF definition to describe people This no longer
the case with alternatives including ldquoFriend of a Friendrdquo (FOAF) specification used to
describe people their interest and interconnection using RDFXML
The MML metadata framework will closely follow the approach of CellML to ensure
interoperability (described in Table 3-2) However new existing standards will be
50
introduced to provide a much more powerful descriptive framework The MML metadata
specification will also introduce its own subset metadata elements to describe specific
information relevant to ModelML and FML
Namespace Name Namespace URI Recommended Prefix
CellML Metadata httpwwwcellmlorgmetadata10 cmeta
RDF httpwwww3org19990222-rdf-
syntax-ns
rdf
RDF Schema httpwwww3org200001rdf-schema rdfs
Dublin Core httppurlorgdcelements11 dc
DC Qualifiers httppurlorgdcterms dcterms
vCard httpwwww3org2--1vcard-rdf30 vCard
BQS httpwwwcellmlorgbqs10 bqs
New Specifications
MML Metadata mmlmeta
Table 3-2 Existing CellML metadata support and proposed MML metadata syntax
MML metadata usage
Metadata are encapsulated within the ltannotationgt element where ltannotationgt
elements are a child to all MML objects In general it is recommended to use the Resource
Description Framework to construct the metadata information however it is possible to
insert other metadata specifications within annotation This section will provide the
recommended method on how metadata should be constructed using RDF
RDF metadata information can be declared within the parent ltrdfRDFgt tag as suggested
by the CellML metadata specification However from the 2004 RDF specification the
omission of the ltrdfRDFgt element is allowed as long as the description can be described
51
by one outer node It is recommended that a namespace be included in all metadata
elements as a number of different specifications are used Each ltrdfRDFgt or parent
element contains one or more ltrdfDescriptiongt elements which describes one particular
metadata section Each ltrdfDescriptiongt must declare the attribute rdfabout with a valid
URI that points to a valid XML element
ltrdfRDF xmlnsrdf=rdquohttpwwww3org19990222-rdf-syntax-nsrdquogt ltrdfDescription rdfabout=rdquoelement_idrdquogt ltrdfDescriptiongt ltrdfRDFgt
Metadata that can be inserted includes authors and contributors modification histories
annotations and descriptions that are outlined in the CellML metadata specification
The MML framework introduces document metadata which that describes the main
information regarding MML content The purpose of document description metadata is to
provide a central structure to describe information about the current document including
the name date created authors description web resources modification and comment list
This metadata information is stored in the element ltmmlmetadocumentgt tag as described
in the code listing below
ltmmlmetadocumentgt ltmmlmetanamegtModel nameltmmlmetanamegt ltmmlmetadescriptiongt description of the projectltmmlmetadescriptiongt ltmmlmetacreatedgt1142000ltmmlmetacreatedgt ltmmlmetaweb_resourcegt lthomepage rdfresouce=httpegcomgt ltemail rdfresource=teamteamcomgt ltwiki rdfresouce=httpegcomgt ltrepository rdfresouce=httpegcomgt ltdownload_page rdfresouce=httpegcomgt ltmmlmetaweb_resourcegt ltmmlmetaauthor_listgt ltvCardNgtltvCardNgt ltvCardNgtltvCardNgt ltmmlmetaauthor_listgt ltmmlmetacontributor_listgt ltvCardNgtltvCardNgt ltvCardNgtltvCardNgt
52
ltmmlmetacontributor_listgt ltmmlmetaresultsgt ltmmlmetaresultsgt ltmmlmetaweb_resourcegt ltmmlmetaweb_resourcegt ltmmlmetacomment_listgt ltmmlmetacomment_listgt ltmmlmetaresultsgt ltmmlmetaresultsgt ltmmlmetamodification_listgt ltmmlmetamodification_listgt ltmmlmetacomment_listgt ltmmlmetacomment_listgt ltmmlmetacategory_listgt ltmmlmetacategory uri=identifiergt ltmmlmetacategory uri=identifiergt ltmmlmetacategorygt ltmmlmetacategory_listgt ltmmlmetadocumentgt
53
337 MathML
Mathematical Markup language[21] is a product of the W3C Mathematical Working
Group and is intended to provide a framework to describe mathematics for machine to
machine communication The current specification stands at 2032
with an upcoming 3033
draft available
The primary objective of MathML is to describe both the presentation of a mathematical
notation and the content of the mathematical idea that it represents As such MathML has
two set of tags to describe mathematic formulation Content and Presentation markup
syntax
MathML presentation markup contains up to 30 elements which describe the layout of
mathematical expressions The layout syntax can be classified into scripts general layout
such as row style or fractions and tables MathML content markup consists of more than
120 elements including operators relations and named functions The main purpose of the
content markup is to describe the meaning of the mathematical expression
Like CellML the MML framework will primarily use content markup that will capture the
meaning of the formulation MML will also use limited presentation markup language to
describe tensor Mathematical expressions in MathML are stored as tree data structures
where the nodes correspond to MathML elements and the leaf represents an operator or
content such as a number or character An import element used in content markup is the
ltapplygt element which describes a function or operation and its corresponding
arguments
ltapplygt ltop or functiongt ltargumentgt ltargumentgt ltapplygt
32
httpwwww3orgTRMathML2 33
httpwwww3orgTRMathML3
54
The positions of the child elements of ltapplygt designate the arguments and operation or
function where the first child is the operation or function followed by the arguments The
operation and functions can be classified into unary binary or n-ary type and signifies the
number of arguments each operation or function can take
For example a+b+c-d can be represented by
ltapplygt ltapplygt ltminusgt ltapplygt ltplusgt ltcigtaltcigt ltcigtbltcigt ltcigtcltcigt ltapplygt ltcigtdltcigt ltapplygt ltapplygt
MathML and MML framework
All MathML syntax declared within MML documents must be encapsulated within the
ltmathmlmathgt element unless the child objects of a parent element contains only
MathML syntax Within CellML there exists a subset of MathML elements that is
expected to be supported by parsing applications This approach was taken due to the large
library of MathML content elements and the likelihood that most parsing applications
would not be able to support all the content markup elements MML will follow a similar
approach to CellML (described in Table 3-3) by designating a similar MathML subset that
will describe the general simple ODE nature of MML documents
55
Token Elements ltcngtltcigt
Basic Content
Element
ltapplygtltpiecewisegtltpiecegtltotherwisegt
Relational
Operators
lteqgtltneqgtltgtgtltltgtltgeqgtltleqgt
Arithmetic
Operators
ltplusgtltminusgtlttimesgtltdividegtltpowergtltrootgtltabsgtltexpgtltln
gtltloggtltfloorgtltceilinggt
ltfactorialgtltlogbasegt
Logical Operators ltandgtltorgtltxorgtltnotgt
Calculus ltdiffgtltdegreegtltbvargt
Constants truegt ltfalsegt ltnotanumbergt ltpigt ltinfinitygt ltexponentialegt
Semantic and
Annotations
ltsemanticsgt ltannotationgt ltannotation-xmlgt
Table 3-3 MathML subset supported from the CellML Specification
Employing a standardised mathematical representation language provides a number
advantages including commonality with other representation languages such as CellML or
SBML MathML is a widely adopted language to describe mathematical content used on
the web and other applications[45-47] Its use minimises development issues such reusing
existing tools to parse MathML content Furthermore employing a standardised language
will not force third party developers to adopt or choose a new paradigm for describing
mathematical content A disadvantage of MathML is the verbose nature that is inherited
from the XML A more efficient mechanism is to employ string based mathematical
representations such as Matlab34
syntax However this introduces another level of
development complexity as an extra parser has to be introduced to parse this content which
34
The Mathworks Inc
56
does not fit with the nature of XML representation In addition the Matlab syntax itself is
not well equipped to represent complex mathematical expressions or higher order functions
As such the inability to represent complex mathematical expressions outweighs the size
efficiency it may possess
57
34 HDF5
One of the disadvantages of XML is the overhead in describing large amounts of numeric
data To overcome this the MML framework allows numeric data to be stored in HDF5
format for objects declared in ModelML or FML documents a The naming mechanism is
retained by the parent XML referencing document
341 Hierarchical Data Format (HDF) overview
The Hierarchical Data Format35
was created by the National Center for Supercomputing
Applications (NCSA) to describe graphical and numeric data HDF consists of an abstract
data model and storage model and libraries which implement the abstract models to
different types of storage mechanisms
The HDF abstract model is a device and programming language independent conceptual
model used to describe complex data data types and grouping methods The key concepts
for are
- Groups A collection of groups or objects
- Datasets A multidimensional data array which may include attributes and
metadata
- Datatype A description of a data element
- Dataspace A description of a dimension in a multidimensional dataset
- Attribute A named data value associated with groups dataset or named
datatype
Groups
HDF is a hierarchical format composed of groups and objects A group object is a container
that may contain zero or more objects Each object must belong to at least one group with
the exception of the root folder The root container is identified by ldquordquo and is automatically
created with the creation of the HDF5 file
In HDF5 objects or groups can be identified by their path names A path name is a series of
component names separated by ldquordquo where the component name is a hard or soft link to an
35
httpwwwhdfgrouporgHDF5
58
object The path name signifies the hierarchical nature and component route to the desired
object or group from the root For example the following paths can be used to describe the
relationship between components shown in Figure 3-7
- GroupADataset1
- GroupAGroupBGroupCDataset1
Figure 3-7 HDF5 structure layout example (From HDF5 Manual36
)
36
httpwwwhdfgrouporgHDF5docUG
59
Datasets
Figure 3-8 HDF5 dataset layout example (From HDF5 manual)
A dataset is a collection of data elements and associated metadata including attributes as
shown in Figure 3-8 data type and data space information The data can be stored in a
multidimensional array (gt= 1) with data types including String integer Float Reference
or Compound data type This allows a dataset to be composed of simple primitive data
types through to more complex compounded data composed of several primitive data
types
342 HDF5 in MML framework
HDF5 files are used for numeric storage to complement the MML specifications It is
primarily used by FML and the declaration branch to describe numeric datasets Numeric
data are categorised into five primary groups as shown in Figure 3-9 This layout and the
following figures represent the mandatory grouping hierarchy for the HDF5 MML format
60
Root
Cells Mesh DataAttributes Others
Figure 3-9 The HDF5 MML file format group hierarchy layout The root consists of 5 possible groups
cells mesh attributes data and others
- Cells
- Dim0
- Dim1
- Dim2
- Dim3
- Mesh
- vertex_list
- edge_list
- face_list
- element_list
- Data
- Attributes
- Other
Cells contain information related to geometric field objects each cell class is contained
within its own group named after the class id as shown in Figure 3-10
61
Cells
dim0 dim1 dim2 dim3
pt_list Class_list
Global
Coordinate
Dataset
Global
Coordinate
Dataset
Or
Reference
Dataset
Indexed Member
Groups
Attribute
DatasetOther Datasets
Class_list
Indexed Member
Groups
Attribute
DatasetOther Datasets
Coordinate
Dataset
Or
Reference
Dataset
Figure 3-10 The cell sub-group HDF5 layout Groups are represented with a rectangle and Datasets
are shown as rectangles with curved edges
Cell Information can be stored in a number of ways the simplest being is to use a global
data set for simple primitives such as point lines triangle etc This data set can describe
coordinates or table of point index references (CoordinateDS or ReferenceDS) as shown
in Figure 3-10 on the left branch If additional information is to be attached to the global
table member groups can be created with additional metadata inserted into it These
member groups must be indexed to the owner in the position of the global dataset table this
is done by naming these member groups using the index of the owner as shown in the
central dim1 branch in Figure 3-10 The third method consists of no global datasets
Members of their cell class are contained within its own indexed member group Each
group must contain a coordinate parameter or reference dataset Any other metadata
datasets can be inserted into its own group This method is useful for more complex cells
that can be parameterized in various ways
In general to reference elements of a Cells branch from FML the internal HDF5 path may
be used up to the Class_list level Mapping between individual objects from FML to HDF5
Cells elements must use the index system attached to the HDF5 path system ie
cellsdim1bezier_curve[index] More detailed information can be found in the FML HDF5
section (Page 118)
62
Mesh
Vertex list Edge list Face list Element list
Class Name
Coordinate
Dataset
Or
Reference
Dataset
Attribute
Reference
Dataset
Other Datasets
Figure 3-11 The Mesh sub-group HDF5 layout Groups are represented with a rectangle and Datasets
are shown as rectangles with curved edges
The Mesh group contains element information on how the mesh is constructed as shown in
Figure 3-11 These include class identification reference table domain table topological
and element parameter information placed if necessary in the datasets named
ldquoReferenceDSrdquo ldquoDomainDSrdquo ldquoTopologyDSrdquo and ldquoParameterDSrdquo respectively in their
appropriate group Mesh point coordinates are stored in the cell groups the reference
information is stored according to the dimension and element class id within the mesh
group hierarchy For example a 2D mesh object is described using point coordinates with
vertex line and quadrilateral elements As such the following groups are created to store
the reference index table topology information and parameter table if necessary
- meshdim0vertex
- meshdim1line
- meshdim2quadrilateral
Mesh elements from HDF5 may be referenced using the index attached to the HDF5 path
according to their position of itself in the coordinate or reference dataset ie
meshdim0vertex[index]
63
Other miscellaneous groups in HDF5 include data attributes and other The data group
contains data arrays which can be referenced by ltdatagt elements found in the declaration
branch The attribute group contains attribute information which are typically scalar
vector or of matrix forms These can be stored as 2D 3D and 4D arrays within HDF5
Other datasets that cannot be categorised into attribute or data can be stored within the
ldquootherrdquo group All datasets here are literally named and references from MML documents
are carried out by using the HDF5 path to the relevant datasets
Referencing elements from HDF5 to MML is carried out by encapsulating the path of the
HDF5 structure and relevant index if applicable to the attribute ldquoext_srcrdquo from the desired
XML element
ltimport xlink=rdquohdf5h5rdquo name=rdquoh5rdquogt hellip ltcell ext_src=rdquoh5cellsdim1bezier_curvebc1rdquogt
The HDF5 data format provides a rich and powerful library and an efficient format to store
numeric data[48-49] Grouping and path mechanisms are ideally suited to the MML
framework The grouping mechanism allows contents to be organised similarly to the XML
allowing contents to be mapped more easily from HDF5 to XML Furthermore the naming
mechanism used by HDF5 can be used by the MML path system due to their similar nature
This allows internal HDF5 objects to be referenced from the XML source The HDF5
software library provides a rich set of read and write methods including compression
capability and reading segments of the dataset efficiently All numeric data in the HDF5
files are stored as an ordered n-dimensional array dataset using the float data-type The
number of numeric values per element of the array is dependent on the object it represents
as specified in the MML specification available online (71Appendix C) (ie a point object
can have up to 3 numeric entries depending on the spatial coordinate As such the dataset
will have a size of n by d where n is the number of point and d is the spatial dimension)
64
35 MML import mechanism
351 Import overview
The MML framework is centred on modularity An important aspect of this design is the
ability to reference other documents and access the contents of that document with as little
coupling as possible to the syntax of the referenced document The Import branch is part of
the Common syntax library that is accessible for both ModelML and FML It is intended to
fill the role of an interface between different documents
The Import branch allows documents to reuse other pre-existing documents Current types
of documents that can be imported are CellML ModelML FML and HDF5 formats Each
import declaration must be accompanied by a unique identifier from within the importing
document To reference an object from the external document the unique identifiers along
with the external object name will constitute a legal path name for referencing
352 ltimportgt
An external document may be imported using the ltimportgt tag An ltimportgt tag must
declare the attribute ldquonamerdquo with a legal universal resource identifier and a valid ldquoxlinkrdquo
attribute specifying the path to this document The ltimportgt element is an interface to the
content of the external document The path to the objects in the external document is
constructed from the identifier of the import element rather than the paths of the object
within the external document In general the local namespace objects of the external MML
document are visible from the import interface Non-MML documents require manual
declaration of what is visible or accessible within the ltimportgt element
ltimport name=rdquogeometryrdquo xlink=rdquocgeometryfmlrdquo type=rdquofmlrdquogt hellip hellip ltedge ref=rdquogeometrybezier_curve3rdquogt
The Import element also provides facilities to override or append additional information to
the imported document at the local scope such as overriding variable values substituting
65
variables with expressions or appending additional state variables These changes are only
visible through referencing the ltimportgt object An external document may be imported
several times with different manipulations under each ltimportgt element
This section will explain the rules on how to import certain document formats Specific
details can be found in the formatrsquos own relevant sections
Accessing variables or objects
Variables equations or other objects can be declared within the Import element which will
allow these objects to be used in the local namespace as string references rather than data
references A string reference is generally found in ltcigt elements in MathML The parsing
application will identify these objects at the local namespace map them back to the import
parameter or document and use the values found there This is primarily used for CellML
documents to allow variables or equations to be referenced from MML documents using
ltimport_variablegt and ltimport_equationgt
Importing ModelML documents
A possible approach to importing ModelML is to create a common library of functions
expressions variables or units declarations that can be used by other ModelML documents
This would simplify implementation and error checking and is equally applicable to
declarations from FML documents
ModelML provides a mechanism to import and create variations of that document The
ltinterfacegt and ltimplementationgt tags allow subtle variations of a master model to be
created by changing a few of the variables or equations from smaller external documents
The master model may declare the ltinterfacegt branch allowing other models to know
which variables they may overwrite The ltinterfacegt declaration does not change the
parsing nature of the model it is only recognized by the parsing application when the
ltimplementgt elements from the variation models are parsed and mapped to the master
model
66
The ltimplementgt branch simply contains the overriding information about variables or
equations This allows variations of the master model to be created without duplicate data
that spans across the variation models
Master Model Template Code
ltmodelmlgt ltinterfacegt ltvariable ref=var1gt ltvariable ref=var2gt ltequation ref=xxxgt Offer an overriding Math Expression ltinterfacegt
hellip
ltmodelmlgt
Variation Model Template Code
ltmodelmlgt ltimport_listgt ltimport name=zzz xlink=maaaxml type=ModelMLgt ltimplementgt ltvariable ref=var1 value=42131gt ltvariable ref=var2 value=4132gt ltequation ref=xxxgt lt-- Declaration Style equation declaration --gt ltequationgt ltimplementgt ltimportgt ltimport_listgt
ltmodelmlgt
Importing CellML documents
CellML documents are generally imported by ModelML documents and contain the
governing mathematical models used by ModelML ltdependentgt and ltindependentgt
variables must be declared as the child of the import element Additional parameter and
variable substitutions are allowed from the importing scope Because of the hierarchical
67
nature of the CellML document access to specific variables must be declared and by
default all variables and equations are non-accessible from the imported document
Parameter values are inserted using ltparametergt provided the correct path to the object
within the CellML document is given using the attribute ldquonamerdquo
The CellML import interface provides a few overriding capabilities to the imported CellML
document including the insertion of substitute variables or expressions This is achieved by
declaring the new variables and expressions within the child of a referenced CellML object
within the import object using ltdependent_variablegt ltimport_equationgt or
ltimport_variablegt
Example 1
ltimport name=rdquouniqueIDrdquo xlink=rdquocdocumentcmlrdquo type=rdquoCellMLrdquogt ltimport_variable ref=componentvar1 local_name=xxxxgt ltimport_equation ref=componentid local_name=yyyygt
ltimportgt
Example 2
ltimport name=rdquouniqueIDrdquo xlink=rdquocdocumentcmlrdquo type=rdquoCellMLrdquogt ltdependent_variable name=rdquocomponentxrdquogt lt--Subtitution example--gt
ltdependent_variable name=rdquocomponentxrdquogt ltvariable name=rdquooverriderdquogt ltmathmlgt ltdepenedent_variablegt
ltindepenet_Variable name=rdquocomponenttrdquogt ltparameter name=rdquocomponentsrdquo value=rdquo22gt ltimportgt
It should be noted that this mechanism is intended to create slight variations of the original
document to encourage reusability and efficiency However considerable modifications of
CellML documents should reside in a new CellML document itself A potential
disadvantage of this approach is that this method may circumvent the CellML checking and
validation process and tools A solution to this problem is to create a temporary CellML
68
model which contains a modified original model with the MML modifications such that
standard CellML checking and validation processes may be employed
Importing FML documents
FML documents can be imported from either another FML document or a ModelML
document FML provides the fieldgeometric information used by ModelML FML
documents can also import other FML documents these external FML models can then be
used by the mapping branch to construct a new FML model
All local namespace objects within the ltframegt and ltdeclarationgt branches are visible to
the parent document In boundary representation and mesh representation models all cell
objects can be referenced directly by name Point lists are referenced using an index system
(pt[0] hellip pt[n])
FML allows Cell objects and topological objects to be referenced by an index system as
well as an identifier if one exists To access these by index the correct method when only
one list container exists is
Class_id[index] or topological_class_id[index]
If for some reason a multiple class list container exists within the FML cell list branch the
following index system may be used
Class_id[index of list group][index]
In Mesh models accessible objects can be inferred from the domain information supplied
through the index system using
Vertex[index] edge[index] face[index] subdomain[index]
or if the identifier branch is supplied (string literal identifier mapping) direct reference to
this string literal may be used
ltimport name=rdquouniqueIDrdquo xlink=rdquogeometryfmlrdquo type=rdquoFMLrdquogt
69
HDF5 import
HDF5 is used to store large numeric datasets its internal structure is similar to FML HDF5
may be imported using
ltimport name=rdquohdf5rdquo xlink=rdquohdf5fileh5rdquo type=rdquohdf5rdquogt
Internal objects are referenced using the combination of import identifier and the HDF5
pathing system to locate objects within HDF structure (Import_idinternal_h5_path) To
access objects within HDF5 files the attribute ldquoext_srcrdquo within the referencing object is
used
For example if a point list is stored in HDF5
ltpt_list ext_src=rdquohdf5cellsdim0pointsCoordinateDSrdquogt
Or a Bezier Curve
ltbezier_curve ext_src=rdquohdf5cellsdim1bezier_curve_listbc1rdquogt
70
36 MML mathematical objects
361 Declaration overview
Both ModelML and FML require additional mathematical expression support in addition to
their basic functionality The declaration branch is used in both FML and ModelML
documents to declare variables expressions functions and other declarative objects
This branch requires the ability to construct basic mathematical constructs associated with
variables expressions or functions All mathematical contents in MML are described using
MathML Specialized mathematical constructs include CellML units boundary conditions
and weak term representation The declaration branch also allows data storage in native
XML format or HDF5 The data are stored in a tree hierarchical form that can be used to
represent an n-dimensional array
The ltdeclarationgt element exists as a child of the document root In general most
declaration objects intended to be publicly used within the document are stored under the
ltdeclarationgt element
ltdeclarationgt ltvariable_listgt ltequation_listgt ltdeclarationgt
However declaration objects can be stored outside the declaration branch within other
MML objects these objects can only be accessed by the parent element according to the
specific element parsing rules
ltdependent_variable name=rdquoardquogt ltvariable name=rdquoegrdquogt ltdependent_variablegt
The declaration branch currently supports ltvariablegt ltequationgt ltfunctiongt
ltboundary_conditiongt ltweak_termgt ltdatagt and ltunitsgt declaration
71
362 Variables
ltvariablegt is a symbolic representation that can be used to represent a constant or an
unknown quantity that can change Variables are not strongly type cast To declare a
constant type or a variable type with an initial condition the attribute value is used to
specify the numeric quantity To declare that a variable can change its value with no given
initial conditions simply declaring the ltvariablegt with a unique identifier within the
relevant namespace scope is sufficient
ltvariable_listgt ltvariable name=rdquotemperaturerdquo value=rdquo-40rdquo unit=rdquoCelsiusrdquogt ltvariable_listgt
363 Equations
The ltequationgt element is used to describe simple numeric mathematical or logical
expressions which are symbolically linked to a variable identifier that can be accessed
from relevant namespace scopes The use of expressions can significantly simplify complex
equations by breaking them down into simpler components
An ltequationgt declaration typically contains two parts a variable list followed by a
MathML description of the expression The MathML declaration must be in the form of
Variable_identifer = math_expression
For example to define the equation a = 42 we could use
ltequation_listgt ltequation name=rdquoeg1rdquogt ltvariable_listgt ltvariable name=rdquoardquogt ltvariable_listgt ltmathgt ltapply id=rdquoeq1rdquogt lteqgt ltcigtaltcigt ltcngt42ltcngt ltapplygt ltmathgt ltequationgt ltequation_listgt
72
364 User defined functions
The ltfunctiongt object is used to declare functions including basis functions that can be
used to interpolate sets of data There are a number of components within ltfunctiongt that
must be declared These include the input header that describes the inputs to the function
such as parameters or data points The input header information includes input variable
name type (ie vector scalar matrix) and optional constraints on the input variables
description The output header describes the output variable information including the name
of the variable and type The mathematical content of user-defined functions is described
using MathML For example to define the function
f = hermite_cubic(nnpt1pt2tan1tan2t)
We could use a template code as described as followed
ltfunction_listgt
ltfunction name=hermite_cubicgt ltinput_headergt lt-- describe field inputs iept1 pt2 t1 t2gt lt-- need to differentiate variables (ie normal inputvector and parameter ) --gt ltinput_listgt ltinput name=xx type=DataType(Optional)gt ltinput name=xx type=DataType(Optional)gt ltconstraintgt ltmathgt boolean ltmathgt ltconstraintgt ltinputgt ltinput name=xx type=DataType(Optional) parameteric=truegt ltrange gt_eq=5 lt_eq=-5gt ltinputgt
73
ltinput name=pt1 type=Vector2fgt ltinput name=pt2 type=Vector2fgt ltinput name=tan1 type=Vector2fgt ltinput name=tan2 type=Vector2fgt ltinput name=t type=float parameteric=truegt ltrangegt ltapplygt ltgtgt ltcngt0ltcngt ltapplygt ltapplygt ltltgt ltcngt1ltcngt ltapplygt ltrangegt ltinputgt ltinput_listgt
ltinput_headergt ltoutput_headergt ltoutput_headergt lt-- Math declaration that must use the above input --gt ltmathgt ltapplygt lttimesgt ltapply id=cubic_hermite_basisgt ltmatrixgt ltmatrixrowgt ltcngt2ltcngtltcngt-2ltcngtltcngt1ltcngtltcngt1ltcngt ltmatrixrowgt ltmatrixrowgt ltcngt-3ltcngtltcngt3ltcngtltcngt-2ltcngtltcngt-1ltcngt ltmatrixrowgt ltmatrixrowgt ltcngt0ltcngtltcngt0ltcngtltcngt1ltcngtltcngt0ltcngt ltmatrixrowgt ltmatrixrowgt ltcngt1ltcngtltcngt0ltcngtltcngt0ltcngtltcngt0ltcngt ltmatrixrowgt ltmatrixgt ltapplygt ltvectorgt ltcigtt^3ltcigt
74
ltcigtt^2ltcigt ltcigttltcigt ltcigt1ltcigt ltvectorgt ltvectorgt ltcigtpt1ltcigt ltcigtpt2ltcigt ltcigttan1ltcigt ltcigttan2ltcigt ltvectorgt ltapplygt ltmathgt ltfunctiongt ltfunction_listgt
365 Weak term declarations
Many spatio-temporal models consist of PDEs which are defined only on boundaries and
sub surfaces whose dimension is less than the dimension of the model itself To implement
such cases ModelML employs the use of weak term declarations This terminology follows
the syntax of the COMSOL finite-element package which allows users to specify weak
term expressions such that when multiplied by a number of suitable test functions their
spatial integral is constrained to be zero In MML weak terms consists of weak weak
derivative and constraint expressions stored in ltweakgt ltdweakgt and ltconstrgt
respectively If the parsing application does not detect any of these the default value 0 is
assumed
Simple scalar values can be stored in the attribute ldquovaluerdquo Expressions can be stored as
MathML or referenced as a declaration object
ltweak_term_listgt ltweak_term name=rdquobcrdquogt ltweak values=rdquo4rdquogt ltweakgt ltdweakgt Math expression ltdweakgt ltconstrgt ltequation ref=rdquossrdquogt ltconstrgt ltweak_termgt ltweak_term_listgt
75
366 Boundary condition declarations
ltboundary_conditiongt describes the mathematical formulation of the PDE boundary
conditions necessary to solve spatial models There are two main types of boundary
conditions supported Dirichlet and Neumann It is also possible to create a mixed boundary
condition
The Neumann boundary condition is described as
(3-1)
Whilst the Dirichlet boundary condition is described as
(3-2)
Where denotes the normal inward component of the flux vector across the boundary
and R is an expression vector whose elements are constrained to equal 0 These elements
specify the Dirichlet boundary condition For example for a PDE system in two dependent
variables u v with boundary conditions and inward flux for v equals to
we would specify
The term in the Dirichlet boundary condition refers to internal Lagrange multipliers
introduced to enforce the Dirichlet and Neumann boundary constraints Note that the
Dirichlet condition requires both the G and R term to be specified while the Neumann only
requires G to be specified
A ltboundary_conditiongt must declare the attribute name and type The G and R terms are
stored in the elements ltggt and ltrgt respectively and are optional If the parsing
application does not detect these the value of 0 is assumed If the values are simple scalar
76
values they may be stored using the attribute ldquovaluerdquo If the information is a mathematical
expression then it can be stored using MathML within the parent element or using the
declaration object reference
ltboundary_condition_listgt ltboundary_condition name=rdquoinsulationrdquo type=rdquodirichlet rdquogt ltg value=rdquo4rdquogt ltrgt MathML ltrgt ltboundary_conditiongt ltboundary_condition_listgt
367 Units
ltunitsgt is used to describe non-SI units As described earlier the unit description
framework will be implemented according to the CellML 10+ specification
ltunits name=celsius_per_centimetregt ltunit units=celsius gt ltunit prefix=centi units=metre exponent=-1 gt
ltunitsgt
368 Data
ltdatagt can be used to store hierarchical data This can be an n-dimensional array or a tree-
based structure The data stored can be MathML integer String or data object reference to
create complex multi-dimension array structures
A ltdatagt object contains two main components ltheader gt and ltarraygt The header
describes the data type and units of the data elements using ltdata_typegt which describes
the type of the data The primitive types supported are listed in Table 3-4
77
Data Type Definition
String
Integer Two-byte big-endian unsigned integer
Float Four-byte big-endian IEEE floating point
Double Eight-byte little-endian IEEE floating-point
Table 3-4 Data types currently supported by ltdatagt
A complex ltdata_typegt can be created by embedding it in other data types For example
if a data type of ldquosrdquo is created composed of String and Integer
ltdata_types name=rdquosrdquogt ltdata_type type=rdquoStringrdquogt ltdata_type type=rdquoIntegerrdquogt ltdata_typegt
A hierarchical array is specified using the ltarraygt element which may contain ltdgt (a
short hand representation for datum) for data elements or additional ltarraygt elements to
create a multi-dimensional array structures
Complex data can be stored by encapsulating ltdgt within other ltdgts Using the example
above
ltdgt ltdgtXltdgtltdgt1ltdgt ltdgt
Large numeric datasets can have the data stored in an external HDF5 file and referenced
using the attribute ldquoext_srcrdquo This method only allows multi-dimensional rectangular arrays
to be represented
For example
ltdata_listgt ltdata name=rdquohdf5rdquo ext_src=rdquoh5_filedatahdf5_egrdquogt ltheadergt ltdata_type type=rdquointegerrdquogt ltheadergt ltdatagt
ltdata name=rdquocell_gridrdquogt ltheadergt ltdata_type type=rdquointegerrdquogt
78
ltheadergt ltarraygt ltarraygt ltdgt3ltdgt ltarraygt ltarraygt ltdgt3ltdgt ltarraygt ltarraygt ltdatagt
ltdata_listgt
79
37 The ModelML specification
371 Overview
Using the MML framework organ and tissue can be represented by a geometric model
with constituent cells of the tissue represented by a mathematical model To map the
cellular model onto the tissue or organ a relational descriptive specification is required
One of the main goals of the MML framework is to provide a specification that describes
relational information between different components of a model including the nature of the
relationship as well as adding additional data to the relationship such as an external
stimulus current that was not in the original constituent cellular model An optional
component of the relational specification is metadata used by the external application to
help in parsing the document
The above requirements are satisfied by the specification known as ModelML ModelML is
intended to describe relational information between different XML documents
Specifically it relates field information to mathematical systems models such as field
information in FML to the mathematical systems models in CellML or local mathematical
declarations ModelML will provide a range of mechanisms which allow imported CellML
models to be modified at a local level This includes changes to variable values equations
to be substituted or new dependent variables to be introduced It will also provide a path
handling system to access objects from external documents ensuring that local and
imported objects do not have naming conflicts
ModelML also describes model setup information in addition to general metadata using the
ltprotocolgt element This includes the solver application setup such as particular solver
used solver configuration and mesh elements used Protocol attributes are not required
ModelML can also contain model metadata information using the resource descriptive
framework (RDF) as well as general commenting about the model using a general XML
commenting system closely related to the CellML Metadata specification
372 Design and requirement
The goal of ModelML is to encapsulate relational information between FML and CellML
and provide the additional information required to construct a functional model that maps
80
between the spatial field domains to the cellular mathematical systems models As such
ModelML is required to provide facilities to import external models as well as allow
accessing and overriding capabilities to the imported models It must also provide methods
to describe the governing PDE systems To ensure commonality between ModelML and
FML both specifications will use the import and declaration branches The separation of
information into different domains encourages modularity leading to more reusability and
easier construction of models Under this paradigm ModelML is a top level document that
imports lower level XML documents such as CellML FML or ModelML declaration
branch information
-name
ltmodelmlgt
-name
ltimportgt
ltmodelgt
ltdeclarationgt
-name
ltgroupgt
ltprotocolgt ltsystemgt
-name
ltsubdomaingt
-name
ltedge_groupgt
-name
ltboundary_groupgt
-name
ltpoint_groupgt
ltgeometric_propertygt
ltphysics_propertygt
1
1
1
1
1 1
ltinterfacegt ltimplementgt
1
-about
ltrelationalgt
1
Figure 3-12 ModelML Level 1 Relational Diagram
81
As shown in Figure 3-12 each ModelML model will contain one ltmodelgt branch to
describe the main model of that document Within that ltmodelgt branch there are a number
of different components
The ltsystemgt branch is used to describe the mathematical systems and related variable
mappings This allows the grouping of ODEs from one or more CellML models and
describes how state variables are mapped and It also describes spatial variables from FML
that will declare the variable names to be used in the ModelML scope or map these spatial
variables to these found in other documents
The grouping branches including ltsubdomaingt ltboundary_groupgt and
ltpoint_groupgt is where the geometric information from FML is linked to the
mathematical information such as the CellML and ODE systems as well as declarative
objects from the ltdeclarationgt branch
ModelML is required to provide specific handling capabilities for CellML and to some
extent FML CellML overriding modifications at the ModelML level include replacing
variable values or initial conditions replacing variables with new expressions and
allowing equations from CellML to be duplicated and modified There are two main places
in ModelML where CellML documents can be modified at the ltimportgt branch and
where the CellML object is referenced within ModelML In the ltimportgt branch the
CellML document can be considered as a template At this level any modifications here are
carried to any other objects which reference this imported model At the reference level a
CellML document can be considered as an instantiated object where any modification at the
local reference level will only be visible within the local scope Any modification there will
have precedence over higher level modifications if there are areas of overlap
CellML ODEs are generally in the form of
From the ModelML perspective modifications are to insert field information such as or
append additional information to the source term (F) From the ModelML subdomain
82
grouping perspective the goal is to alter the ODE equation from CellML into the PDE
form
Where is a generalised flux term such as and [op] can be addition subtraction
multiplication or division on the extra source term
FML object handling is only concerned with referencing the correct type of data
specifically the dimensional information from FML to ModelML There are two main
areas of this enforcement the first being that the referencing object must be the correct
abstract object For example a bezier curve should be referenced by an Edge object The
second area is the grouping branch where it should be ensured that the correct geometric
or field objects are used in the correct group
For 3D models
- Subdomains ndash solid regions
- Boundary ndash surfaces
- Edge ndash edges
- Point ndash points
For 2D models
- Subdomains ndash face
- Boundary - edges
- Point ndash points
For 1D models
- Subdomains ndash edges
- Point ndash points
As the dimension of the geometric model decreases the relational information also
decreases
83
ModelML can describe a number of metadata information including protocol attributes
which describe functional aspects of the model including the type of solver used the time
step or even mesh element associated with dependent variables The protocol metadata can
also be used to describe mathematical ontology information
General metadata such as author names model description or modifications can be
described through either RDF in ltannotationgt or general XML comments
As an example of ModelML use to describe an electrophysiological tissue model a
number of components have to be considered
1) Import CellML and FML documents
2) Create Mathematical Systems and Spatial Variable mappings if applicable
3) Create relational information between different data domains
4) Insert metadata to describe model information
Step one is to import the FML and CellML documents This allows these imported objects
to be accessible from within the ModelML document The import mechanism also allows
ModelML to override values from the external documents
The next step is to declare the mathematical or spatial systems This is used to define the
mathematical equations of this model but also map variables that may span across different
CellML documents For example multiple cellular models may be used to model tissue
function however there is no guarantee that the variable names or the number of state
variables are the same The system mapping allows these variables to be mapped under a
common identifier or have the ODE systems grouped depending on the parent PDE
systems The system mapping also allows spatial variables to be mapped from FML
documents to CellML and ModelML
The next step is to create relational information between the field and mathematical system
data Different geometric objects can be linked with different types of mathematical
information For example a subdomain entity can be linked to a governing ODE
mathematical model while boundary or point objects can be referenced to boundary
conditions or weak term mathematical declarations The grouping mechanism also provides
84
a means to attach field information such as tissue conductivity to the PDEs and provide a
local scope to manipulate or replace data of the imported models
Metadata can be inserted into the ModelML documents to describe the model in order to
provide detailed explanations of the model and different components used ModelML
provides two types of metadata support general metadata description using the CellML
metadata specification and protocols Protocols are used by applications to describe
different types of data All metadata can be ignored by the parsing applications
373 ModelML document structure
A ModelML document is declared by the ltmodelmlgt element which must use the ldquonamerdquo
attribute to define the name of this model There are 3 main child elements that can be
declared within ltmodelmlgt these are ltimportgt ltdeclarationgt and ltmodelgt A fully
functional ModelML document can contain all three branches All model and relational
data are contained under the ltmodelgt branch The ltimportgt branch describes external
documents used by this document whilst the ltdeclarationgt branch contains mathematical
objects that are used by the current document The specific rules for ltimportgt or
ltdeclarationgt can be found under their respective sections in this chapter It is possible to
declare a ltmodelmlgt document with only ltdeclarationgt data This type of ModelML
document can be imported into other ModelML documents
Elements declared under ltmodelgt include ltprotocolgt ltsystemgt grouping related
elements such as ltsubdomaingt ltedge_groupgt ltboundary_groupgt or ltpoint_groupgt
elements An example of the MML structure layout is given as followed
ltmodelml name=rdquomodelrdquogt ltimportgt ltdeclarationgt ltmodelgt ltsystemgt ltgroupgt ltmodelgt ltmodelmlgt
85
Protocol
The ltprotocolgt branch contains protocol attributes which describes information related to
external application processing Protocol attributes are described using ltp_attributegt
which must declare a ldquonamerdquo attribute that is a unique legal identifier The attribute
information is stored as text under the ltp_attributegt element although most general
protocol attributes should be contained within the ltprotocolgt branch itself
ltvariable name=rdquoTrdquogt ltprotocolgt ltp_attribute name=rdquofemelementrdquogtLagrangeltp_attributegt ltprotocolgt ltvariablegt
A number of attribute names are reserved under the MML framework These include
- Comsol Application Dependent
- comsolsolver
- comsolsolvertimestep
- comsolsolverabs_tol
- comsolsolverrel_tol
- comsolsolvermax_bdf
- comsolsolvermin_bdf
- comsoltimestep
- comsoltimesteptaken
- comsoltimestepinitial
- comsoltimestepmaximum
- MML General
86
- mmlsolvertype
- mmlsolver
- mmlsolvertimestep
- mmlsolverinitial
- mmlsolvermaximum
- FEM related
- femelement
Lagrange
Argyris
Hermite
Bubble
Curl
Discontinuous
Density
Divergence
- femelementshape
- femelementgorder
- femelementcporder
It is not required that the parsing application recognizes or implements methods that will
utilise these protocol attributes With the active development of SED-ML37
(Simulation
37
httpwwwbiomodelsnetsed-ml
87
Experiment Description Markup Language) an XML based encoding of simulation
experiments The protocol metadata could be replaced by this language when a stable
version has been released
Systems
The ltsystemgt branch is used to describe mathematical systems that reside within a
ModelML document this may include ODE systems or spatial variable mappings The
ltsystemgt elements are encapsulated under the ltsystem_listgt element A ltsystemgt
element must declare the ldquonamerdquo attribute and has two child elements ltmodel_groupgt
and ltvariable_mappinggt
ltmodel_groupgt encapsulates ltimportgt references of models which contain variables to be
mapped ltvariable_mappinggt contains overriding variable declarations mapped to the
variables found from the referenced imported models in ltmodel_groupgt
For ODE systems ltvariable_mappinggt has an attribute ldquomappingrdquo which can be set to
ldquodefaultrdquo if the current ODE system has a one to one mapping of dependent variable to the
imported dependent variables If not the dependent variable of the ODE system will have
to be declared as ltstate_variablegt and mapped to the corresponding variable found in the
referenced imported model It must also declare the independent variable of that ODE
system using the ltindependent_variablegt element In certain situations
ltindependent_variablegt may be declared within its own ltsystemgt element This generally
occurs when two CellML models contain different numbers or unrelated dependent
variables such that a single ltsystemgt is incapable of mapping these elements
The ODE state variable name does not have to be the same as the mapped dependent
variable name the latter is used to override variable names at a local scope Parsing
applications which handle ltsystemgt related references must take into consideration the
renaming of dependent variables from the imported document
The number of variable mappings within each ltstate_variablegt must be the same as the
number of referenced imported models under the ltmodel_groupgt
88
ltsystem name=test2gt ltmodel_groupgt
ltimport ref=earmgt ltimport ref=fitzgt ltmodel_groupgt ltvariable_mappinggt ltstate_variable name=V1gt ltvariable ref=earmmembraneVgt
ltvariable ref=fitzmembraneVmgt ltstate_variablegt ltstate_variable name=mgt ltvariable ref=earmfast_sodium_current_m_gatemgt ltvariable ref=fitz comp1mgt ltstate_variablegt ltindependent_variable name=rdquotimerdquogt ltvariable ref=earmfast_sodium_current_m_gatetimegt ltvariable ref=fitz comp1timegt ltindependent_variablegt ltvariable_mappinggt ltsystemgt
The ltsystemgt element may also be used to declare a spatial system This maps spatial
variables present in CellML to FML The element ltspatial_variablegt is used within
ltvariable_mappinggt
ltsystem name=spatial_systemgt ltmodel_groupgt
ltimport ref=cellmlgt ltimport ref=geometrygt ltmodel_groupgt ltvariable_mappinggt ltspatial_variable name=xgt ltvariable ref=cellmlcomponentx_variablegt
ltvariable ref=geometryxgt lt spatial_variable gt ltvariable_mappinggt ltsystemgt
By default if only one FML model is imported and used in the relational grouping the
spatial variable name is presumed to be available at the ModelML scope In such instance
it is not necessary for the ModelML document to declare the spatial variable mapping
89
Groups
Grouping elements describe a many to many relational information between different MML
objects The generic class on which all grouping tags are based is the ltgroupgt element
Each ltgroupgt element may contain multiple ltrelationalgt elements which encapsulate the
members of this relationship as shown in Figure 3-13 The ltrelationalgt element provides
the abstract class from where specific categories are derived
Figure 3-13 A group can contain a number or relational definitions Each definition must include one
or more items
The Group relation pattern can be used to create a more complex tree relational structure as
shown in Figure 3-14 A ltrelationalgt element may contain a child ltgroupgt element to
create a multi-level tree based relationship
90
Figure 3-14 Complex tree based grouping using ltgroupgt
In general Group describes the relational information between field objects and
mathematical information These groups include ltsubdomaingt ltboundary_groupgt
ltedge_groupgt and ltpoint_groupgt All grouping elements must declare the ldquonamerdquo
attribute with a unique legal identifier Relational categories are ltgeometric_propertygt
which contains field related objects and ltphysics_propertygt which contains mathematical
content objects
Processing application should also note the dimensional correctness of the container or
reference element in ltgeometric_propertygt Grouping elements should only reference
FML objects of the relevant dimension as set out in Table 3-5
91
DimensionGrouping Subdomain Boundary Edge Point
3D Model 3d 2d 1d 0d
2D Model 2d 1d NA
(Boundary)
0d
1D Model 1d 0d NA 0d
Table 3-5 Grouping in relation to geometric dimensions
It is also possible to use topological element to reference an FML geometric object such as
ltedgegt to represent a ltbspline_curvegt element using its index position ie
(topological_class[index_pos]) The processing application should ensure that object
referencing using an abstract object observes the dimensional correctness
There are two main types of mathematical models that can be referenced within ModelML
an external imported model or as general declaration object To reference an external
model the ltimport_propertygt element must be used within ltphysics_propertygt while for
a non-imported model object a ltsystem_mappinggt can be used These elements are used
to link the mathematical information to the relevant ltsystemgt group
ltsystem_mappinggt must declare the ldquosystem_refrdquo attribute which references an existing
ltsystemgt declaration ltsystem_mappinggt can contain a number of ltvariable_mappinggt
tags Each ltvariable_mappinggt declares a number of dependent variables (under
ltvariable_listgt) and their corresponding conditions (under ltconditionsgt) The dependent
variables declared in all ltvariable_mappinggt tags within a ltsystem_mappinggt must have
a one to one relationship with state variables declared from the referenced ltsystemgt
element
ltphysics_propertygt ltsystem_mapping system_ref=test1gt ltvariable_mappinggt ltvariable_listgt ltstate_variable ref=Vmgt ltvariable_listgt ltconditionsgt ltboundary_condition ref=invert_bcgt ltconditionsgt ltvariable_mappinggt ltsystem_mappinggt
92
ltphysics_propertygt
The ltimport_propertygt element is used to reference an external mathematical model to the
appropriate ltsystemgt ODE group Each ltimport_propertygt must declare the attribute
ldquoimport_refrdquo which points to a valid ltimportgt object as well as a ldquosystem_refrdquo which
points to a valid ltsystemgt object Each ltphysics_propertygt may have multiple
ltimport_propertygt tags which link different mathematical model or system groups to the
same geometric region
ltphysics_propertygt ltimport_property import_ref=fitz_central system_ref=test1gt
ltphysics_propertygt
Subdomains
ltsubdomaingt references geometric domains In 3D space these are solid regions In 2D
space they are face objects while in 1D they are edge objects
Mathematical models referenced in ltsubdomaingt are generally from imported models
specifically CellML There are a number of specialized elements to deal with external
imported models which allows referencing and modification of these models
To reference an imported model an ltimport_propertygt element must be declared under
ltphysics_propertygt ltimport_propertygt must contain the ldquoimport_refrdquo attribute which
references the import declaration as well as ldquosystem_refrdquo which references the ODE
system declaration if the external model contains ODEs
For each modification to the referenced model a ltlayergt element must be used This
element should declare both a ldquotyperdquo attribute declaring the type of the imported model as
well as a ldquonamerdquo attribute A ltlayergt element must also contain ltimport_equationgt
which references the equation in the imported model using the ldquorefrdquo attribute
Additional optional elements found under ltlayergt include ltfluxgt ltsourcegt and
ltstimulusgt objects
ltsubdomain name=x2gt ltgeometric_propertygt
93
ltgeometric_entity ref=circleS_2gt ltgeometric_propertygt
ltphysics_propertygt ltimport_property import_ref=fitz_central system_ref=test1gt ltlayer type=cellml name=bodygt ltimport_equation ref=membraneVm_diff_eqgt ltflux x_direction=-sigVmx y_direction=-sigVmygt hellip ltsource operation=rdquoplusrdquogt MathML ltsourcegt hellip ltstimulus ref=rdquostim1rdquogt
ltlayergt ltimport_propertygt
ltphysics_propertygt ltsubdomaingt
CellML models are referenced using ltimport_propertygt from within grouping elements
Also the CellML model must be declared under ltsystemgt elements for setting up the
correct model equations The ltimport_propertygt references the whole ODE system from
the imported model to the relevant geometric objects
The parsing application is required to take into consideration both the ODE system and the
external CellML model when parsing the ltimport_propertygt The system tag declares
which dependent variables from the CellML model are relevant along with the subsequent
ODE and related variables
Further modifications to the imported CellML model can be achieved through use of the
ltlayergt elements Each ltlayergt element must declare an ltimport_equationgt element
which references an equation from the CellML model using the CellML referencing
system If more than one layer references the same equation this creates duplicate
equations The parsing application must take this into consideration and create the
modifications
ltimport_equation ref=rdquomembraneVm_eqrdquogt
It is possible to manipulate the referenced imported equation within the local scope This
involves providing new expressions to which the variables in the old expression will
94
reference The current specification only allows variables from the old equations to be
substituted with a new expression For example to substitute the variable in an imported
CellML model with the new expression we could use
ltimport_equation ref=rdquomembraneVm_eqrdquogt ltapply id=rdquosubrdquogt lteqgt ltcigtVmltcigt ltapplygt ltminusgt ltcigtViltcigt ltcigtVeltcigt ltapplygt ltapplygt ltimport_equationgt
In this example the Vm variable in the old equation will reference the new expression
where
Additional information can also be attached to ltimport_equationgt elements These include
ltfluxgt ltstimulusgt and ltsourcegt ltfluxgt describes the vector gradient information of a
variable within subdomain The available attributes are ldquox_directionrdquo ldquoy_directionrdquo and
ldquoz_directionrdquo to describe simple scalar values or using a MathML vector to describe more
complex expressions
ltstimulusgt and ltsourcegt elements attaches an extra term to the imported equation The
ltsourcegt allows an extra mathematical term described using either a ldquorefrdquo attribute to
reference an existing expression ldquovaluerdquo attribute to describe a scalar value or using
MathML to describe an expression The ldquooperationrdquo attribute describes how this term will
be attached to the original CellML equation The possible operation are plus minus divide
or multiple The ltstimulusgt element is derived from the ltsourcegt element where the
operation is set to plus
ltimport_property system_ref=rdquosystem1rdquo import_ref=rdquoimport1rdquogt ltlayer type=rdquoCellMLrdquogt ltimport_equation ref=rdquomembranev1rdquogt ltflux x_direction=rdquo-Vmxrdquo y_direction=rdquo-Vmyrdquogt ltsource operation=rdquominusrdquo value=rdquo5rdquogt ltlayergt
95
ltlayergt ltimport_equation ref=rdquomembranev2rdquogt ltfluxgt
ltvectorgt ltapplygt lttimesgt ltcigt-sigAltcigt ltapplygt ltdiffgt ltbvargt ltcigtxltcigt ltbvargt ltcigtVmltcigt ltapplygt ltapplygt ltapplygt lttimesgt ltcigt-sigAltcigt ltapplygt ltdiffgt ltbvargt ltcigtyltcigt ltbvargt ltcigtVmltcigt ltapplygt ltapplygt ltvectorgt
ltfluxgt ltlayergt ltimport_propertygt
In this example the ndashVmx value of the x-direction attribute inltfluxgt denotes
where
Vm is defined variable in the imported CellML model Similary ldquo-Vmyrdquo in the y_direction
denotes
In general the rules for the parsing application dealing with CellML modifications starts at
the ltimportgt element When parsing the ltimportgt element the parsing application should
create a copy of information from that CellML model with any modifications that have
occurred at that scope Every object that references this ltimportgt element should have a
instantiation of that CellML template Any further modification at the local level of the
referencing object should override the local copy of the CellML template
96
Edge Boundary and Point Groups
Edge boundary and point groups are used to reference the respective geometries to the
relevant mathematical objects The correct geometric object dimension is shown in Table 3-
5 An edge group is only applicable to 3D geometrical models to describe 1D objects in 3D
space While in 2D geometric models a 1D object is classified as a boundary object instead
of an edge
374 ModelML Example
An example ModelML importing an excitable cardiac model (Rogers-McCulloch)
described in CellML (equation 3-3 and 3-4 with values described in Table 3-6) mapped to a
simple 1D cable geometry will be presented The cable geometry is split into two domains
where one domain is applied with an external current
(3-3)
(3-4)
Parameter Atrial
a 013
b 0
c1 026
c2 01
d 1
e 013
A 140
B -85
k 3000
Vm(0) -65
u(0) 0
Table 3-6 FHN and RM model parameters and initial condition values All units are dimensionless
unless otherwise specified
97
Using ModelML equation (3-3) will have gradient conductivity and a stimulus term
attached as shown in equation (3-5) in bold
(3-5)
The ModelML example
ltmodelml name=rm_condgt ltimport_listgt ltimport name=geom type=FML xlink= conductivity_testfmlgt ltimport name=atria type=CellML xlink= roger_modified_FIXEDxmlgt ltdependent_variable name=membraneVm initial_condition=rdquo-60rdquogt ltdependent_variable name=recovery_variableugt ltindependent_variable name=environmenttimegt ltparameter name=ionic_currentk value=3000gt ltparameter name=recovery_variablee value=0013gt ltparameter name=recovery_variableB value=-85gt ltparameter name=recovery_variableA value=140gt ltparameter name=recovery_variabled value=1gt ltparameter name=membraneCm value=1gt ltparameter name=recovery_variablebeta value=0gt ltparameter name=ionic_currentc1 value=026gt ltparameter name=ionic_currentc2 value=01gt ltparameter name=ionic_currentalpha value=013gt
ltimportgt ltimport_listgt
ltmodelgt ltsystem_listgt
ltsystem name=membranegt ltmodel_groupgt
ltimport ref=atriagt ltmodel_groupgt ltvariable_mappinggt
ltstate_variable name=Vgt ltvariable ref=atriamembraneVmgt
ltstate_variablegt ltvariable_mappinggt
ltsystemgt ltsystem name=time_systemgt
ltmodel_groupgt ltimport ref=atriagt
ltmodel_groupgt
98
ltvariable_mappinggt ltindependent_variable name=time units=secondgt
ltvariable ref=atriaenvironmenttime units=secondgt ltindependent_variablegt
ltvariable_mappinggt ltsystemgt ltsystem name=atr_underlyinggt
ltmodel_groupgt ltimport ref=atriagt
ltmodel_groupgt ltvariable_mappinggt
ltstate_variable mapping=default name=ugt ltvariable_mappinggt
ltsystemgt ltsystem_listgt ltsubdomain_listgt
ltsubdomain name=san_domgt ltgeometric_propertygt
ltgeometric_entity ref=geomSANgt ltgeometric_propertygt ltphysics_propertygt
ltimport_property import_ref=atria system_ref=membranegt ltlayer name=mvgt
ltimport_equation ref=membraneVm_diff_eqgt ltfluxgt
ltapplygt lttimesgt ltcigt-sigAltcigt ltapplygt ltdiffgt ltbvargt ltcigtxltcigt ltbvargt ltcigtVltcigt ltapplygt ltapplygt
ltfluxgt ltstimulus value=stimgt
ltlayergt ltimport_propertygt ltimport_property import_ref=atria system_ref=atr_underlyinggt ltphysics_propertygt
ltsubdomaingt ltsubdomain name=atr_domgt
ltgeometric_propertygt ltgeometric_entity ref=geomAtrgt
99
ltgeometric_propertygt ltphysics_propertygt
ltimport_property import_ref=atria system_ref=membranegt ltlayer name=mvgt
ltimport_equation ref=membraneVm_diff_eqgt ltflux
ltapplygt lttimesgt ltcigt-sigAltcigt ltapplygt ltdiffgt ltbvargt ltcigtxltcigt ltbvargt ltcigtVltcigt ltapplygt ltapplygt
ltfluxgt ltlayergt ltimport_propertygt ltimport_property import_ref=atria system_ref=atr_underlyinggt ltphysics_propertygt
ltsubdomaingt ltsubdomain_listgt
ltmodelgt
ltdeclarationgt ltvariable_listgt
ltvariable name=sigA value=2e-4gt ltvariable name=sigSA value=2e-4gt
ltvariable_listgt ltunits_listgt
ltunits name=millisecondgt ltunit prefix=milli units=secondgt
ltunitsgt ltunits_listgt ltequation_listgt
ltequation name=stimgt ltmathgt ltapply id=stimgt lteqgt ltcigtstimltcigt ltapplygt lttimesgt ltcngt50ltcngt ltapplygt ltminusgt
100
ltapplygt ltgtgt ltcigttltcigt ltcngt01ltcngt ltapplygt ltapplygt ltgtgt ltcigttltcigt ltcngt011ltcngt ltapplygt ltapplygt ltapplygt ltapplygt ltmathgt ltequationgt
ltequation_listgt ltdeclarationgt
ltmodelmlgt
101
38 The FML specification
381 Overview
The definition of a field is the association of a physical quantity to every point on a
manifold Fields can have both a geometric or non-geometric representation Examples of
the former would be anatomical-based models such as the electrical conductivity field of a
tissue or organ An example of a non-geometric representation would be a gravity field
describing gravitational strength at all points in space as a function of some global
coordinate system Fields can be classified into scalar fields such as voltage vector fields
such as force or tensor fields such as the state of stress in a solid or fluid medium
In biological modelling fields have a range of important applications including describing
the shape of anatomical objects or spatial properties such as stress and temperature A
complex field model can consist of a geometric model containing multiple field attribute
definitions describing tissue fibre orientation ion channel expression and other spatial
variation in tissue properties
In the MML framework field representation is delegated to the FML specification FML is
primarily responsible for describing geometric models and providing identifications to
components of these models In addition FML is capable of assigning field attributes to
regions of space this can be used to describe specific region characteristics or even to
specify storage result datasets
Although XML is a verbose data structure[16 50] with increasing storage capacity and
compression methods it is possible to minimize the size of field data in XML Nevertheless
XML is not an elegant solution for large numeric datasets The Hierarchical Data Format
(HDF) is an open self-describing standard used to describe large heterogeneous esoteric
numeric datasets or images This makes it an ideal complement to the XML specification
where object identifiers can be stored in XML while associated numeric datasets can be
stored in HDF5
102
382 Design and requirements
The goal of FML is to represent field information and the space that contains it To achieve
this a number of aspects have to be considered including
- Spatial representation
- Basic field objects
- Geometric representation
- Field attributes
- Identifiers
- User defined Interpolating functions
- Modularity
Spatial representation will form the container where field objects will be declared The need
to declare such a container is important Its properties such as dimension names (ie spatial
coordinates and time variables) will be used referenced by ModelML In FML the concept
of ldquoframerdquo will provide this function A frame object allows FML models to be combined
encouraging modularity and reuse
Basic field objects will define the type of fields supported in FML FML will attempt to
provide a basic set of geometric objects to define shapes or regions as well as user defined
interpolating functions for describing spatial objects FML will also provide common
methods in geometric representation techniques The geometric representation scheme
should be concise and simple
FML will also provide object identifier mechanism This will allow objects or spatial
properties to be referenced internally or externally by other documents Providing a
modular approach in model construction
FML will incorporate both ltimportgt and ltdeclarationgt as described previously in their
respective sections Using the common framework of MML will simplify application and
model development
103
In general field data sizes are often large Due to the verbose nature of XML the file size
could be significantly larger compared with binary format storage However there are
several factors that could minimize the XML overhead disadvantages [30] including
1) The cost of storage space has decreased exponentially over recent years
2) The use of XML databases significantly improves access performance and storage
size depending on the database implementation
3) XML can be compressed or converted in XML binary format to decrease file size
It is possible to store numeric information in XML for small to medium field models
However for larger models the preferred method is to store numeric data in HDF5 with
spatial properties and identifiers stored in the XML document
104
Spatial representation
3D Space 2D Space 1D Space
Frame of
reference
embed embed embed
Consist
3D Cell
Solids
2D Cell
Face
1D Cell
Edge
0D Cell
Vertex
3D Cell
Primitives
2D Cell
Primitives
2D
Interpolating
function
2D User
defined
function
1D Cell
Primitives
1D
Interpolating
function
1D User
defined
function
Point
Consist Consist Consist Consist
Consist
s of
Consist
s of
Consist
s of
Figure 3-15 A generalised overview of FML objects Each FML model contains a frame that may
define one to three dimensions This frame may contain different types of geometric objects depending
on the spatial dimensions
In FML an environment or a region of space is defined by a frame of reference which
establishes the coordinate system of that region By defining the coordinate system and
frame of reference it is possible to combine or transform frames relative to each other
Once a region of space has been defined in FML field data attributes and geometric
representation schemes can then be inserted into the frame
105
Figure 3-15 illustrates FML spatial entity relationships from the frame container to spatial
objects These objects are categorised according to their dimension and can be constructed
from objects of lower dimensions
Currently 3D cells do not officially support interpolating functions due to the scope of this
project However 3D interpolating functions can be constructed using similar methods as
the 2D interpolating functions to describe a cell
Frame of reference
In physics a frame of reference is defined as ldquoa set of axes which an observer can measure
the position and motion of all points in a system as well as the orientation of objects in
itrdquo[51] In FML a frame is used to represent a region of space in which an object can
reside This modular approach allows spatial data to be edited or combined across different
FML documents
Coordinate systems
A coordinate system is necessary to precisely define fields over that space As such each
Frame is required to define the coordinate system of that space by specifying each
dimension and the name given to it By default FML supports the standard Cartesian xyz
naming of coordinates for geometric objects Different naming of coordinates can be
mapped to the xyz in FML The time dimension may also be declared if spatial objects are
time dependent
383 Geometric modelling
Geometric modelling is concerned with the mathematical representation of geometric
objects such as curves surfaces or solids by providing a complete flexible and
unambiguous representation of that object This representation can then be used to
visualise modify or analyse parts of a model
There are a number of geometric modelling forms which can represent information directly
without deviation where additional information can be derived Standard forms include
wireframe modelling surface modelling solid modelling and non-two-manifold solid
modelling
106
Developed in the early 1960s wireframe modelling was one of the earliest forms of
geometric representation using vertices and edges However this form representation is
incomplete and possibly ambiguous[52]
Surface modelling was developed in the late 1960s to succeed wireframe modelling This
method includes the representation of surfaces however a major downside of this method
is the lack of integrity checks or explicit information about connectivity[52]
Created in the early 1970s solid modelling guarantees a closed and bounded geometric
object and provides a complete description of the object[53-54] Solid modelling provides
many advantages over surface modelling It is able to distinguish the outside and inside of a
solid allowing the ready analysis of volume center of volume or moments of inertia etc
Solid modelling is often known as ldquotwo manifold solid representationrdquo since every point
on the surface is connected to the topological equivalent of a 2D disk
Non-manifold modelling[55-56] improves on solid modelling by removing the constraint
on the topological equivalence It contains all the features of wireframe surface and solid
modelling in a unified representation
Non-two-manifold representation is considered to be superior and more flexible than solid
modelling It has the ability to represent a wide range of complex objects but at the
expense of increased complexity and size
384 Solid modelling methods
Solid modelling is generally performed using one of three model types decomposition
models constructive models and boundary models
107
Decomposition models
Figure 3-16 A decomposition geometric model is where the geometric object is constructed using finer
geometric elements
Decomposition models represent geometric objects through the use of elements by
subdividing the space of the object as shown in Figure 3-16 There are a number of
different types of decomposition models including exhaustive enumeration boundary cell
enumeration and cell decomposition[52]
Exhaustive enumeration
Exhaustive enumerations use uniform size and orientation non-overlapping cubes to
represent geometric objects This method is used in finite element meshing and medical 3D
representations It has some advantages and disadvantages including the fact that
exhaustive enumeration is an approximation scheme but is unambiguous and unique for a
given object in a fixed space By subdividing an object into elements the memory storage
requirement is significantly larger than other representation methods[52]
108
Boundary cell enumeration
Similar to exhaustive enumeration boundary cell enumeration only represents boundary
regions The advantages of this approach are the increased memory efficiency and Oct-
treeQuad-tree representation used which leads to a much more efficient computation of
area and integral evaluation of a region This method is often used in medical applications
and sonar imaging[52]
Cell decomposition
Unlike exhaustive enumeration cell decomposition can use unit cell types other than
uniform cubes This allows geometric objects to be constructed from different cell types to
create an unambiguous non-unique but concise representation of the geometric object
The unit cells in this approach must meet at a vertex edge or face can be parameterized
instances of generic cells and be disjoint and non-overlapping
This method is very general and accurate with a much more efficient memory foot print
than exhaustive enumeration This approach is often found in finite element meshing
scientific visualisation etc [52]
109
Constructive models (constructive solid geometry)
Figure 3-17 Constructive models are constructed using operations In this example a circle is
embedded on a square to create a new geometry
Constructive modelling is concerned with Boolean operations of geometric primitives as
shown in Figure 3-17 These operations include union intersection difference etc for
Boolean operations sweeps rotate etc for modification operations These operations can
be performed on geometric primitives such as cubes spheres and squares Complex
geometric objects can be constructed from simple primitives this information is often
stored as a CSG tree where terminal nodes are geometric primitives and non-terminating
nodes are Boolean operations
The main advantage of CSG is its simplicity which guarantees validity conciseness and
computational efficiency Disadvantages include non-uniqueness no explicit information
110
about boundaries and final domain information and the complexity of the object can be
hindered by the choice of available primitives
Boundary representation modelling
Figure 3-18 A boundary representation model is a geometric object defined by its boundary and
geometric objects which are dimensionally less than the model itself
In this representation geometric objects are described using boundary elements as shown in
Figure 3-18 For 3D objects the model would be constructed of faces boundaries and
points and similarly for 2D objects boundaries and points Boundary representation is an
explicit representation which is closed bounded and orientable
There are two types of information stored in boundary representation topological and
geometric data Geometric information describes an object in relation to the spatial
dimension eg its location and size These objects include points curves and surfaces
Topological information is an abstract description of the model which can be derived from
the complete geometric information Topology describes the adjacency information
between geometric objects including proximity and grouping information Typical
topological elements include
111
- Vertex a point in space which may lie on a surface or edges
- Edge a non-self intersecting curve bounded by two vertices In two-manifold
boundary representation an edge is also bounded by two faces
- Loop an ordered sequence of vertices and edges creating a non self-intersecting
closed curve
- Face a non self-intersecting surface bounded by one or more loops The number of
faces is equal to the number of peripheral loops
- Shell a collection of ordered oriented faces that forms the boundary of a single
closed volume (region)
- Region a unique identifiable volume in space In general there is one global
region which is infinite and can contain a number of finite regions
- Model the modelling space which can contain one or more regions
Overview
The geometric modelling forms described above can be classified into three criteria
- Boundary or volume based whether a object is specified by its boundary or by its
volume
- Evaluated or non-evaluated describes roughly the amount of information required
to specify an object
- Object or spatially based whether a geometric object is described by its actual
shape or is characterized by the spatial coordinate system
Based on these criteria the modelling form can be separated into two tables as shown
below in Table 3-7 and Table 3-8[52]
112
boundary based volume based
spatial based Half Space Oct-tree
object based Euler Operators CSG
Table 3-7 Unevaluated geometric representations
boundary based volume based
spatial based Boundary Cell Enumeration Cell Enumeration
object based Boundary Representation Non-parametric primitives
Table 3-8 Evaluated geometric representations
In the case of FML the requirement to maintain information about domains boundary or
surface objects rules out unevaluated forms of geometric modelling To provide a greater
flexibility FML is designed to support multiple modelling forms including boundary
representation (surface representation or the stricter non-two manifold solid modelling) and
cell enumeration (mesh) Both boundary and mesh representation are common and popular
formats used widely in CAD and scientific visualisation Boundary representation methods
can be more onerous to implement than mesh models however the size of a boundary
representation model may be significantly less than that of a mesh model particularly for a
large complex models Boundary cell enumeration and non-parametric primitives (limited
to the primitive objects defined by the FML specification) can be described using FML
however there is currently no support for it in the application toolkit due to the limited
scope of this project and as such these are not commonly used method in the MML
framework
In finite-element analysis geometric objects are required to be converted into a mesh
format Storing a geometric model using boundary representation delegates the meshing of
that model to the application layer This flexibility allows applications to choose meshing
options If the geometric model is stored as a mesh model the FEM solver will have to use
the predefined mesh to solve the model However complex anatomical objects can be more
difficult to implement using boundary representation whereas mesh representation
provides a simpler descriptive method for complex geometry
113
385 Data fitting methods
Interpolating functions are useful for describing a geometric object from a set of spatial
data points There are number of interpolating methods used to fit curves and surfaces
FML will support rational Bezier and B-Spline curves and surfaces due to their popular
usage However FML also provides a flexible mechanism for user-defined interpolating
functions where the basis function is defined in the ltdeclarationgt branch which can later
be referenced
Property Hermite-
Coons
Bezier Composite
Bezier
B-Spline NURBS Ferguson
Ease in geometric
representation
med high high high high low
Convex Hull no yes yes yes yes no
Ease in creation med med med high high low
Local Control no no complex yes yes no
Accuracy med high high high high med
Interpolation ease med med med high high med
Generality med med med med med med
Popularity low med med high high low
Table 3-9 Comparison of curvesurface methods[52]
In a comparison of curve and surface methods by Nicholas Patrikalaskis[52] the strength
and weakness of common interpolation methods were identified including Hermite-
Coons[57] Bezier BSpline and Ferguson His comparison noted the strength of Bezier and
B-Spline for geometric representation interpolation and popularity (industry and
STEPPDES standard) A summary of his finding is illustrated in Table 3-9
Commercial solvers and academically available solvers such as COMSOL Multiphysics38
CMISS39
and Continuity40
can use interpolating basis functions to create geometries
Providing standard interpolating methods such as BSpline or Bezier functions as well as
38
COMSOL Multiphysics v 34 COMSOL AB Palo Alto CA 39
httpwwwcmissorg 40
httpwwwcontinuityucsdedu
114
user defined functions will provide the FML basis for describing geometric models for
available solvers An overview of common data fitting methods is provided in Appendix E
115
386 FML cell objects
In FML cells are the basic fundamental objects These are defined as a topology along with
an ordered list of points The topology of the cell can vary in dimension independent of the
spatial dimension For example lines polygons or pyramids are one two and three
dimensional topologies with points that can be declared in three dimensions[58]
In FML cells are primitive field objects that reside in a region of space Cell objects can be
simple primitives such as lines triangles etc with corresponding ordered list of points or
they can also be interpolating functions with the corresponding coefficients and basis
functions to construct the surface or curve The concept of cells forms the basis of field
objects in FML where there are two components topological data which is invariant under
any continuous transformation and geometric data which specifies the spatial information
Additional field attributes associated with geometric or topological information may also be
attached to cell objects The class layout diagram is shown below in Figure 3-19
Cell Objects
Topology Geometry
Attributes
Figure 3-19 FML abstract cell object class diagram A cell object contains two definitions topological
and geometric information Additional attributes can be attached to cells
The basic cell syntax used in FML includes
- Points
- Line
- Polyline
- Bezier curve
- B-Spline curve
116
- Triangle (tri)
- Triangle strip (tri_strip)
- Quadrilateral (quad)
- Polygon (poly)
- Bezier surface
- B-Spline surface
- Tetrahedron (tetra)
- Hexahedron
- Voxel
- Pyramid
Fields amp attributes
Attributes are used to describe non-geometric field data which can be attached to geometric
regions or objects These non-geometric fields may include force temperature stress or
conductivity etc Attribute data can be categorised into a number of different data types
including scalar vector and tensor Scalar data is a 11 data array that holds a single value
This is the simplest and most common form of attribute data Vector data is an n1 data
array which describe a magnitude and a direction this type of data can be used to describe
velocity or gradient information Tensors are complex generalisations of vectors and
matrices A rank k tensor can be considered as a data array with k dimensions For
example a rank 0 tensor is a scalar type rank 1 is a vector type while rank 2 is a matrix
Tensors can be represented using MathML MML allows vectors and tensor to be defined
as vectors and matrix but does not guarantee that these follow tensor transformation rules
This is the responsibility of the user to ensure that such representation corresponds to
physically meaningful quantities such as tensors
117
Discussion
Cell
3D Cell
Solids
2D Cell
Face
1D Cell
Edge
0D Cell
Vertex
3D Cell
Primitives
2D Cell
Primitives
2D
Interpolating
function
2D User
defined
function
1D Cell
Primitives
1D
Interpolating
function
1D User
defined
function
Point
Consist
Consist Consist Consist Consist
Consists
of
Consists
of
Consists
of
Figure 3-20 FML cell object diagram In FML cells consist of primitive objects such as lines
triangles or interpolated functions such as Bezier or BSpline curves
Figure 3-20 illustrates the cell-object relationship in FML Cells are primitive objects on
which topological objects based on dimensionality are based on In turn concrete primitive
geometric or interpolating functions are derived based on these topological objects For
example a primitive line can be considered to be an edge object a one dimensional
topological object
The purpose of defining an abstract Cell class from which primitive objects or interpolating
representations can be derived allows future extensibility and topology referencing Also tf
allows concrete cell objects to be referenced by topological objects which simplifies
interactions across different documents where the exact cell implementation class may not
be known
Cell is an abstract class that serves as the fundamental object in the FML implementation
A cell object can be used to represent a geometric entity or it can be used to represent a
118
region of space with additional field attributes attached to it These objects can then be used
by representational schemes to construct larger geometric models
387 FML document structure
-name
ltfmlgt
-name
ltimportgt ltdeclarationgt
101
1
01
1
01
ltframegt ltmappinggt
1
01
ltcell_listgt ltb_repgt ltmeshgt ltfieldsgtltdimensiongt
1
1 01 01 01 01
1
1
Figure 3-21 FML syntax class diagram
As shown in Figure 3-21 all FML document contains the root ltfmlgt with a mandatory
attribute ldquonamerdquo that identifies the document The ltfmlgt element may contain child
elements including ltimportgt ltdeclarationgt ltmappinggt and ltframegt elements
ltimportgt and ltdeclarationgt are part of the MML common syntax Specific details can be
found in their respective sections below
A ltframegt element describes a region of space It can contain field information and
geometric model representation scheme using either boundary representation ltb_repgt or
mesh representation ltmeshgt A ltframegt element must contain dimension information
about the local space using the element ltdimensiongt By default FML supports the
notation x y and z Any changes to the dimension naming should be mapped to the x y
and z identifiers Currently FML only supports Cartesian coordinate system
119
Identifiers and HDF5
FML objects can be identified through using their object name and the MML path
mechanism However an FML document can contain a large number of cell objects and it
may not be practical to provide a unique name to each one of these
FML allows objects to be identified through an index based on the position of the XML
element in the parent or position of the declaration in the HDF5 dataset This is applicable
to cells boundary representation topology or mesh representation elements
In long-handed notation the index path system requires the user to list out the complete
XML or HDF5 path
- cell_listdim_xcells_class_list_containercell_class_id[index]
- b_reptopologyadjacencytopo_class[index]
- meshtopo_listtopo_class[index]
However the long-hand notation can be mapped to simpler path system
- dim_xcells_class_list_containercell_class_id[index]
- b_reptopo_class[index] (vertex pvertex pedge edge face)
- meshtopo_class[index] (vertexedgefaceelement)
For example
- dim_2bezier_surface_listbezier_surface[3]
- b_repface[2]
- meshvertex[3]
An exception to this rule is point objects which can be simply referred to as
- pt[index]
For example as shown in the summarised code below
ltfmlgt ltframegt ltcell_listgt
120
ltdim_0gt ltpt_listgt ltptgt ltptgt ltpt_listgt ltdim_0gt ltdim_1gt ltbezier_curve_listgt ltbezier_curvegt ltbezier_curvegt lt bezier_curve_list gt ltdim_1gt ltcell_listgt ltframegt ltfmlgt hellip ltmodelmlgt hellip ltboundary_groupgt ltgeometric_propertygt
ltedge ref=rdquofml_modeldim_1bezier_curve_listbezier_curve[2]rdquogt ltgeometric_propertygt ltboundary_groupgt ltmodelmlgt
Bezier curves can be referenced by using ldquodim_1bezier_curve_listbezier_curve[index]rdquo
Point objects can simply be referred to as ldquopt[index]rdquo by the referencing objects
In certain cases Cell object property values may have to be accessed and referenced for
such as the values of an objectrsquos x y or z coordinate This can be achieved using ldquoobj_idxrdquo
ldquoobj_idyrdquo or ldquoobj_idzrdquo respectively
ltframegt
A ltframegt element is considered to be a region of space in which geometric objects can
reside A ltframegt element must declare the attribute ldquonamerdquo with a unique and legal
identifier Each ltframegt element must declare dimension information through the
ltdimensiongt branch Cell objects are stored in ltcell_listgt while specific geometric model
information are stored in ltb_repgt for boundary representation or ltmeshgt for mesh
models The ltfieldsgt branch contains field attribute information which may be attached to
121
cell objects If applicable each frame should contain one geometric descriptive scheme that
describes how the cell objects forms a geometric model
The general syntax for ltframegt elements is
ltframegt ltcell_listgt ltb_repgt ltmeshgt ltfieldsgt ltdimensionsgt ltframegt
Conceptually a frame serves as a container This allows the construction of complex
models based on components where different frames are mapped to create larger and more
complex models
ltdimensiongt
The ltdimensiongt element encapsulates the dimensional information about a ltframegt
including spatial coordinate names time and dimension size ltdimension_elementgt is used
to describe a coordinate axis Each ltdimension_elementgt must declare the attribute
ldquonamerdquo By default FML uses the names x y z and t (spatial and time dimensions) which
are commonly found as attributes in ltptgt or ltcontrol_pointgt elements (these variables
may be referenced by other objects unless specific dimension names are declared) The
dimensional elements are mapped to the default attributes depending on their position
within the ltdimensiongt branch
Custom dimension names may be used in cell objects instead of mapping the
ltdimensional_elementsgt to the (xyz) annotation This is useful for dimension declarations
greater than three dimensions For example to define an i j k Cartesian coordinate system
the following template may be used
ltframegt by default dimension elements are mapped to xyz depending on index position
ltdimensiongt ltdimension_element name=igt ltdimension_element name=jgt
122
ltdimension_element name=kgt ltdimensiongt ltcell_listgt ltdim_0gt ltpoint_listgt
Using default attributes mapped to dimension element position ltpt x=0 y=0 z=0gt Direct mapping to axis ltptgt ltdim ref=igt0ltdimgt ltdim ref=jgt0ltdimgt ltdim ref=kgt0ltdimgt ltptgt ltpoint_listgt ltdim_0gt ltcell_listgt ltframegt
ltcell_listgt
Cells are contained in the container ltcell_listgt and are organised according to their
dimension (Basic FML cell objects are listed in Table 3-10) Objects with dimension of
zero are placed within ltdim_0gt dimension of one into ltdim_1gt dimension of two into
ltdim_2gt dimension of three into ltdim_3gt Any object with a dimension higher than
three is stored in ltdim_ngt Each object itself is contained within an ltobject_listgt
container (where object is the name of the class id) below each dimensional category It is
possible to separate the same object class into different ltobject_listgt containers For
example
ltcell_listgt ltdim_0gt ltpt_listgt ltptgt ltptgt ltpt_listgt ltdim_0gt ltdim_1gt ltbezier_curve_listgt ltbezier_curvegt
ltbezier_curvegt
123
ltbezier_curve_listgt ltdim_1gt ltcell_listgt
Points (ltptgt) are the fundamental cell objects which define a zero-dimension object in a
region ltcontrol_pointgt is similar to point but with an additional attribute of ldquoweightrdquo It is
used primarily in Cell objects that require a weight attribute It should be noted that
ltcontrol_pointgt is equivalent to ltptgt with an attribute of weight declared
Dimension Name XML Tag
0 points ltptgt
control points ltcontrol_pointsgt
1 line ltlinegt
Rational BSpline
Curves ltbspline_curvesgt
User Defined
Function ltfield_functiongt
Rational bezier curves ltbezier_curvesgt
polyline ltpolylinegt
2 Rational Bezier
surface ltbezier_surfacegt
BSpline Surface ltbspline_surfacegt
polygon ltpolygongt
Triangle Strip lttri_stripgt
Bezier triangles ltbezier_trianglegt
Triangle lttrigt
quadrilateral ltquadgt
User Defined
Function ltfield_functiongt
3 tetrahedron lttetragt
voxel ltvoxelgt
124
hexahedron lthexahedrongt
pyramid ltpyramidgt
Table 3-10 Basic FML cell tags
Other supported basic cell types are listed in Table 3-10 With the exception of certain
interpolation objects such as Bezier or BSpline cells most of the primitive cells are linearly
interpolated including line triangle and tetrahedron Bezier and B-Spline cells are
interpolated according to their pre-defined basis function The user can create their own
interpolating function through ltfield_functiongt by creating a basis function in the
ltdeclarationgt branch and providing the parameter details in the ltfield_functiongt element
The cell list can be constructed from referencing an external HDF5 file in which the
numeric data is stored For large datasets this is a much more efficient and elegant solution
than storing the data directly as XML There are a number of ways HDF5 can be referenced
from the ltcell_listgt as summarised below Note that referencing may only occur at one
level
- Directly from ltcell_listgt the whole cell list is constructed from the HDF5 file
- Directly from ltdim_xgt element the cell objects below the dimension element is
constructed from the external file from the specified internal HDF5 path
- From the ltcell_id_listgt element the cells in the list container are constructed from
the referenced HDF5 path
- From a ltcellgt object the HDF5 path should point to a cell object
HDF5 referencing is achieved through the attribute ldquoext_srcrdquo Which should equal the
correct path that matches the desired level of referencing For the above cases the
corresponding HDF5 internal path should be
- ltcell_list ext_src=rdquohdf5_idcellsrdquogt
- ltdim_x src=rdquohdf5_idcellsdim_xrdquogt
- ltcell_id_list ext_src=rdquohdf5_idcellsdim_xcell_id_listrdquogt
- ltcells ex_src=rdquohdf5_idcellsdim_xcell_id_listcell[index]rdquogt
125
It should be noted that in MML HDF5 files one single cell object may be described across
multiple datasets The parsing application should be aware of this when constructing a cell
object
By default referencing data from HDF5 will use the index referencing system However
FML allows stud elements to be inserted that can provide a naming mechanism in place of
the default index referencing system for HDF5 files
For example
ltbezier_curve_list ext_src=rdquohdf5_filecellsdim1bezier_curve_listrdquogt ltbezier_curve name=rdquobc1rdquogt ltbezier_curve name=rdquobc2rdquogt ltbezier_curve_listgt
Boundary representation model ltb_repgt
Figure 3-22 Boundary representation adjacency information A face can be separated into its edge
components and into its vertex components
In FML 1D and 2D boundary representation is supported The boundary representation
scheme as shown in Figure 3-22 is stored in the ltb_repgt tag which contains topological
information for solid modelling A ltb_repgt must contain lttopologygt which than contains
ltadjacencygt information In turn an A ltadjacencygt must declare the attribute ldquotyperdquo
Valid attribute values are[59]
126
- vertex vertex adjacency (1D)
- edge edge information (2D3D)
- face face adjacency (3D)
- subdomain subdomain adjacency (1D 2D 3D)
Vertex adjacency is primarily used by 1D models only It must contain the attribute ldquoptrdquo
which points to a valid geometric point index as well as ldquouprdquo and ldquodownrdquo which refer to
the adjacent subdomains
There are two types of edge adjacency information that can be stored in ltedgegt simple
edge information about an edge and terminating vertices or edge adjacency using a
winged-edge data structure Both data types are required to declare an attribute ldquorefrdquo which
declares a valid edge object Simple edge adjacency requires the attribute ldquovtx1rdquo and
ldquovtx2rdquo that declares the indices of the terminating vertex For 2D models the ldquouprdquo and
ldquodownrdquo attribute is also required to reference the adjacent domains
A winged-edge data structure[52] contains information for four connecting edges two faces
(3d models) and two vertices The valid attributes are ldquovtx1rdquo ldquovtx2rdquo to describe the
terminating vertices and ldquocw1rdquo ldquocw2rdquo ldquoccw1rdquo and ldquoccw2rdquo to reference the four
connecting edges 2D models the attributes ldquouprdquo ldquodownrdquo are required to reference the
adjacency domain names In 3D models the attributes ldquoface1rdquo and ldquoface2rdquo are also
required to describe the adjacency faces
Face adjacency is stored in the ltfacegt element which describes a face in relation to its
bounding edges and domains The required attributes are ldquorefrdquo to reference the surface
object and ldquouprdquo and ldquodownrdquo to reference the adjacent domains The bounding edges are
stored as child ltedgegt elements these ltedgegt elements are only required to declare the
ldquorefrdquo attribute
Subdomain adjacency information describes the bounding elements of a subdomain
Although this information can be derived from other adjacency information it is however
convenient to have the evaluated information stored The bounding elements (ltvertexgt for
1D ltedgegt for 2D ltfacegt for 3D) are stored as child elements of ltgeometric_entitygt
127
ltgeometric_entitygt must declare the attribute ldquonamerdquo which references the name of that
subdomain
For a 1D model the adjacency information required is edge and subdomain For 2D
models the adjacency information required is edge and subdomain
A simple 1D line geometric model with three domains is presented here Using the
boundary representation model
ltfml name=geom1gt ltframe name=globalgt ltdimensiongt ltdimension_element name=xgt ltdimensiongt ltcell_list tolerance=60E-11gt ltdim_0gt ltpoint_listgt ltpt x=00gt ltpt x=02gt ltpt x=04gt ltpt x=06gt ltpoint_listgt ltdim_0gt ltcell_listgt ltb_repgt lttopologygt ltadjacency type=subdomaingt ltgeometric_entity name=dom1gt ltvertex pt=0gt ltvertex pt=1gt ltgeometric_entitygt ltgeometric_entity name=dom2gt ltvertex pt=1gt ltvertex pt=2gt ltgeometric_entitygt ltgeometric_entity name=dom3gt ltvertex pt=2gt ltvertex pt=3gt ltgeometric_entitygt ltadjacencygt ltadjacency type=vertexgt ltvertex down=NONE pt=0 up=dom1gt ltvertex down=dom1 pt=1 up=dom2gt ltvertex down=dom2 pt=2 up=dom3gt ltvertex down=dom3 pt=3 up=NONEgt
128
ltadjacencygt lttopologygt ltb_repgt ltframegt ltfmlgt
Mesh model ltmeshgt
Figure 3-23 A 2D mesh model and the model constituents Consisting of face (2D) edge (1D) and
vertex (0D) topological objects In this example the face objects would be triangle elements edge
objects would be line elements and vertex are 0D topological objects
In FML all three dimensions of mesh modelling is supported Mesh information as shown
in Figure 3-23 is stored in the ltmeshgt branch which contains a number of elements
including vertex edge face and element list as well their corresponding domain index
Neighbourhood information can also be stored although this is optional
129
ltidentifiergt provides an optional mapping mechanism that references the domain index of
mesh to a string name The ltidentifiergt is separated into ltvertex_idgt ltedge_idgt
ltface_idgt and ltelem_idgt elements Each of these contains a ltname_mapgt tag that
declares the attribute ldquonamerdquo whose value is the domain string name as well as the attribute
ldquoindexrdquo which specifies the index of that domain
0D 1D 2D and 3D cells are stored in ltvertex_listgt ltedge_listgt ltface_listgt and
ltelem_listgt respectively using the appropriate Cell object The only additional attribute in
these is ldquodomainrdquo to specify the domain to which these elements belong
Neighbourhood information is encapsulated within the ltneighgt branch or through the
predefined neighbour attributes of the cell object such as ldquoneigh1rdquo ldquoneigh2rdquo etc to describe
the neighbouring element index
In practice geometric points of a mesh model are stored in the ltcell_listgt The mesh list
declares the relevant primitive cells which make up the model and references those points
from ltcell_listgt for the cells in ltvertex_listgt ltedge_listgt ltface_listgt and
ltelement_listgt
1D models require ltvertex_listgt and ltedge_listgt to be declared 2D models require
ltvertex_listgt ltedge_listgt and ltface_listgt to be declared 3D models require
ltvertex_listgt ltedge_listgt ltface_listgt and ltelem_listgt to be declared
Sample syntax for using ltmeshgt is given below
ltmeshgt ltidentifiergt ltvertex_idgt ltdomain name=xx index=1gt ltvertex_idgt ltedge_idgt ltface_idgt ltelem_idgt ltidentifiergt ltvertex_listgt Vertex reference ltvtx pt=1 domain=1gt OR direct declaration
130
ltpt x= y= z= domain=1gt ltvertex_listgt ltedge_listgt ltline pt1=1 pt2=2 domain=1gt ltpara value=0001gt ltlinegt ltedge_listgt ltface_listgt lttri pt1=1 pt2=2 pt3=3 domain=1gt ltpara value=0001gt lttrigt ltface_listgt ltelem_listgt lttet pt1=1 pt2=2 pt3=3 pt4=4gt ltpara value=0001gt lttetgt ltelem_listgt ltneighgt lttet ind=1 neigh1=2 neigh2=3 neigh3=4 neigh4=5gt ltneighgt ltmeshgt
Using mesh representation for the same geometry described in the boundary representation
example (one dimension 3 domain geometry)
ltfml name=testgt ltframe name=Meshgt ltdimensiongt ltdimension_element name=xgt ltdimensiongt ltcell_listgt ltdim_0gt ltpoint_listgt ltpt x=00 y=00 z=00gt ltpt x=004000000000000001 y=00 z=00gt ltpt x=008000000000000002 y=00 z=00gt ltpt x=012000000000000002 y=00 z=00gt ltpt x=016000000000000003 y=00 z=00gt ltpt x=02 y=00 z=00gt ltpt x=024 y=00 z=00gt ltpt x=027999999999999997 y=00 z=00gt ltpt x=031999999999999995 y=00 z=00gt ltpt x=035999999999999993 y=00 z=00gt ltpt x=04 y=00 z=00gt ltpt x=044000000000000006 y=00 z=00gt
131
ltpt x=04800000000000001 y=00 z=00gt ltpt x=05200000000000001 y=00 z=00gt ltpt x=05600000000000002 y=00 z=00gt ltpt x=06 y=00 z=00gt ltpoint_listgt ltdim_0gt ltcell_listgt ltmeshgt ltidentfiergt ltvertex_domaingt ltedge_domaingt ltname_map index=0 name=e0gt ltname_map index=1 name=e1gt ltname_map index=2 name=e2gt ltedge_domaingt ltidentfiergt ltvertex_listgt ltvertex domain=0 down=0 pt=0 up=1gt ltvertex domain=1 down=1 pt=5 up=2gt ltvertex domain=2 down=2 pt=10 up=3gt ltvertex domain=3 down=3 pt=15 up=0gt ltvertex_listgt ltedge_listgt ltline domain=0 pt1=0 pt2=1gt ltline domain=0 pt1=1 pt2=2gt ltline domain=0 pt1=2 pt2=3gt ltline domain=0 pt1=3 pt2=4gt ltline domain=0 pt1=4 pt2=5gt ltline domain=1 pt1=5 pt2=6gt ltline domain=1 pt1=6 pt2=7gt ltline domain=1 pt1=7 pt2=8gt ltline domain=1 pt1=8 pt2=9gt ltline domain=1 pt1=9 pt2=10gt ltline domain=2 pt1=10 pt2=11gt ltline domain=2 pt1=11 pt2=12gt ltline domain=2 pt1=12 pt2=13gt ltline domain=2 pt1=13 pt2=14gt ltline domain=2 pt1=14 pt2=15gt ltedge_listgt ltmeshgt ltframegt ltfmlgt
132
This mesh model can be represented using HDF5 file The HDF5 document is an
automatically generated binary file and will not be shown The XML FML document is as
followed
ltfml name=testgt ltframe name=Meshgt ltdimensiongt ltdimension_element name=xgt ltdimensiongt ltcell_listgt ltdim_0gt ltpoint_list ext_src=h5_testCellsDim0pt_listCoordinateDSgt ltdim_0gt ltcell_listgt ltmesh ext_src=h5_testMeshgt ltidentfiergt ltedge_domaingt ltname_map index=0 name=e0gt ltname_map index=1 name=e1gt ltname_map index=2 name=e2gt ltedge_domaingt ltidentfiergt ltmeshgt ltframegt ltimport_listgt ltimport name=h5_test type=HDF5 xlink=hdf5h5gt ltimport_listgt ltfmlgt
FML field attributes ltfieldsgt
Field attributes can be grouped using the ltattr_groupgt element with the mandatory
attribute ldquonamerdquo This element encapsulates common geometric objects with the relevant
ltattrgt information Even without using ltattr_groupgt reference cell objects may still
attach ltattrgt with the attribute ldquocategoryrdquo declaring the attribute category to which this
element belongs as well as ldquotyperdquo which can include the value of ldquoscalarrdquo ldquovectorrdquo or
ldquotensorrdquo Scalar type can be stored in the attribute ldquovaluerdquo while ldquovectorrdquo and ldquotensorrdquo can
be described using embedded MathML An example of the ltattrgt syntax is given below
ltfieldsgt ltattr_group name=temperature units=rdquoCelsiusrdquogt ltattr type=scalar value=20gt
133
ltattr type=scalar value=21gt ltattr type=scalar value=22gt ltattr type=scalar value=23gt ltattr_groupgt ltattr_group name=velocity units=rdquometer_per_secondsrdquogt ltattr type=vectorgt ltvectorgt ltcngt13ltcngtltcngt42ltcngt ltvectorgt ltattrgt ltattr type=vectorgt ltvectorgt ltcngt31ltcngtltcngt22ltcngt ltvectorgt ltattrgt ltattr type=vectorgt ltvectorgt ltcngt11ltcngtltcngt42ltcngt ltvectorgt ltattrgt ltattr type=vectorgt ltvectorgt ltcngt4ltcngtltcngt11ltcngt ltvectorgt ltattrgt ltattr_groupgt ltfieldsgt
A field attribute can be referenced by one or multiple cell objects The cell represents a
region of space which the referenced attribute represents In the example below a cube cell
references a temperature attribute from ltfieldsgt at the index of 2
ltcubegt ltattr ref=rdquotemperature[2]rdquogt ltcubegt
It is possible to declare the attribute information directly from the cell object
ltcubegt ltattr category=rdquotemperaturerdquo type=scalar value=20 units=rdquoCelsiusrdquogt ltcubegt
Attribute objects have the option to be named and referenced directly by this name
However this is often impractical Instead an index system can be used such as
134
ldquoattr_group_id[index]rdquo
User-defined functions
Users may define their own interpolating function There are two components which must
be declared the basis function in the ltdeclarationgt branch and the ltfield_funcitongt with
the relevant parameter values in the ltcell_listgt
An example of a user-defined cubic-hermite basis function is given below More details are
available in chapter 364
ltfunction name=hermite_cubicgt ltinput_headergt ltinput_listgt ltinput name=xx type=DataType(Optional) parameteric=true(optional)gt ltrange gt_eq=5 lt_eq=-5gt ltinputgt ltinput name=pt1 type=Vector2fgt ltinput name=pt2 type=Vector2fgt ltinput name=tan1 type=Vector2fgt ltinput name=tan2 type=Vector2fgt ltinput name=t type=float parameteric=truegt ltrangegt ltapplygt ltgtgt ltcngt0ltcngt ltapplygt ltapplygt ltltgt ltcngt1ltcngt ltapplygt ltrangegt ltinputgt ltinput_listgt ltinput_headergt lt-- Math declaration that must use the above input --gt ltmathgt ltapplygt
135
lttimesgt ltapply id=cubic_hermite_basisgt ltmatrixgt ltmatrixrowgt ltcngt2ltcngtltcngt-2ltcngtltcngt1ltcngtltcngt1ltcngt ltmatrixrowgt ltmatrixrowgt ltcngt-3ltcngtltcngt3ltcngtltcngt-2ltcngtltcngt-1ltcngt ltmatrixrowgt ltmatrixrowgt ltcngt0ltcngtltcngt0ltcngtltcngt1ltcngtltcngt0ltcngt ltmatrixrowgt ltmatrixrowgt ltcngt1ltcngtltcngt0ltcngtltcngt0ltcngtltcngt0ltcngt ltmatrixrowgt ltmatrixgt ltapplygt ltvectorgt ltcigtt^3ltcigt ltcigtt^2ltcigt ltcigttltcigt ltcigt1ltcigt ltvectorgt ltvectorgt ltcigtpt1ltcigt ltcigtpt2ltcigt ltcigttan1ltcigt ltcigttan2ltcigt ltvectorgt ltapplygt ltmathgt ltfunctiongt
The field function must supply relevant parameter information which agrees with the input
declaration of the declaration basis function
ltfield_function id=bc1 fuction_ref=basis1gt ltparameter_listgt ltparameter input_ref=p0gt ltcngt1ltcngtltcngt2ltcngt ltparametergt ltparameter input_ref=p1gt ltcngt1ltcngtltcngt2ltcngt ltparametergt ltparameter input_ref=p2gt ltcngt1ltcngtltcngt2ltcngt
136
ltparametergt ltparameter_listgt ltfield_functiongt
137
39 Concluding remarks
The aim of the MML specification was to implement a temporo-spatial modelling
interchangeable representational format which can use existing specifications for
mathematical models To achieve this two representation languages have been introduced
ModelML which describes relational data and controls the interactions between different
representation languages and FML which describes field data which can be either
geometric or attribute related These representation languages are intended to provide a
framework to describe integrative biological systemsThe MML specification is by no
means complete It is currently unable to describe a number of different types of modelling
paradigms including cellular automata and stochastic models
ModelML is capable of describing complex relational data inserting field information into
differential equations describing mathematical systems and mapping of variables to spatial
regions that can span across multiple documents It supports the CellML metadata
specification and a subset of MathML syntax Using the Physiome paradigm ModelML
reuses model components described in other representation formats This encourages reuse
collaboration and efficiency
FML is designed to describe field data such as geometric models and objects using
primitive predefined objects interpolating functions or field attribute information attached
to spatial regions Currently there are two alternate field representation languages FRL[25]
and FieldML[24] FML is currently on geometric model representation and cell object
identification FRL lacks the ability to represent geometric schemes while FieldML is
currently under active development
Both ModelML and FML are proposed interchangeable representation languages aimed at
fulfilling part of the Physiome project goal to provide an integrative biological modelling
framework The MML framework is a layered architecture which consists of application
and representational formats designed to describe organ-level temporo-spatial models This
allows MML models to be used as an intermediary between different collaborating groups
and software although a wider range of application support will need to be developed
138
There are several limitations to the current ModelML and FML specification There are no
ontology supports with regards to how mathematicalgeometric models can be described
Ontology provides a set of standard terminologies to promote interoperability FML is
aimed towards representing geometric models using standard geometric modelling methods
primarily because of our choice of finite element solver FML currently only supports
Cartesian coordinate system and the field function scope can be greatly improved
For practical reasons the weak term and boundary description syntax follows closely its
representation in the finite element solver that was used in this project (COMSOL
Multiphysics) Although the MML framework allows these mathematical terms to be more
broadly described this has not been implemented yet and can be considered as a current
limitation
Field attributes are currently limited to scalarvectormatrix data types This limitation is
due to the current scope of this release
Lastly ModelML currently only supports CellML and is geared toward describing partial
differential systems This can be expanded upon to include SBML and other types of
mathematical models Although SBML and CellML can be converted from one format to
the other for certain models native support will encourage greater reuse of existing
components
139
Chapter 4 Application Toolset
41 Introduction
A number of software tools were developed for this project to facilitate the goals of the
MML framework These include an extensible authoring platform with editing and
visualisation capabilities utility tools which process the MML models from one format to
another API packages which handle the MML specification mathematical contents and
CellML input and output processing tasks
Representation languages such as CellML[16] SBML[7] or FRL[50] all provide a range of
tools to achieve the stated goal of their project Such tools can be often be categorised into
authoring tool including editing visualisation or validation capabilities API which
provides read or write functions code generators which converts the representation
language into another format simulation software that can solve the model and utility tools
that performs other functions
Figure 4-1 The MML toolset architecture layout The application toolset facilitates the transfer of data
from the data source to other layers such as external solvers
A number of applications were developed for the MML framework to facilitate its basic
goals as shown in Figure 4-1 These functionalities include API packages which read and
write MML documents in both XML and HDF5 formats Also included is an editing
platform to allow users to edit and visualise the MML models which consists of graph and
geometric based visualisation This platform also serves as an interface to other utility
packages An important factor is the ability to convert data from external sources into
MML format as well as generating code to allow the MML model to be solved by an
140
external solver application This includes importing geometric data into FML and
converting MML models into a solvable format for the finite element solver COMSOL
Multiphysics41
In this chapter we will outline the basic software methodologies and tools employed to
develop the MML application toolset We will also discuss and analyse this software in
terms of requirement design implementation overview and how these tools fit in the
overall MML framework architecture
41
COMSOL Inc Palo Alto CA USA
141
42 Authoring tools
421 Introduction
The MML framework is a hierarchal component architecture consisting of several
representation languages that can span across XML or HDF5 data formats Creating or
maintaining an MML model can be a cumbersome process This could be simplified by
using an integrated development environment application (IDE) The purpose of the IDE is
to maintain and assist in the creation and editing of a model which may span across several
documents as well as provide access to other supporting tools within one application
platform
422 Eclipse platform
The Eclipse42
framework was selected to provide the infrastructure to build the IDE
application Eclipse is a Java-based powerful reliable and an extensible rich client
platform (RCP) that allows complex applications to be developed and deployed across
multi-platform mediums quickly A major advantage of using the Eclipse platform is the
already established Java IDE application that provides a pattern of development which
allows core components to be reused to speed up the development process
Eclipse RCP possesses a range of features which makes it an ideal environment to develop
rich applications[60] It is built on components known as plug-ins These are versioned
components that can be shared among different applications or installed together with
different versions of the same plug-in allowing applications to quickly choose the
appropriate plug-in to use On top of this component model approach is Eclipsersquos
middleware and infrastructure which provide a flexible and robust user interface
application extensibility error handling and network update capability and portability
Eclipse can be adopted for any platform that can run the Sun Java43
virtual machine
Part of the infrastructure provided by the rich client platform is the user interface (UI)
support This includes a number of core UI packages that consists of the standard widget
toolkit (SWT) JFace and the workbench which includes editors and view objects SWT
42
httpwwweclipseorg 43
httpjavasuncom
142
provides a native user experience through a smooth responsive user interface design and
implementation native to the operating system which it is installed on It provides a low
level graphics library that provides UI controls such as tables text and colour support SWT
uses native widgets of the host system as much as possible which provides a library that
closely matches the look and feel of the local environment
JFace is a UI toolkit that adds structure and facilities to SWT which performs common
user interface functionality This includes providing facilities to create dialogs text support
multiple step wizard dialogs and framework for preference support in an application
Figure 4-2 The Eclipse Workbench A workbench consists of perspectives which may consist of one
editor and multiple views
The workbench provides a powerful extensible UI paradigm consisting of windows
perspectives views editors and actions as shown in Figure 4-2 It adds coordination and
presentation to JFace components and allows a complex user interface to be constructed
143
using ldquodeclarationsrdquo The workbench provides a set of extension points that allows plug-ins
to define the layout and components of the user interface declaratively This provides two
advantages it minimizes the need to code the user interface manually and decreases the
time needed to load these codes This approach has a positive impact on scalability The
only components required are loaded as indicated by the plug-in declarations As the user
interface grows more complex with more views and editors this declarative approach does
not affect the performance of the application
The workbench typically consists of a number of windows which are organised by a visual
container known as a ldquoperspectiverdquo The windows that reside in the perspective can be
categorised either as a view or an editor An editor is typically used to display the content
of the input document Modifications in the editor follow an open-save-close lifecycle
model A view is typically used to display information used to support the editor any
modification to the view content is saved immediately
423 Requirements and functionality
The overall goal of the application toolset is to provide facilities to allow the user to create
edit visualise and process MML documents To achieve this the eclipse rich client
platform (RCP) was adopted to develop an integrated development environment (IDE)
which includes a text-based editor with user interface and user assistance dialog support as
well as illustrations such as graph visualisation of the MML models and field visualisation
of the FML models The IDE also serves as an access point for other utility applications to
process the MML models
144
Figure 4-3 The text editing platform consists of a text editor and tree visualisation view of the XML
content
The text editing component provides a traditional text based editor along with user interface
and assistance dialog support as shown in Figure 4-3 The user interface support consists of
a set of views which visualise MML documents using tree table or list structures These
views complement the text based editor allowing the user to process the information more
easily The assistance dialogs provide an UI approach to edit or view MML syntax or
components These dialogs and views are also used by other components of the authoring
platform for creating and editing MML syntax with validation support that can check user
inputs as well as assist in the functionality of the MML syntax
145
Figure 4-4 The 2D visualisation platform visualises the MML model using graphs
The 2D graph visualisation platform generates a graph representation of the MML model or
components as shown in Figure 4-4 This view can be used to generate a visualisation by
providing an abstract representation of the document based on certain criteria or it can be
used to represent a complete structural representation of the MML document This package
is constructed using the JGraph Visualisation system
146
Figure 4-5 Geometric visualisation platform
The 3D visualisationrsquos platform visualise the field content of the FML document as shown
in Figure 4-5 Specifically it creates a representation of the geometric model comprised of
boundary representation or mesh models The purpose of this application is to transform the
numeric text data of the FML model into a spatial visualisation which can be assessed by
the user
These tools are housed beneath one common standalone application using the eclipse RCP
This provides a common interface to allow users to access editing and utility tools and at
the same time provides extensibility support that will allow future updates to be integrated
more easily It also provides a simpler mechanism to port applications from one type of
operating system to another Here the RCP platform supports deployment ranging from
Windows to Linux
147
424 Design
Authoring platform
The authoring application provides a platform for text and visualisation editors as well as
user assistance views such as project management or tree based model view It also
provides an interface to access any utility applications that can process the contents of the
editor To achieve this the general design of the application is broken up into a number of
areas These can be separated into the user interface design which can display the content
accordingly and controller design which controls the interaction between the UI and the
data models as shown in Figure 4-6
Editor UI
View UI
Dialog UI
Misc UI
User InterfaceController LogicData Model
Eclipse UI SWTJFaceAlgorithmsXML DOM Document Structure
Figure 4-6 Model-Controller-Viewer paradigm of the MML authoring platform The user interface is
developed using the Eclipse UI packages while the data model is implemented using the Java XML
DOM structure The controller logic controls the interaction between these two layers
The user interface design incorporates many components of the JFace toolkit which allows
the display of data in a meaningful way The UI is separated into a number of components
including editors views and dialog components The editor component of the workbench is
used to display the main representation of the ModelML or FML document This is
implemented through the text editor graphing editor and the geometric visualisation editor
Aiding the editors are views and assistance dialogs Views provide extra functionality
including a tree based navigation view or file management views Assistance dialogs
provide a user interface to view or edit elements of the MML specifications
148
The controller design focuses on the interaction and actions between the user interface and
the data model Primarily the controller algorithm implements what data is loaded into the
user interface and how the new data that resides in the UI is saved back into the data model
The controller also performs actions which are invoked by the UI which have no affect on
the data model This may include file system actions or invoking other applications These
implementations vary according to the data type and UI class However in general the
implementation can be represented as shown in Figure 4-7
User InterfaceController LogicData Model
Observe
Update
Update
Input
User
Figure 4-7 Interaction between user UI controller and data model using the observer pattern
The data model design is centred on the maintenance and the life cycle of the model The
design must also provide a basic functionality associated with the data model such as open
save or delete as well as mechanism that will allow controllers to observe the data model
for any changes This is achieved through the observer pattern which notifies observing
objects to update their viewable contents whenever the data is changed The main data
object of the authoring platform is the XMLModel class which is responsible for
maintaining the Java XML DOM class All user interfaces and controller classes interact
with this class either through observing or updating this object
The following section describes a general overview of the implementation of the main
components of the authoring platform including general class interactions work flows as
well as discussion and limitations of the designs
149
Text editor support dialog and views
Editor AbstractTextEditor
SourceViewerConfiguration
Default Eclipse Editor
implementation Contains all
the basic default action of an
Editor
Specific
implementation of
Editor Controls the presentation of
the editor and other actions
Figure 4-8 Editor class implementation overview An Editor is created by extending the
AbstractTextEditor class Additional functionality is created by extending the
SourceViewerConfiguration and other supporting classes
The Eclipse platform provides a number of components which aid in the development of an
IDE including text editing capability Text editors are created by sub-classing the
ldquoAbstractTextEditorrdquo class as shown in Figure 4-8 This class provides the basic
functionality of a text editor including the display and handling of input and output
components Customisation of the text editor is implemented through the sub-classing of
ldquoSourceViewerConfigurationrdquo These customisations include syntax highlighting
and suggestions The model object for the abstract text editor is handled by the document
provider whose main purpose is to supply the editorrsquos data model (IDocument class)
which represents the content of the editor By overriding the generic document provider of
the text editor a customised IDocument class can be created that provides extra
functionality such as partitioning support of the text content or listeners that can observe
any changes to text contents Additional implementation information can be found in [61]
150
Assistance Dialog MFormDialog FormDialog
Data Model
Generic Eclipse Dialog
Implementation with
generic functions
Specific dialog
implementation
Provides Data model
UI and validation
support
Figure 4-9 Assistance dialog implementation overview An assistance dialog is created by extending the
MFormDialog class which contains basic functionality including data model control
The assistance dialogs tools are a wide array of dialogs which provide a simple user
interface to aid in the creation editing and visualisation of specific MML syntax The
foundation of the assistance dialogs are the ldquoFormDialogrdquo abstract class (Figure 4-9) that
provides basic functionality for dialog handling including creation of the visual components
and basic buttons such as ldquookrdquo and ldquocancelrdquo A specialised abstract class was built on top of
the FormDialog class to provide specific functionality required by the assistance dialogs
that is the ldquoMFormDialogrdquo abstract class The extra functionality includes data model
handling and observation Any changes to the XML data model will notify the dialog to
update their user interface The MFormDialog also provides user interface creation and
loading algorithms which control when the user interface is constructed and how and when
data is loaded into the user interface as well as dialogs attributes which control basic
behaviour such as creating a new syntax editing a syntax or view-only mode during the
creation and destruction phase of the dialog life
The implementing dialog extends upon the ldquoMFormDialogrdquo class and must provide the
data object (ie XML element) user interface implementations any validation rules if
applicable and the data loading algorithm These dialogs can be used by any component of
the authoring platform provided that the data model and behavioural attributes are supplied
Views are a window component of the Eclipse Workbench In the authoring platforms they
are used to observe the active editor content and generate additional information
151
accordingly Views are created by sub-classing the ldquoViewPartrdquo class and providing
additional information such as user interface and data loading algorithms to construct the
views A list of views available is listed in appendix D
Graph visualisation
This editor provides a 2D structural or simplified representation of the MML model using
graph visualisation A graph is a collection of nodes or vertices as well as edges which
describe the relationship between different nodes This provides an alternative to the text
editor by providing a simpler method for the user to view or comprehend a model The
graph editor can be separated into the components shown in Figure 4-10 The first of these
is the JGraph graphing package which provides the overall graphing framework and the
foundation of the graphing editor The JGraph package consists of two sub-packages an
open source JGraph swing component which provides a powerful and feature rich Swing
based graphing toolkit and the Layout Pro package which provides layout algorithms for
the JGraph edge and vertex objects The second component is the MML Graphing package
which implements the graph generations including the data handling and layout algorithms
The graph visualisation is than attached to the Eclipse UI such that it can be displayed
within the authoring platform
Graph Generator
ILayout
ControlObject
Vertex
JGraph
1
1
1
1
1
Figure 4-10 The graphing package implementation overview The graph generator utilises the JGraph
package which provides core functionality to draw and maintain the graph and the graph layout
routing The ILayout abstract classes describe how layouts are populated and constructed
152
The MML graphing package is responsible for generating graphs associated with the MML
specification using the JGraph package It has a number of components including the graph
generator class which serves as the main interface for the MML graphing package the
layout generation classes graph object classes and utility classes
ModelML Based Graphs MML Model Overview
ODE System centric
System centric
Grouping centric
FML Based Graphs FML Overview
Geometric topology
CellML Based Graphs CellML Structure Overview
CellML equation summary with unit checking
Table 4-1 Graph layout summary available in the graph visualisation editor
The graph generator is responsible for receiving the input data model graph parameters and
attributes and invokes the appropriate handlers to generate the desired graph visualisation
based on this data The handler component consists of the graph layout classes vertex and
control objects These classes construct a graph representation based on the input data
model using vertices and control objects The list of layout algorithms is listed in Table 4-1
Vertices objects describe how a vertex in the graph is visualised including its shape and
colour Control objects provide the text information describing what text should be inserted
into the vertex In general each MML syntax has a specific implemented control object
which describes what text information is generated Once the graph information is
generated it is passed to the JGraph package where it is drawn Once the graph generator
constructs a graph layout using the layout classes based on the input parameters this
information is passed to the JGraph package where the actual visualisation occurs
The graph generator is also responsible for implementing other functions such as input and
output handling This includes associating graph nodes to the appropriate assistance dialog
or creating and handling the visualisation object lifecycle
153
Geometry visualisation
The geometric visualisation editor provides a geometric representation of the FML models
In its numeric text form this data is difficult to understand and visualise The editor
provides a viewing platform to overcome this problem written using the Java3D package
Renderer
Render Controller
Environment Controller
Loader Controller Pipeline
1
1
1 1
Java3D
Figure 4-11 Geometric platform implementation overview
The Java3D package creates a virtual universe from a scene graph A virtual universe is a
collection of objects that are to be rendered The scene graph is composed of nodes and
arcs A node is a Java3D object such as geometric objects sound light locations and other
audio or visual objects These nodes are connected by ldquoarcsrdquo which define the parent-child
relationship between the nodes that forms a tree structure The Java3D package provides a
simple and powerful API to construct a visualisation application These include basic
geometric classes to render geometries and support classes that provide input and output
handling of the virtual universe
The class layout of the visualisation platform can be summarized in Figure 4-11 The
Renderer is the main class responsible for taking the input data and invoking the
appropriate handlers These handlers include ldquoEnvironmentControllerrdquo responsible
for setting up the environment such as the supporting user interface and camera control
The ldquoRenderControllerldquo class is responsible for rendering controls such as keeping
track of which objects are loaded and when to display them On the other hand
ldquoLoaderControllerrdquo class is responsible for controlling what is loaded and rendered
154
Geometry Kernel Data
XML Data
Invoke Loader
Setup Enviroment Controller
Setup Render Controller
Finalize Scene Graph and display
User Interaction
Convert to Geometry Kernel Data type
Pass data into specific loader and
load it into scene grap
Figure 4-12 Geometry platform workflow How data is inserted analysed and displayed
The Renderer uses the Geometry Kernel IData and IBaseModel data structure FML
documents are converted to IBaseModel data structures using the Utility package In this
format the data is sent to the loader controller which invokes the appropriate loader for the
IBaseModel The loader than extracts the appropriate IData objects and sends it through the
processing pipeline In this pipeline the data objectrsquos numeric and metadata information is
extracted and used to generate a Java3D shape object and extra visualisation such as text or
control points This process continues until the scenegraph is populated Once the loader is
complete the RenderController and EnvironmentController are invoked
Each controller populates its data structure information or attaches additional visualisation
to the scene graph to construct an overall scene This process is summarized in Figure 4-12
An editor was implemented to house the geometric visualisation responsible for the
lifecycle of the renderer and data structures The editor also provides an interface to access
renderer methods to manipulate or access internal data structure information
155
43 Utility tools
Import Export Code Generator
Intermediary Data structure
Applications
Comsol
Matlab
Utility Applications
Solvers
Generate
Code for
solvers
InputOuput
Access
CellML
MMLData
Representation
FormatsOther
Figure 4-13 Utility tools are used to facilitate transfer of data from one format to another or to
provide other functionalities for applications such as general API access to data structures
The MML framework is intended to be an intermediary representation language that
transfers information between different sources Data can be generated from one
application stored in MML specifications and generated into another format for another
application as shown in Figure 4-13 Currently there is a need to convert geometric field
data into FML and also generating usable code that can be solved from an MML model
consisting of ModelML FML and CellML
The utilities package is a collection of classes which aids in the conversion of the data
These classes convert one specific data format into MML or conversely MML
specification into specific solvable scripts The utility package also contains a number of
different intermediary data structures used to represent MML and CellML models These
intermediary data structure were implemented primarily for two main purposes Firstly to
store an analysed format of the exchange language so that it can be validated or processed
The intermediary data structure then stores the final processed form of the exchange
language and provides an API to access the data Secondly the data structure minimizes
any changes to the application codes if the specification were to be changed serving as a
156
decoupling mechanism to protect the applications development from the specification
development
431 Requirements and functionality
The requirement of the utility toolsets can be categorised into a number of areas These
include code generation from MML models or CellML documents into secondary formats
such as COMSOL or Matlab files A number of steps are required to achieve the desired
functionality including the capability to parse valid ModelML FML or CellML documents
into an intermediary data structure where the information can be accessed and processed
according to the MML specification rules Once the processed information has been
acquired a valid executable script is generated for the relevant solver These applications
are central to the MML framework as they facilitate the representation of data and the
application of this representation
The second area of the utility package is geometric related conversion including the
conversion of data between the COMSOL geometry format into FML and vice versa The
current requirement is to support 1D and 2D boundary representation models and 1D 2D
and 3D models for mesh models in COMSOL geometric format These data formats are
parsed into intermediary data structures found in the Geometric Kernel package The utility
applications then convert the geometric kernel package objects into other formats This
intermediary approach allows additional geometric formats to be supported at a later stage
Another category in the utility package is the data structures and relevant handlers which
serve as intermediaries between different established data formats These data structures
include ldquoModSourcerdquo responsible for creating an internal structure of an MML model
and ldquoAbstractModelrdquo that is responsible for parsing the MML model and processing it
into this intermediary data structure Processing may include unit conversion such that a
CellML model is unit equivalent with other CellML models before it is inserted into the
intermediary data structure
The CellMLHandler is responsible for parsing CellML documents into an internal data
structure that can be appended to the ModSource data structure Intermediary data
structures are required for the multi-layer specification approach in the MML framework
157
In its raw XMLHDF5 format the data can be spread around different locations and
sources By converting this raw data into a centralized and processed form using
ModSource and CellMLHandler it provides a simpler method for applications to
access model information The intermediary data structure also allows the data to be
validated or manipulated such as checking for naming collisions validating or converting
units
432 Design
COMSOL exporter (MML to COMSOL)
The MML Export utility is responsible for parsing an MML model comprised of ModelML
FML and CellML documents and generating a COMSOL solvable script using the general
PDE application mode found in COMSOL Multiphysics COMSOLrsquos Weak term
application modes are also supported to represent PDEs on surfaces edges and points
There are a number of steps involved in parsing these documents The ModelML FML and
CellML documents are parsed into their own respective intermediary data structures such as
Abstract Model Geometry Kernel data structure and CellML Handler respectively In this
format the MML Export application is able to access and modify the relevant information
such as avoiding naming collisions unit checking and correction in order to generate the
correct solvable COMSOL script Once processed into the intermediary data structures the
exporter then uses the information to construct the relevant script code
158
Comsol Exporter
Header Parser
Geometry Parser
Application Parser
Post Processing ParserIDocument
Geometry Kernel Data
Subdomain Parser
Boundary Parser
Point Parser
Figure 4-14 COMSOL Exporter package implementation overview
The MML Export application consists of a number of classes The main class is the
ldquoComsolExporterrdquo (as shown in Figure 4-14) which is responsible for invoking the
relevant data structures and sub parsers to generate the COMSOL file The sub parsers are
in turn responsible for different areas of the COMSOL Script file COMSOL script file can
be separated into header geometry application and post processing information The
parsers that handle these are HeadParser GeometryParser
ApplicationParser and PostParser respectively ComsolExporter invokes
the Abstract Model class that generates the ModSource intermediary data format from the
MML file This data structure is than passed down to the sub-parsers to generate their
relevant sections The data generated from the ComsolExport is stored in an internal
data structure called ldquoDocumentrdquo which can be then passed to other applications or
written to a file as shown in Figure 4-15
159
MML Model
ModSource Data
Comsol Exporter
Invokes Sub Parsers
Geometry Data
System Data
Mathematical Data
Relational Data
Populate Document
Structure
The MML Model is converted
into the ModSource data
structure
The ModSource data structure
is fed into the Comsol Exporter
Application
The Sub Parsers are invoked
and the different data types are
analyzed and constructed into
an executable script
Figure 4-15 COMSOL Exporter package workflow
The Geometry sub parser is responsible for handling geometric content in the COMSOL
script file There are number of options on how this geometry can be expressed depending
on the FML model type and dimension supplied The output model may be generated as an
external COMSOL geometric file using the Geometry Utility package for 1D 2D and 3D
mesh and 1D and 2D boundary representation models 1D and 2D boundary representation
models may also be constructed as commands stored in the script file The FML input
model must be a valid geometric model to be parsed in correctly The rules for valid
geometric models can be found in appendix B
The application sub parser is responsible for handling the MML mathematical content and
relational data and inserting these correctly into the COMSOL script file using the general
application format This includes mapping the ModelML system information into
application modes found in the COMSOL script as well as generating the correct header
information including state variable The application parser itself consists of a number of
sub parsers that handles different relation groups including SubdomainParser for
subdomains BoundaryParsers for boundaries EdgeParser and PointParser
that handles edge and point group respectively These sub parsers all share similar
functionality including handling mathematical content This may include processing and
categorising an equation into sub components such as coefficient source term flux
160
components etc and generating the correct COMSOL syntax Once the mathematical
information is correctly setup from the ModSource data structure the sub-parsers then
create the relational information between the mathematical content and the geometric
information There are a number of steps involved in this Firstly the FML geometric
object specified must be analysed to calculate the internal COMSOL geometric index
Using this index number the mathematical content can then than be linked to the geometric
object at the script level
There are some current limitations on the capability of the COMSOL Exporter related to its
capability to parse and transform CellML mathematical formulations This is due to the
limited functionality of the Mathematical parser and its ability to simplify or breakdown
complex formulations such as nested variable relationships Currently governing ODEs
expressed in CellML must be in the form where the differential terms are not expressed as a
variable and that the equation should be in its simplest expanded term For example
where
or
are not in the supported format The acceptable form
for the previous example in its expanded simplest form includes
and
Matlab exporter (CellML to Matlab)
The Matlab exporter is a secondary utility that converts a CellML document comprised of
an ODE system into a Matlab executable script The main class of this application is the
MatlabExporter which invokes the CellMLHandler to create a representation of
the CellML document with the option to validate and correct units This is then processed
to create a Matlab script file There are a number of steps in this latter process including
identifying the state variables as well as generating the ODE equation and expressions
Once these components are identified the MatlabExporter class then generates the
Matlab script function file
161
Geometry kernel
FML_IBaseModelHandler
ComsolInputHandler
Geometry Kernel
Data
ComsolMeshWriter
ComsolBrepWriter
FMLMeshWriter
FMLBrepWriter
Comsol
Geometry
File
FML
FML
Comsol
Geometry
File
Figure 4-16 Geometry Kernel utility tools facilitate the conversion of data between different formats
This figure illustrates the relationship between the formats java classes and data objects
The utility section of the Geometry Kernel package consists of applications which handle
FML and COMSOL file generation They also manges the creation and maintenance of
internal Geometry Kernel data structures as shown in Figure 4-16 The foundation of the
Geometry Kernel package are the IBaseModel and IData abstract classes which
respectively represent geometric models and field data representations (such as triangle
interpolating curves etc) The utility applications which parse external files into internal
data structures are the ldquoFML_IBaseModelHandlerrdquo and ldquoComsolInputHandlerrdquo
which parses FML documents and COMSOL geometric files respectively Once an
external file has been converted into an internal data format the utility application can then
process and convert the data into other formats Current outputs supported by the geometry
utility application are the FML and COMSOL formats The classes which handle these
formats are FMLBrepWriter FMLMeshWriter ComsolBrepWriter and
ComsolMeshWriter for boundary and mesh geometric representations
162
Converting external files into internal formats possesses a number of advantages It allows
the data to be processed prior to its import and export and the intermediary data structure
provides a buffer between the processing application and different specifications A
disadvantage of this approach is the fact that handler classes are required to be implemented
for each different type of data format Another disadvantage is the addition of an extra layer
of processing time which can be noticeable for large numeric data The java class handler
for FML and COMSOL are FML_IBaseModelHandler and
ComsolInputHandler
There are a number of rules governing how the internal data structures can be constructed
using boundary representation or mesh models FMLMeshWriter and FMLBrepWriter
are responsible for converting the internal data structure of mesh or brep objects into FML
format Similarly ComsolBrepWriter and ComsolMeshWriter classes are
responsible for converting the internal data structure into their respective COMSOL
formats The COMSOL Boundary representation writer only supports 1D and 2D models
The rules for valid geometric representation are described in appendix B
Intermediary data structures
Data Structure
API
Data Generator Application
Data Format
Figure 4-17 Intermediary data structures are used by applications to access external files
The ldquoModSourcerdquo data structure is an internal data structure used to represent MML
models This intermediary representation allows the model information to be processed
such as identifier collision checking and mathematical content parsing Furthermore an
163
intermediary data structure provides a level of decoupling between the specification and the
application as shown in Figure 4-17 providing a more efficient development and
maintenance approach
The Abstract Model application is responsible for populating the ldquoModSourcerdquo data
structure from an MML model It invokes ldquoCellMLHandlerrdquo to process CellML
documents as well as Geometry Kernel Utilities to process geometric data Abstract model
consists of classes to handle ModelML contents as seen in Figure 4-18
Abstract Model Generator
Geometry Generator
System Generator
Model Generator
Data Generator
1
1
1
1
1
1
1
1
ModSource
1
1
Geometry Kernel Data Structure
CellML Handler
1
1
Figure 4-18 Abstract model package implementation overview
The main class is ldquoAbstractModelrdquo which controls the life cycle of the data structures
and invokes different classes to handle different components of the MML model These
components can be categorised into the overall mathematical systems handled by
ldquoSystemGeneratorrdquo the parsing of the rest of the ModelML document handled by
ldquoModelGeneratorrdquo and the handling of geometric information by the
ldquoGeometryGeneratorrdquo class The workflow of how the data is populated can be seen in
Figure 4-19
164
The system handler (SystemGenerator) is responsible for parsing the overall ODE
state variables or other variable mappings described in the system elements in ModelML It
maps the final state variable names to the state variables found in imported CellML
documents It also maps any associated meta-data information related to the variables This
class is also responsible for converting units of an external model from the ratio specified in
the ModelML document This allows CellML models with variables that are dimensionally
equivalent but not equal to be used together
Figure 4-19 Abstract model package workflow for converting MML models into an intermediary data
structure
The model handler (ModelGenerator) is responsible for constructing the relational data
information and any other information that resides within the ModelML document It also
ensures that there are no naming collisions between objects that reside across different
documents The relational information is contained in the grouping elements which
includes subdomain boundary edge and point groups These groups link geometric
165
information to the system declaration and mathematical objects For subdomain groups
additional information is often included that attaches extra conditions to the mathematical
models This may include overriding declarations conductivity values external stimuli or
extra source terms These extra conditions are appended to the relational data as the group
element is parsed The model handler also parses declaration objects into the internal data
structure
The geometric handler (GeometryGenerator) invokes geometric utility applications to
handle geometric information found in FML The first step is to construct a Geometry
Kernel data structure representation of the FML document The next step is to invoke the
COMSOL Index application which maps FML geometric objects to a COMSOL based
index This index is used to identify geometric objects within the COMSOL solver
application It also allows mathematical information and other attributes to be attached to
the geometry The boundary representation COMSOL index is generated from the
ascending order of the coordinate (xyz) of vertices with edges sorted by the edge objectrsquos
degree Within class orders objects are sorted according to the ascending connecting
vertices index Similarly face object indexes are created by sorting according to the object
class degree followed by the connecting boundary edge index Subdomain object indexing
is dependent on the dimension of the geometric models and maps directly one to one to the
indices of the same dimension geometric object Mesh model object domain indices does
not require calculation In mesh models the domain indices are declared as part of the FML
document The index information can be mapped directly into COMSOL for use
ModSource
Math LibraryRelational LibrarySystem Library Geometry Library Data Library
1
1
1
1
1
1
1
1
1
1
1
Figure 4-20 ModSource package implementation overview
166
The ModSource data structure is the internal representation of an MML model with the
main class layout shown in Figure 4-20 The central structure is the ModSource class which
references a number of different classes which handle different aspects of the MML model
These include the MathBase class that contains mathematical models or objects
GeometryBase which encapsulates field related information SystemBase which
contains the mathematical ODE system information and ReferenceBase which contains
relational information between the fields mathematical and system data The ModSource
data structure provides a set of APIs to allow the retrieval of internal information for other
applications to use
CellMLHandler CellML Model
Components
Variables
Equations
1 1
1
1
Units
1
1
1
1
Figure 4-21 The CellML Handler class implementation overview
The CellMLHandler is responsible for parsing CellML documents into an internal data
structure accessible to other applications and provides an API to access these CellML
objects (CellMLHandler UML class diagram can be seen on Figure 4-21) The data
structure allows CellML objects to be searched by an identifier using the MML
specification rules Objects in CellML are identified by their component name followed by
ldquordquo and the object name If the object name does not exist then the object can be referenced
by its index using the syntax object_class[index] In general the CellMLHandler first
167
parses any unit declarations followed by the component It then populates the componentrsquos
internal structure with variables and equations with unit attached if applicable using the
MathAST structure found in the MML parser With the components populated the CellML
Handler next processes the connection elements of the CellML documents Any
relationship between variables of different components are recognized and updated
accordingly This connection signifies shared values among components The CellML
handler also provides functions that can analyse piecewise equations and check
corresponding units Because piecewise equations are conditional statements the CellML
handler provides options to evaluate these conditions such that it can store the whole
piecewise equation or the equation that satisfies only one condition The CellML handler
can also invoke unit checking and correction of the equations this is achieved by invoking
the Math Expression parser utility functions If an equation unit declaration is found to be
incorrect but equivalent (unit ratio error) a correcting ratio term may be inserted into the
equation to make the units equal
168
44 Parsing tools
MML API
XML
Document
HDF5
File
XML DOM HDF5 Obj
Application Layer
API Implementation
Raw Data File
Figure 4-22 The MML Parser API in relation to data and other applications The API facilitates read
and write access from applications to the raw data formats
The parsing package attempts to provide an application programming interface (API) to
allow applications to access and manipulate the MML documents It also maintains the data
structures and related functions for XML and HDF5 data formats as shown in Figure 4-22
A set of centralized parsing packages allows easier development and maintenance of
external applications by providing a uniform set of APIs to deal with both low level editing
of specific components of a data structure and high level editing that could span across
different areas of the one structure The centralized nature of the API and data structure
also allows development changes to be more easily propagated across applications that
adopt these packages
441 Requirements and functionality
The main requirements for the parsing tool sets include providing a set of APIs as well as
maintenance of the data structures These include providing functions to read and write
MML or CellML into an XML Document data structure implement an observer pattern on
the data structure such that any modifications will notify observers of changes as well as
functions to aid in the generation or importexport of the XML documents
169
This parser package is also required to provide API and data structure encapsulation as
well as related functions for HDF5 files The latter includes functions that read and write
numeric datasets defined for MML models
In addition to the XML and HDF5 API a mathematical parser was also developed This
includes the ability to parse MathML mathematical declarations or string based
mathematical declarations and converts these to a tree based data structure In this form the
data can be converted to MathML or string form if required This parser also provides a
unit parsing capability that validates if a unit is correct and if not tries to correct the unit if
possible The Mathematical parser also contains other utility classes including evaluation of
equations search and replace of variable names and equation identification
Another group of classes that can be considered part of the parsing package are the
Geometry data structures These serve as a faccedilade to the FML HDF5 and XML based field
data This geometry API provides a transparent method to access the numeric data of FML
regardless of whether the data is stored in HDF5 or XML It also provides algorithms for
specific functions such as Bezier or BSpline interpolating curves and surfaces
442 Design
MML parser (XML)
The MML Parser package is primarily intended to provide basic read and write capability
for the MML specification across XML or HDF5 formats (using the HDF5 parser classes)
It is also responsible for encapsulating the XML data using the Java XML Document
Object Model (DOM) The MML Parser also uses other XML tools including XML Path
Language (XPath) for data retrieval and XML Schema for validation
Document Object Model (DOM) and Simple API for XML (SAX) are the two primary
methods for reading in XML documents that have been considered for this project
DOM is a tree based parsing technique allowing a complete and dynamic access to the
whole XML document The DOM implementation provides an API to navigate the XML
document whereby DOM loads the whole XML document into memory Although this
allows quick access the load time could be significant if the document is large
170
SAX is an event driven push model for parsing XML documents The SAX implementation
interacts with the XML document as it is parsed This allows low memory consumption
However it is considerably more difficult to navigate an XML document using SAX to
modifying contents In practice SAX parsers are generally used to transform XML
documents while DOM parsers are used to navigate and manipulate these documents
Using the JAVA DOM API provides several benefits including faster implementation the
ability to store and quickly access the internal data structure as well as the ability to provide
validation capabilities The disadvantages of using Java DOM include the possibility of a
large memory foot print which could be a problem for FML fields stored in XML format
as well as inefficiencies in using a generic implementation designed for general use
XPath 20 is a WW3C defined query language which allows navigation of XML content as
well as selection of nodes or evaluation of values using path expressions A path expression
is a series of commands separated by the binary operator ldquordquo which applies the command to
the right hand side where the results are then selected by the left hand side An example
command to select a node in XML using XPath is ldquotag1tag2tag3rdquo
The core components of the MML Parser are the abstract classes ParserFactory
XMLDocument and defaultXMLWriter The ParserFactory is responsible for
creating and maintaining the data structures as well as support classes and functions It is
also responsible for opening or exporting the XML data structure into other formats Each
XML specification has its own parser factory which controls the readerwriter classes and
document structure
171
ParserFactorydefaultXMLWriter
XMLDocument Java DOM
1
1
1
CellML Factory
FML Factory
ModelML Factory
FML Worker
ModelML Worker
MMLImport
MMLDeclaration
CellML Worker
1
1
1
Vocabulary Definitions
1
1
1
1
FMLVirtualTree
1
1
1
Figure 4-23 The MML API package implementation overview The core class is the ParserFactory
which may consist of defaultXMLWriter workers
The XMLDocument class encapsulates the Java DOM API and DOM data structure It also
provides an observer pattern to the data structure which allows other classes to observe
changes to the XML data structure and propagate the changes to the relevant observers
172
The defaultXMLWriter provides a basic set of functions that updates edits or
navigates the DOM structure using a combination of Java DOM API and XPath functions
The MML Parser implementation can be categorised into CellML FML ModelML and
Common MML Syntax as shown in Figure 4-23 Each of these ParserFactory and
supporting classes provide a basic readwrite of XML syntax or higher level access
spanning across different XML syntax or HDF5 writing capabilities The MML API class
can be found in appendix D
Supporting data structures implemented in the MML Parser includes the Virtual FML Tree
structure which can span across XML and HDF5 formats The Virtual Tree allows a
representation structure to be created that allows easier navigation and access to XML and
HDF5 data structures in FML The Virtual Tree is parsed according to the cell list and mesh
element found in FML
Implementation of the MML parser package is focused on abstraction encapsulation
factory pattern and centralization of functions and specifications This approach provides
benefits in development and maintenance The encapsulation and factory approach attempts
to hide the Java DOM API and data structure allowing different DOM implementations to
be used with fewer changes to the overall code Changes to the specification can be more
easily maintained with centralized vocabulary classes and functions which can be traced to
the adapting application using this parser However there are several limitations to the
implementation of the parser package The current implementation is only focused on a
Java development environment with no consideration for or binding interface to other
platforms The efficiency of the Parser API is tied to the underlying data structure provided
by the Java DOM API and HDF5 Java Object package
Mathematical parser
The mathematical expression parser is responsible for handling mathematical content
There are two input and output types string literal (appendix B) and MathML formats The
core data structure of the mathematical parser is the abstract syntax tree The input data is
parsed into this tree and in this form other functions can be performed on the mathematical
expression The mathematical parser is built around the visitor pattern with the main class
173
being MEEParser as shown in Figure 4-24 This class is responsible for taking the
respective input formats such as String literal or XML and redirecting it to one of the sub-
parsers responsible for handling that particular format The MEEParser is also responsible
for handling the syntax tree data structure and associated functions that can be performed
on the data
MEEParser
MathASTtoMathML
MathMLtoMathAST
Abstract Syntax Tree
MathParser
MathScanner
StringScanner
11
11
11
1
1
1
1
11
1
1
1
1
1
1
Figure 4-24 The Mathematical Parser implementation overview A string input is handled by
StringScanner and subsequent classes while MathML is handled by the MathASTtoMathML and
MathMLtoMathAST classes
For a string literal input format a number of stages are required to parse the content into an
abstract syntax tree structure These stages can be broken into lexical analysis and syntax
analysis to produce a valid syntax tree as shown in Figure 4-25
174
Lexical Analyzer
Syntax Analyzer
Token stream
Syntax Tree
y = 4 + t 10
ltidygt lt=gt ltid4gt lt+gt ltidtgt ltgt ltid10gt
Input Character Stream
Figure 4-25 Mathematical Parser workflow on how a string based mathematical equation in this case
y=4+t10 is parsed and converted into an abstract syntax tree
=
+
y
4
t 10
Abstract Syntax Tree
Figure 4-26 A visual representation of an abstract syntax tree of y=4+t10
The lexical analyser takes the input string and converts it into a meaningful sequence of
ldquolexemesrdquo For each lexeme the lexical analyser generates an output token consisting of
175
token name and attribute values The token name is used during the syntax analysis and the
attribute value in conjunction with a symbol table is used in the semantic analysis The
mathematical lexical analyser uses a LL(1) context free grammar (appendix B) which is a
top-down parsing method to analyse the expression character stream The class that handles
the lexical analysis is the MathScanner
The syntax analyser converts the tokens from the lexical analyser into an intermediate tree
representation form (Figure 4-26) which represents the grammatical structure of the tokens
The class that handles the syntax parser is the MathParser
Input in MathML format can be parsed directly from MathML into a tree structure by
simply traversing the XML tags and converting the MathML Syntax into the internal
mathematical abstract syntax tree data structure The classes associated with the conversion
between MathML and the internal data structure is handled by MathASTtoMathML or
MathMLtoMathAST class
Once in the tree data structure a number of functions can be performed including
generating outputs in either string or MathML format evaluating the expression checking
for unit errors as well as utility functions such as identification validation visualisation
and searching capabilities Most of these functions traverse the tree structure using a post-
order traversal method and perform any necessary actions on the tree nodes The complete
function list can be seen in appendix D Two main algorithms will be discussed below
units checking and correction and evaluation of the mathematical expression
The evaluation algorithm can only be performed on a mathematical expression with a
logical assignment such as equals greater than Given the mathematical tree structure and
the associated variable table containing the value and description of the variable data type
(scalar vector or matrix the algorithm traverses the tree in a post order fashion as shown in
Figure 4-27 The values of the leaves are extracted and propagated up the tree with
associated operations applied according to the operators assigned to the nodes This repeats
until the value reaches the top of the tree The result of the evaluation algorithm can either
be a numeric value where the result on the right hand side is assigned to the variable on the
176
left hand side or a Boolean result which compares the left and right hand statements with
respect to the logical operator
=
+
y
4
t=5 10
Symbol Table
t = 5
50
54
54
Figure 4-27 Evaluation is performed in a post-order traversal The symbol table provides additional
data about variables (ie t=5) The leaf nodes are visited and evaluated and the results are propagated
up the tree
Units handling consists of two main functionalities unit validations and unit corrections
There are however some limitations only MathML can be used to take advantage of unit
checking as the string format does not handle unit expressions Also unit corrections can
only be performed on binary operators where the left and right hand sides of the operator
are not equal but equivalent Unit equality means that both units are the same In contrast
unit equivalence implies that both units when simplified to their base SI units are the same
but the multiplier ratio is different (eg millimetre and metre are unit equivalent differing
only in their multiplier ratio) The unit correction algorithm attempts to insert ratios on
binary operators to ensure unit equality
177
=
+
mL
L
m^3 Lm^3
=
+
mL
L
m^3 Lm^3
L
L
=
+
mL
L
m^3 Lm^3
L
L
0001
A) Unit Tree B) Unit Checked Tree C) Unit Corrected Tree
mL = millilitre
L = litre
m^3 = meter cube
Lm^3 = litre per meter cube
error
mL
mL
Figure 4-28 The unit checking process The left figure (a) illustrates a unit tree This tree is evaluated
to check for unit consistency as shown on the middle figure (b) The unit checker attempts to fix the
unit tree by inserting a ratio as shown in the right figure (c)
The classes that handle these are convertUnitTree and parseUnitTree for
validation and error checking Core data structures involved are the unitrsquos data structure and
unit SI definition list Unit evaluation algorithms handle these data structure The algorithm
includes breaking the unit down into its SI unit form performing division and
multiplication operations on two units and calculating the ratio that will equalize two
equivalent units With these basic data structures and algorithms a unit tree can be
traversed as well as checks made for unit correctness or equivalence The unit checking
algorithm is similar to the mathematical evaluation process The unit leaf nodes are visited
and compared at the binary operator nodes Once the unit operation has been calculated a
correctness or equivalence boolean flag can then be raised at the node of comparison as
shown in Figure 4-28 b In this example the m^3 and Lm^3 are compared at the
multiplication node After evaluation the correct unit at this node becomes L This result is
propagated up the tree till the next node with the plus operator where the children are
compared according to the rules found in appendix B In turn this result is propagated up to
the equal node again the children are compared according to the unit checking rules but
here the child units do not match Since the units are equivalent but not equal the unit
178
correcting algorithm attempts to adjust the right hand side of the equation to match the left
A ratio is calculated and inserted into the tree as shown in Figure 4-28 c
The mathematical parser utilises the visitor pattern which allows the addition of new
functions without modifying the data structure simplifying development of this core
structure In parsing string input formats grammar rules and syntax tree construction are
derived from compiler development techniques[62]
There are however a number of limitations with the current mathematical parser The parser
can only handle a subset of the MathML structure as defined in the CellML 11
specification and is not intended to be a fully capable mathematical package Also its
classes are also not designed for numeric accuracy associated with floating point errors
found in computing Although Java provides some classes that can deal with floating point
errors the goal of the mathematical parser was not to provide evaluation accuracy for
floating point data types such as floats and doubles
HDF5 handler
The HDF5 handler is responsible for the interaction between applications and HDF5 files
Its primary purpose is to maintain the HDF5 file data structure provide functions to write
MML format into HDF5 as well as input and output handling
179
HDF5
Object
Package
HDF5ParserIHandler
CellHandler
MeshHandler
AttributeHandler
DataHandler
1
1
Figure 4-29 HDF5 handler implementation overview The HDF5 parser utilises the HDF5 object
package which provides raw readwrite access to HDF5 files The IHandler provides functionality with
respect to the MML specification
The HDF5 Handler uses the Java HDF5 Object Package which provides a number of
advantages over the native HDF5 library written in C++ These include simplifying the
HDF5 access by encapsulating basic calls into higher functions as well as accessing HDF5
functions without directly linking or accessing the native HDF5 libraries There are
however some limitations to the object package which includes missing functions from the
native library as not all the functions are mapped one to one Furthermore not all
capabilities and features of the HDF5 libraries are supported in java in both interface or
object packages Regardless these features are not critical to the HDF5 Handler
implementation
The implementation consists of the main handler class (Figure 4-29) HDF5Parser which
is responsible for maintaining the HDF5 data structure as well as providing open and
closing functions Other classes include a set of definition classes according to the MML
specification as well as sub-parsers that deal with different aspects of the MML HDF5
specification including cells attributes declaration and mesh handlers The main functions
180
of these sub-parsers are to write numeric datasets from java primitive arrays into HDF5
files which involve the insertion and extraction of 1D 2D and 3D arrays for both integer
and double primitive types Access requirements include accessing specific sections or the
whole of a numeric dataset from a HDF5 file
Geometry API
IData
XML HDF5
In Memory
IBaseModelAPI
Data
Type
Application Layer
Figure 4-30 The Geometry Kernel API package overview This API provides a set of functions for
access to geometry data in either XML or HDF5 file or in-memory data structures
The geometry kernel package consists of a number of classes spanning across different
categories One of these includes its own data structures and API to access numeric values
associated with particular interpolating functions or geometric objects as shown in Figure
4-30 The aims of these data structures are to serve as intermediary interfaces between the
native data and the accessing application by providing an API to access algorithms or
numeric datasets This approach allows the raw data format to be hidden from the
accessing object The raw data may span across multiple sources such as XML and HDF5
or stored directly on the data structure itself Accessing these data individually would
require a number of functions However by encapsulating these function into a higher
function provides a simpler and efficient method of data access
181
The Geometry Kernel data structures can be categorised into primitive geometric objects
supported interpolating functions or user defined functions The list of the structures (Java
class representation) is
- Point
- Line
- Triangle
- Triangle Strip
- Polygon
- Tetrahedron
- Hexagonal prism
- Pyramid
- Quadrilateral
- Rational Bezier curve and surface
- Rational BSpline curve and surface
- User defined interpolating functions
The primitive objects are a set of ordered geometric points on a predefined linear
interpolated topology including lines triangles tetrahedra etc Supported interpolating
functions include Bezier curves and surfaces as well as NURBS curves and surfaces User-
defined functions consist of the interpolation function described using the MathML parser
tree structure and the related control points and constraint relation information Using this
description the functions can be evaluated along the parametric values specified in the
constraint information set
Unlike the user-defined interpolating functions both Bezier and BSpline functions have
specific algorithms implemented to quickly and efficiently evaluate the respective
functions User-defined functions are evaluated according to the basis function declared in
the MML specification which could be inefficient The algorithms used for Bezier includes
the de Casteljau algorithm and the blossom algorithm[63]
The de Casteljau algorithm can be described as follows
182
given and n is the function degree
Where
are control points of bezier functions of degree r
This recursive algorithm can be implemented as followed
double deCasteljau(int i int r double t double[] controlpoints)
if(r==0)
return controlpoints[i]
return (1-t)deCasteljau(i r-1 t controlpoints) + tdeCasteljau(i+1 r-1 t controlpoints)
The b[ab] function is known as a blossom For a bivariate piecewise linear interpolating
function
This can be used to define two interpolating function
The blossoming principle was developed by de Casteljau and Ramshaw and is closely
related to the de Casteljau algorithm The notation indicates that t appears r times The
Bezier point can be expressed using the following multi-variable function
183
where the bezier curve is defined over the parametric value a and b The de Casteljau
recursion can be expressed using blossom
These algorithms and variations of these are used to evaluate and construct rational and
non-rational Bezier curves and surfaces An example algorithm to evaluate a point on the
bezier interpolating function can be described as
double getBezierCurvePoint(double t double[] ControlPoints)
return MathUtilitydeCasteljau(0 ControlPointslength-1 t ControlPoints)
The evaluation of the BSpline interpolating function consists of three steps compute the
knot span index compute the non-vanishing basis functions and evaluate the bspline
interpolating function The algorithm used to find the span index is described below where
n should be set to m-p-1 (m is the knot count and p is degree) and U is the
knot vector
int FindSpan(npuU)
If ( u == U[n+1])
Return n
low= p
high = n+1
mid = (low+high)2
while( u lt U[mid] || u gt= U[mid+1])
if(u lt U[mid])
high = mid
else
low = mid
mid = (low+high)2
Return mid
184
The algorithm to determine the non-vanishing basis function is given in the pseudo code
below where variable i is the span index u is the input parametric term p is the BSpline
function degree and U is the knot vector The result is stored in an array N
BasisFuns(iupUN)
N[0] = 1
For(j=1 j lt= p j++)
left[j] = u-U[i+1-j]
right[j] = U[i+j] ndash u
saved = 0
for(r=0 r lt j r++)
temp = N[r](right[r+1]+left[j-r])
N[r] = saved+right[r+1]temp
saved = left[j-r]temp
N[j] = saved
Hence to find a point on a BSpline curve
CurvePoint(npUPuC)
span = FindSpan(npuU)
BasisFuns(spanupUN)
c= 00
for(int i=0 i lt= p i++)
C = C+ N[i]P[span-p+i]
The Geometry API also consists of the Geometric Model representation data structure This
data structure provides a basic set of APIs to access information including cell objects
based on dimension classification as well as algorithms associated with calculating field
information The current model representation method includes mesh and boundary
representation described by the MeshModel and BrepModel classes respectively
The design approach of this structure is to separate the raw data and algorithms and provide
a set of interfaces to simplify implementation of applications requiring access to geometric
185
or numeric data sets It also serves as a faccedilade data structure that hides the underlying
information allowing data in different formats to be readily transferred
However there are some limitations with the current implementation especially in the
efficiency of accessing a large number of primitive data structures The data can be stored
either by reference (data still on disk) or directly (in memory) There is trade off in memory
capacity with access time from the hard disk which is considerably noticeable for
geometric models containing a large numbers of geometric objects Using referencing each
access requires fetching of data from either the HDF5 or XML source which adds another
layer of latency This can be minimised by introducing buffers and multi-threading to
preload the However these approaches are currently beyond the scope of this project
186
45 Toolset summary and discussion
The aim of the application toolsets is to provide a basic range of tools that will facilitate in
the creation editing and processing of MML documents To achieve this a number of
methods tools and frameworks were used to implement the toolsets to ensure that the
package could deliver the intended functionalities As part of this project these tools and
specifications were made available on a publicly accessible website
httpmmlgsbmeunsweduau (See also appendix C)
451 Parser API
The API package is intended to provide a central interface to edit and retrieve MML
document data This package can be categorised into three main sections the MML
Specification API the HDF5 handler and the Mathematical Content Parser The MML
Specification API provides the core XML read and write capability It also provides higher
function read and write capabilities which hide the source of the content (XML or HDF5)
The HDF5 parser provides read and write capability to HDF5 documents according to the
MML specification whilst the mathematical parser is responsible for handling
mathematical contents including read write and utility functions such as unit checking
conversion and search and replace functionality
The Parser API package layer provides the basic interface between the raw document data
and the application layer By providing an API centred on a core package it allows the de-
coupling of the data and applications minimising the impact of changes from one layer to
the other
The API package developed for this project facilitates the usage of the MML specification
and framework and allows applications to be developed more quickly There are however
several limitation to the current API design The package is implemented using Java which
may be a limitation if other programming languages are used Furthermore the interface is
dependent on Java One possible solution is the OWL interface definition language (IDL)
an interface that is independent of programming languages and platforms The IDL would
be an ideal method to describe the API as a future development goal For the scope of this
187
project however the current API package provides the required functionality to implement
the application toolset
452 Authoring tools
The authoring tools are a set of editing or visualisation platforms implemented using the
Eclipse Rich Client Platform These sets of tools also include a geometric visualisation
platform to visualise FML documents and a graph visualisation platform that can provide
abstract or structural representation of the MML models or documents
The authoring tool is an important component of the MML framework for the creation
editing visualisation and processing of an MML model The Eclipse rich client platform
provides a powerful and extensible framework that allows components to be upgraded or
added more easily allowing extra functionality to be added easily as the scope of this
framework expands Furthermore the eclipse framework allows the application to be
exported into different operating systems simplifying development
However there are also several limitations with the current state of these application tools
mainly related to the feature quality of beta release software As time progresses it is
expected that the application toolset will grow in functionality and usability Including
greater support in the geometric visualisation platform will provide greater support to FML
specification development including data set or attribute visualisation and corresponding
visualisation algorithms
453 Utility tools
The utility tools provide a set of functionalities to convert data from one source to another
This includes handling and processing of MML and CellML models into internal
intermediary data structures Processing may include variable and equation naming checks
unit checking and conversions to allow different CellML models to be used together The
utility tools also allow the conversion of MML documents or standalone CellML
documents into solvable scripts as well as processing geometric data from and to FML
documents The utility programs provide a means to generate MML documents from other
formats and convert MML models into solvable scripts
188
As with the other toolsets there are also several limitations to the current utility tools
Currently the utility tools are focused on our choice of finite element solver This choice
will have an impact on geometric model processing The geometric tools currently support
import and export of FML documents from and to COMSOL geometric data structures For
mesh models other CAD Image processing software can be used that is Simpleware
ScanIP and ScanFE44
However they are required to be converted into COMSOL data
structure first and then converted into FML In future the utility applications should
expand and support other geometric programs or solver application such as CMISS or
Continuity
44
Simpleware Ltd Exeter UK
189
Part II Simulations of Cardiac Pacemaker and Atrial
Electrical Activity Using the MML Framework
190
Chapter 5 Modelling Cardiac Electrical Function An Overview
Figure 5-1 The anatomy of the heart (From [64]) SAN ndash sinoatrial node AVN ndash atrioventricular
node RA ndash right atrium LA ndash left atrium RV ndash right ventricle LV ndash left ventricle PV ndash pulmonary
veins SCV ndash superior vena cava ICV - inferior vena cava TV ndash tricuspid valve MV ndash mitral valve
and PFN ndash Purkinje fibre network
51 Introduction
The heart is a complex organ that pumps blood throughout the body Initiation of the
heartbeat typically occurs in pacemaker cells of the sinoatrial node Action potential
impulses propagate from there to the atria before reaching the ventricles To model such a
complex dynamic system a vast amount of information is required This includes
geometric field data to describe the anatomical structure of the heart as well as cellular and
biochemical mechanisms to characterise cardiac cell electrical activity
There exists a wealth of cardiac cell models from polynomial-type models to the ever
increasing biophysically-accurate models that incorporate newly identified membrane
currents With the growth and the increasing maturity of internet technology there has been
191
a drive for a standardised format to share these models including SBML CellML and
ontological definitions that attempt to link up biological information using standardised
definitions The CellML repository provides a number of curated ready to use cardiac cell
models Using the MML framework developed in this thesis these cardiac models can be
incorporated into continuum models of the desired anatomical geometry for simulation
In this chapter an overview of cardiac physiology modelling methods and models relevant
to the simulation user-case will be discussed
52 Cardiac electrical function
521 Overview
Initiation of the heartbeat occurs in specialised cells of the cardiac conduction system
These specialised cells initiate and conduct action potentials which in turn trigger the heart
muscle contraction Pacemaker cells which rhythmically generate electrical action
potentials are found in two main areas of the heart the sinoatrial node (SAN) located in the
upper right atrium near the superior vena cava and the atrio-ventricular node (AV) located
near the tricuspid valve in the interatrial septum These cells are closely associated with
conduction fibres that are capable of conducting action potentials more rapidly than
ordinary fibres - up to 4 ms compared to 03-05 ms in an ordinary heart muscle[65] The
initiation of the heart beat normally starts in the SAN spreading through the bulk of the
atria before arriving at the AV node The spread of the impulse causes the atria to contract
as a unit Once the impulse reaches the AV node conduction is delayed due to the AV
nodersquos low conductivity The impulse then travels through the atrioventricular bundle in the
interventricular septum and splits into the left and right bundle branches These branches
innervate the left and right ventricles through an extensive network known as Purkinje
fibres across the ventricular myocardium as shown in Figure 5-1 This causes the ventricles
to also contract as a unit
Intercellular communication occurs through specialised cellular connections known as gap
junctions A gap junction is formed by the pairing of cell membrane structures to
192
neighbouring cells known as connexons Each connexon is composed of six connexin (CX)
proteins Different types of gap junctions exist within the heart they can be classified as
either homotypic or heterotypic depending on whether the two connexons are of the same
or different types Furthermore the connexins determine the property of the gap junction
including the permeability of the gap junction channel The syncytical nature of the
myocardium causes the heart to activate via a propagating activation wavefront
522 The cardiac action potential
The action potential of cardiac cells occurs in several phases Like other types of excitable
cells the electrical response of the transmembrane potential is caused by the changes in cell
membrane permeability caused by the opening and closing of ion channels The ions
predominantly responsible for action potentials in the cardiac cells are sodium potassium
and calcium In pacemaker cells the action potential is initiated by the changes in the
potassium sodium and calcium membrane permeabilities The slow depolarisation of the
cell (phase a Figure 5-2) is caused by the closing of potassium channels and the short-lived
opening of the hyperpolarisation-activated channel This slow depolarisation causes the
opening of voltage gated calcium channels triggering the rapid depolarisation phase of the
pacemaker action potential (phase b Figure 5-2) There are two types of calcium channels
the T-type which opens transiently and the L-type which is longer lasting
193
Figure 5-2 Sinoatrial node action potential waveform
The rapid depolarisation phase triggers the opening of potassium channels which leads to
repolarisation of the cell action potential (phase c Figure 5-2)
194
Figure 5-3 Ventricle action potential waveform
Ventricular cell action potentials occur in four phases as shown in Figure 5-3 The action
potential itself is triggered by the opening of voltage gated sodium channels causing the
rapid depolarisation phase (phase a Figure 5-3) The depolarisation activates a transient
outward current producing a rapid repolarisation (phase b Figure 5-3) and a ldquonotchrdquo in the
action potential (phase c Figure 5-3) The remaining phase occurs in a similar process to
that of the pacemaker cells with the exception that ventricular cells have a stable resting
potential (phase e Figure 5-3)
Cardiac cells in different parts of the heart vary in size tissue conductivity and ion
channels they possess However their calcium channels are all instrumental in triggering
muscle cell contraction The general characteristic of cardiac action potentials can be
summarised as follows
195
- SAN cells are spontaneously active with a slow depolarisation phase followed by a
slow action potential upstroke
- The atria have a stable resting potential of around -90mV They are naturally
quiescent with a more rapid AP upstroke and initial repolarisation phase compared
to SAN cells
- Purkinje fibres exhibit a fast initial rapid repolarisation phase followed by a plateau
phase and then a second rapid repolarisation phase
- Ventricular cells exhibit a rapid upstroke and a much more pronounced plateau that
may last up to 500ms
The rapid upstroke in the atria and ventricle is pivotal to the conduction velocity of the
action potential that coordinates the contraction of the heart
523 Sinoatrial node structure
The sinoatrial node is located in the wall of the right atrium superior to the inferior vena
cava and extends towards the endocardial side of the crista terminalis It consists of a large
number of heterogeneous cells including central and peripheral pacemaker cells The SAN
also contains atrial cells fibroblasts and adipocytes as well as high concentration of
collagen
There are two main theories regarding the cellular organisation of the SAN the mosaic and
the gradient models[66] The gradient model proposes that there is a gradual transition from
central to peripheral SAN cells and then into the atrium in terms of cell size and ion
channel expression Central cells are smaller and have a slower intrinsic pacing rate and
upstroke velocity compared to peripheral cells as central peripheral and atrial cells has
been observed in the rabbit SAN [67] The mosaic model proposes that the cells are spread
uniformly throughout the SAN with atrial cells predominantly in the peripheral regions
The presence of atrial cells in the SAN has been confirmed by Verheijck et al [68]
196
Figure 5-4 3D reconstruction of the sinoatrial node in the rabbit heart (From [69]) SVC superior
vena cava IVC inferior vena cava Ao aorta PA pulmonary artery PV pulmonary vein RA right
atrium RV right ventricle
The Dobrzynski et al model[69] provides a comprehensive 3D structure of the rabbit SAN
as shown in Figure 5-4 In this model the peripheral cells are large and predominantly
arranged in parallel They can be defined by the presence of Cx43 connexin and middle
neurofilament (NF-M) proteins The central cells are smaller with the slower conductive
Cx45 connexin and NF-M proteins The peripheral cells constitute the main SAN impulse
exit region while the central cells are arranged in a mesh with collagen Numeric
simulations suggest that low coupling and conduction in the SAN will fail to sustain atrial
excitation Furthermore the distribution of connexins in the central and peripheral regions
197
helps to create a gradient of impulse velocity that increases from the leading pacemaker site
to the periphery and exit zones
Cell-cell electrical coupling within the SAN is weak This is an important factor in the
protection of the SAN from the hyperpolarised atrial load which can potentially suppress
the SAN This can be shown when the atrium is physically separated from the SAN which
causes an increase in its pacing rate[70] Also direct coupling of a SAN cell and atrial cell
causes the suppression of the SAN cell [71] Numeric simulations have shown that the SAN
requires a minimum size and weak interval cell-cell coupling to drive the atria Other
numeric simulations have shown that strong coupling between the SAN and the atria stops
propagation[72]
524 Cardiac arrhythmia
Arrhythmia is defined as the abnormal genesis or propagation of cardiac action potentials
This may lead to irregular contraction which in turn disrupts the blood pumping function
There are various types of arrhythmia including
- SAN dysfunction causing irregular beats including very slow pacing (bradycardia)
or very fast beat generation (tachycardia)
- Ectopics beats where the impulse is generated outside of the SAN
- Electrical blockage or conduction delays in certain regions of the heart
- Asystole where no electrical impulses are detected
Numeric simulations of arrhythmia can be carried out through either modifying the cellular
sinoatrial node model characteristics or introducing extra field components into the
geometric models to simulate ectopic beats or conduction blockage and delay
Ablation [73] is a form of therapeutic intervention that is surgically induced[74] The goal
of ablation is to restrain the possible electrical pathways by creating insulated barriers
Abolation lines have to be transmural and continuous to be effective This treatment can be
simulated by introducing spatial features into the geometric models
198
53 Cardiac modelling
531 Introduction
Van der Pol and van der Mark[75] were the first to provide a mathematical description of
the heartbeat in 1928 Since then the level of detail and complexity of cardiac models have
increased exponentially In general cardiac models can be categorised into single cell
models or continuum tissue models Single cell models are sometimes referred to as zero
dimensional or lumped parameter models as they give no consideration to spatial
information Continuum models are focused on reproducing the heartrsquos electrical activity at
a spatial level over the tissue or organ
Single cell models can be further classified into polynomial models or biophysical models
employing Hodgkin-Huxley or Markov formulations Polynomial models provide a very
simple description that attempts to reproduce the general characteristics of the action
potential while biophysical models consider the important underlying currents of the cell
membrane that constitutes the shape of the action potential Polynomial models are
generally computationally faster and more efficient however they lack the physiological
accuracy of biophysical models
Multi-cell modelling could not be achieved until the 1990rsquos[76] due to the high
computational requirements These models are based on continuum cable theory utilising
bidomain or monodomain formulations The bidomain formulation is based on the premise
that cardiac tissue consists of two interpenetrating domains the intra and extra cellular
spaces[77] This formulation is however computationally expensive The monodomain
resolves this issue by ignoring the extracellular domain effectively assuming it is shorted
everywhere to a common potential value
Single cell modelling
Single cell models can be either simple empirical models without the complex details of the
underlying ionic mechanisms or biophysical models that attempt to model the membrane
currents
199
Simple polynomial cardiac models generally consist of only a few state variables They
include the Fitzhugh-Nagumo[78-79] van Capelle and Durrer[80] Sato[81] and
Endresen[82] models These models employ only two or three ODEs and are able to
generate crude action potential waveforms It should be noted that these models are highly
computationally efficient but lack biophysical accuracy in regards to details of the
underlying currents For simulations that require detailed properties of the SAN or atria
these models are unsuitable However for instances where action potentials only are
desired such polynomial models should be considered
Figure 5-5 Equivalent circuit of excitable cell membrane
In biophysical models the action potential is the outcome of the computed underlying ionic
currents The cell membrane is modelled as a capacitor in parallel with a number of
conductance branches representing the underlying currents Shown in Figure 5-5 the
currents that flow between the intracellular and extracellular side of the circuit can be
summed up to and a capacitive component
If there is no net current flow across the cellular membrane the circuit equation can be
formulated as
(5-1)
200
where is transmembrane potential and is the membrane capacitance The Hodgkin
and Huxley[83] model was the first to provide such a model of a squid giant axon and
many subsequent models have followed the Hodgkin and Huxley approach In recent times
Markov State formulations have been adopted to model ionic currents
In the Hodgkin and Huxley formulation each time dependent membrane current is
modelled in the general form of
(5-2)
where i is the membrane current g is the maximum cell conductance h and m are gating
variables and p and q represent the number of gates that are required to reproduce the
desired kinetics is the transmembrane potential while is the Nernst equilibrium
potential of the associated ion species
The activation and inactivation gating variables are modelled using a first order differential
equation given by
(5-3)
where and are the opening and closing rates of the gating process respectively
These rates are typically empirical functions of
The Markov description of ionic currents allows the modelling of multiple states unlike
that of Hodgkin and Huxley formulations where only open and closed states are considered
Hence the Markov formulation allows for more complex state diagrams for modelling
underlying membrane currents more accurately However Markov models can introduce
more ODEs compared with the Hodgkin and Huxley form hence increasing the
computation load
The Markov formulation of a membrane current i can be written as
201
(5-4)
where N is the total number of states and is the proportion of membrane channels in
state s The are described by a system of ODEs given by equation (5-5) where g is the
conductance associated with state s
(5-5)
and
(5-6)
The and terms denotes the transfer rate between states r and s The Hodgkin-Huxley
formulation can be considered as a more particular case of the generalised Markov state
formulation
Continuum modelling
Multi-cellular modelling presents a major challenge How can millions of cells be
modelled efficiently whilst taking the underlying currents into consideration Even with the
exponential increase of computational power modelling at this scale is impractical To
overcome this rather than modelling individual cells their average properties are used In
continuum modelling cardiac tissues can be represented as bidomain or monodomain
formulation to create multi-cellular models that can be solved within a reasonable amount
of time
The bidomain formulation utilises the fact that cardiac tissue consists of two domains
representing the volume average properties of the intracellular and extracellular spaces[77]
It is based on cable theory and is a proven method to model the heart[84-85] The bidomain
202
formulation originated from the work of Hodgkin and Huxley[83] a comprehensive review
has been given by Henriquez[86]
Bidomain models are described by coupled PDEs which take into consideration the
membrane currents and intra and extracellular potentials Transmembrane potential is
defined as the potential difference between the intracellular and extracellular domains
(5-7)
where denotes the intra and extracellular potentials respectively Using the 3D
equivalent of Ohmrsquos law the current density vectors (in units of ) are given by
(5-8)
(5-9)
Where subscripts i and e denote intra and extracellular is the electrical conductivity and
Using the current conservation relationship any current that enters one domain must leave
the other thus the volume current sourcesink of each domain are equal but opposite in sign
ie
(5-10)
(5-11)
where is the volume current density (in units of ) across the cell membrane
203
Substituting into (5-8) and (5-10) gives the following
(5-12)
(5-13)
and by replacing the following equation is obtained
(5-14)
Using (5-7) this equation can then be written in terms of the transmembrane potential
(5-15)
This is known as the extracellular equation
The transmembrane current is equal to the sum of the capacitive and total ionic currents
Given that the surface to volume ratio of the cell membrane is then the transmembrane
current expressed as a volume current density ( ) is given by
(5-16)
where is the membrane capacitance
Substituting into equation (5-13)
204
(5-17)
Using equation (5-15) and substituting into (5-17) we get
(5-18)
This constitutes the transmembrane equation Equations (5-15) and (5-18) together
constitute the bidomain formulation
This can be computationally expensive A simpler approach is to simplify the bidomain into
the monodomain formulation In the latter the extracellular domain is considered to be
highly conductive ( or the two domains are considered to be equally anisotropic
( ) This allows the extracellular potential to be removed from the bidomain
formulations (5-18) to obtain
(5-19)
532 Sinoatrial node and atrial single cell models
Authors Year Species
Purkinje fibre Noble ab
1962 -
McAllister et al ab
1975 -
DiFrancesco and Noble
ab
1985 -
Ventricular Beeler and Reuter ab
1977 -
Drouhard and Roberge a 1987 -
Noble et al 1991 Guinea pig
205
Authors Year Species
Luo and Rudy ab
1991 Guinea pig
Nordin 1993 Guinea pig
Luo and Rudy a 1994 Guinea pig
Jafri et al ab
1998 Guinea pig
Noble et al 1998 Guinea pig
Priebe and Beuckelmann
ab
1998 Human
Winslow et al ab
1999 Canine
Pandit et al ab
2001 Rat
Puglisi and Bers a 2001 Rabbit
Bernus et al a 2002 Human
Fox et al 2002 Canine
Greenstein and Winslow 2002 Canine
Cabo and Boyden 2003 Canine
Matsuoka et al ab
2003 Guinea pig
Bondarenko et al ab
2004 Mouse
Shannon et al 2004 Rabbit
ten Tusscher et al ab
2004 Human
Iyer et al 2004 Human
Hund and Rudy ab
2004 Canine
ten Tusscher et al ab
2006 Human
Atrial Hilgemann and Noble ab
1987 -
Earm and Noble ab
1990 Rabbit
Lindblad et al ab
1996 Rabbit
Courtemanche et al ab
1998 Human
Nygren et al ab
1998 Human
Ramirez et al ab
2000 Canine
Sinoatrial Node Yanagihara et al 1980 -
Irisawa and Noma 1982 -
206
Authors Year Species
Bristow and Clark 1982 -
Noble and Noble ab
1984 -
Noble et al 1989 Rabbit
Wilders et al 1991 Rabbit
Demir et al ab
1994 Rabbit
Dokos et al a 1996 Rabbit
Dokos et al 1996 Rabbit
Endresen ab
1997 Rabbit
Demir et al ab
1999 Rabbit
Endresen et al 2000 Rabbit
Zhang et al ab
2000 Rabbit
Boyett et al a 2001 Rabbit
Zhang et al 2002 Rabbit
Kurata et al ab
2002 Rabbit
Sarai et al ab
2003 Rabbit
Lovell et al a 2004 Rabbit
Mangoni et al 2006 Mouse
Table 5-1 Summary of single-cell cardiac models (Updated from Wilder[87]) a) Found in CellML
repository b) Curated Version available (April rsquo09)
A comprehensive review of cardiac sinoatrial node models can be found in Wilders [87]
The first cardiac cellular model was developed by Noble[88-89] with five variables based
on a Hodgkin-Huxley type formulation As time progressed the level of complexity of
single cell models increased The Noble model was updated and subsequently served as a
foundation for other modelling developments Advances in electrophysiological
experimental techniques and computation power allowed the development of more complex
models that incorporated newly identified ionic currents New formulations for the ionic
currents were also introduced including Markov models such as Bondarenko et al[90]
Shannon et al[91] and Lovell et al[66] as well as non-deterministic stochastic models such
as the Guvera and Lewis model[92] of a sinoatrial node cell
207
The basis for the models used in this project is that they are either publically available in
the CellML repository45
or are readily accessible in a CellML format from other sources46
These models serve as a platform for simulation tests and studies using the MML
framework A list of cardiac models can be seen in Table 5-1 which also specifies their
availability on the CellML repository
The choice of models varies according to the requirements of the simulation study A
simple polynomial model may be used instead of a complex biophysical model if the aim of
the study does not require analysis or investigation of the underlying membrane currents
The tradeoffs between computational efficiency and biophysical accuracy and the
characteristics of a model must be decided by the researcher
MML framework allows the creation and simulation of spatio-temporal modular biological
models The heart is a complex anatomical structure it is composed of multiple cell types
and complex muscle fibre orientation that affects the electrical propagation It is feasible to
introduce simplified geometries valid for investigation of SAN function and cardiac
propagation instead of complex anatomically realistic representations Spatial features such
as ablation or conduction anomalies can be incorporated into 2D and 3D field models The
selection of appropriate anatomical detail is a tradeoff between computational speed and
accuracy As the geometric models increase in dimension the computational cost increases
as well
In the next chapter a profile of intrinsic cardiac cell characteristics underlying membrane
currents and propagation properties of existing CellML models will be investigated using
MML Tissue conductivity simulations will also be presented for 2D and 3D models in an
attempt to explore critical conductivity values that allow the SAN to entrain and propagate
impulse into the atria Furthermore 2D and 3D models that generate arrhythmias will be
presented using the MML framework
45
httpmodelscellmlorg 46
These include in-house CellML models developed by Dr Ben Hui from the Graduate School of Biomedical
Engineering University of New South Wales
208
Chapter 6 Cardiac Simulation Using MML
In this section we present a number of cardiac simulation test cases to demonstrate the
capability of the MML framework The purposes of these simulations are threefold
1) To demonstrate the compatibility of the framework with CellML
2) To demonstrate a workflow of increasing modelling complexity from simple setup
to the implementation of realistic geometries by using the modular approach of the
MML framework
3) To demonstrate how complex models can be constructed efficiently
There are three main simulations studies presented The first is a review of existing CellML
cardiac cell models from the CellML repository[39] and other sources[12]
The second set of simulations examines the effect of tissue conductivity on sinoatrial node
and atria models using a range of 2D and 3D geometric scenarios In this study critical
conductivity values which elicit SAN cell frequency entrainment or impulse propagation
into the atria are examined These conductivity values are dependent on the cardiac cell
models used as well as the geometric features of the spatial model
The third simulation study focuses on arrhythmia generation using the Blanc[93] model In
this simulation geometric models presented by Blanc are modified by inserting the SAN to
recreate arrhythmia scenarios in 2D and 3D spatial models An anatomically-realistic atria
model is also presented These models use the critical conductivity values from the
previous simulations as a guide
The cardiac ionic and geometric models used determine the overall computational cost for
solving the model The simulations presented demonstrate that less computationally
expensive components (ie simplified geometries or ionic models) can be interchanged and
used as a guide for more complicated setups Furthermore the modular architecture allows
these components to be constructed more efficiently
209
61 CellML cardiac cell review
611 Introduction
The CellML repository contains a number of curated cardiac cell models[20] In this
section a brief review is provided on which models from the repository47
can be used in the
MML framework as well as CellML models from another source[12] The CellML models
are checked for unit correctness and whether they can be parsed and converted into a
variety of 1D spatial model simulations by the MML utility applications
As part of these simulations this section will look at the utility of SAN atria and
ventricular cell models and their combination for generating propagating action potentials
The primary goals are to identify existing usable models examine possible setups as well
as identifying strengths and weaknesses of the MML framework
612 Methods
The objective of this section is to review a selection of existing CellML cardiac cell models
that can be used with the MML framework (refer to Table 6-1 for the list of cellular
models) CellML models selected from the repository are at least level 2 curated models as
of April 2009 The models were noted for unit correctness and whether they could be
properly parsed by the MML utility applications The MML utility applications are
currently restricted in their ability to parse only limited types of mathematical equations
(appendix B) and generate solvable scripts accordingly Once the model is parsed it can be
converted into a solvable finite element model by the MML utilities
A range of MML models will be constructed from the SAN atria and ventricular cell
models incorporated into a simple 1D spatial model A number of observations will be
made including their characteristics in a basic 1D cable-type model as well as the use of a
radially-symmetric formulation to simulate a 2D model using a 1D PDE These propagation
models will be constructed using three excitable cardiac cell models the Rogers-
McCulloch (1994)[94] polynomial model the Earm-Noble (1990) [95] atrial cell model and
the Shannon et al (2004) [91] ventricular cell model These models represent various
degrees of complexity from simple polynomial models to over forty state variables found in
47
Repository models are retrieved before and during April 2009
210
the Shannon et al Usable SAN models will be connected to these excitable tissues at a
predetermined conductivity value and impulse propagation will be simulated using a simple
1D or radially-symmetric[72] formulation The following sections will describe how this is
implemented in FML (Geometrical) and ModelML (Relational) models
Constructing the FML model
Variations of a simple 1D spatial cable model were used in these simulations including
models that contained either one two or three domains (ie sub-intervals or regions)
The single domain version has a length of 0005m It was used to simulate activity of a
monodomain cardiac formulation The two and three domain versions were used for SAN
atrial simulations For SAN models with both central and peripheral cell types the three
domain version was used while the two domain model was used for SAN simulations not
incorporating SAN heterogeneity The two domain geometric model has a length of
0015m with the two domains separated at the 0007m mark The three domain geometric
model has a length of 0015m where the first domain terminates at 0003m and the second
domain terminates at 0007m A sample FML code is shown below In this example the
model is constructed using the boundary representation method The cell list contains the
point geometric data declarations These points are referenced by index in the topology
information section
ltfml name=geom1gt
ltframe name=globalgt
ltdimensiongt
ltdimension_element name=x units=rdquocentimeterrdquogt
ltdimensiongt
ltcell_list tolerance=15E-12gt
ltdim_0gt
ltpoint_listgt
ltpt x=00gt
ltpt x=00070gt
ltpt x=0015gt
ltpoint_listgt
ltdim_0gt
ltcell_listgt
ltb_repgt
lttopologygt
ltadjacency type=subdomaingt
ltgeometric_entity name=SANgt
211
ltvertex pt=0gt
ltvertex pt=1gt
ltgeometric_entitygt
ltgeometric_entity name=Atrgt
ltvertex pt=1gt
ltvertex pt=2gt
ltgeometric_entitygt
ltadjacencygt
ltadjacency type=vertexgt
ltvertex down=NONE pt=0 up=SANgt
ltvertex down=SAN pt=1 up=Atrgt
ltvertex down=Atr pt=2 up=NONEgt
ltadjacencygt
lttopologygt
ltb_repgt
ltframegt
ltfmlgt
Constructing the relational model
In these simulations CellML models were mapped onto the 1D models described in the
MML format The MML model was then parsed and converted into a solvable script These
models serve as a check for whether the CellML models can be parsed or solved
ModelML was used to span a CellML model onto a single domain FML 1D spatial model
as shown in the code below The conductivity value of these models was set to 0 to observe
intrinsic action potential characteristics in the absence of propagation For atria or
ventricular models the CellML document taken from the CellML repository had to be
modified to remove the stimulus term at the CellML document scope An external stimulus
was applied in the ModelML document to elicit an action potential instead In the code
sample below there are three major components the import list that references the external
CellML model and FML geometric model the system variable declaration that sets up the
ODE state variables and the subdomain list which creates relational information between
the geometric and mathematical information
ltmodelml name=rdquoexamplerdquogt
ltimport_listgt
ltimport name=geometry type=FML xlink= single_domain_1dfmlgt
ltimport name=model type=CellML xlink= fitz_nag_FIXEDxmlgt
ltdependent_variable initial_condition=-60 name=membraneVmgt
ltdependent_variable name=recovery_variableugt
212
ltparameter name=ionic_currentk value=120gt
ltparameter name=recovery_variablee value=006gt
ltparameter name=recovery_variableB value=-32gt
ltparameter name=recovery_variableA value=255gt
ltparameter name=recovery_variabled value=0gt
ltparameter name=membraneCm value=1gt
ltparameter name=recovery_variablebeta value=001gt
ltparameter name=ionic_currentc1 value=18gt
ltparameter name=ionic_currentc2 value=1gt
ltparameter name=ionic_currentalpha value=-1gt
ltimportgt
ltimport_listgt
ltmodelgt
ltsystem_listgt
ltsystem name=membranegt
ltmodel_groupgt
ltimport ref=modelgt
ltmodel_groupgt
ltvariable_mapping mapping=defaultgt
ltsystemgt
ltsystem_listgt
ltsubdomain_listgt
ltsubdomain name=testgt
ltgeometric_propertygt
ltgeometric_entity ref=geometrydom1gt
ltgeometric_propertygt
ltphysics_propertygt
ltimport_property import_ref=model system_ref=membranegt
ltphysics_propertygt
ltsubdomaingt
ltsubdomain_listgt
ltmodelgt
ltmodelmlgt
613 CellML model test results
A summary of results using SAN cell models on a single-domain 1D spatial model is
shown in Table 6-1 The FitzHugh-Nagumo Lovell Demir and Dokos models failed the
unit validation test but were successfully parsed and solved for The Sarai models contained
mathematical expressions not currently supported by the MML parsing applications A
sample of the simulation results are shown in Figure 6-1
213
Sinoatrial Models Single Domain Test Units Validation
Demir et al 1994[96] amp 1999[97] Succeed Failed
Garny 2003[98] Succeed Succeed
Lovella et al 2004[66]
Succeed Failed
DiFrancesco amp Noble 1985 [99] Succeed Succeed
Noble amp Noble 1984[100] Succeed Succeed
FitzHugh-Nagumoa
1961[78-79] Succeed Failed
Kurata et al 2002[101] Succeed Succeed
Dokos et al 1996[102] Succeed failed
Endresen 1997 [103] Succeed Succeed
Sarai et al 2003[104] failed
Table 6-1 Results of SAN (models on a single 1D domain) a denotes non-CellML Repository File
214
Figure 6-1 A sample of the simulated action potentials of SAN cell models on a single 1D domain The
tissue conductivity was set to zero in order to examine the intrinsic action potential characteristics of
the models
Top Dokos (1996) SAN cell model
Bottom Noble amp Noble (1984) SAN cell model
215
Next atria and ventricular cell models were used with the single 1D domain model Unlike
the SAN cell simulations these tests required the application of an external current stimulus
at every point in the domain A summary of the results are shown in Table 6-2
Atria Ventricular models Single Domain Test (Stimulus
applied)
Units validation
Earm et a 1990[95] Succeed Succeed
Hilgemann amp Noble 1987[105] Succeed Succeed
Roger McCullocha 1994[94] Succeed Failed
Lindbald et al 1996[106] Succeed Succeed
Tentusscher et al 2004[107] amp
2006[108]
Failed
Beeler-Reuter 1977[109] Succeed Succeed
Luo-Rudy 1994[110] Succeed Succeed
Ramirez et al 2000[111] Failed
Courtemacnche et al 1998[112] Failed Succeed
Hund et al 2004[113] Failed Succeed
Bondarenko et al 2004[90] Succeed Succeed
Pandit et al 1994 [114] Succeed Succeed
Matsuoka et al 2003[115] Failed
Winslow et al 1999[76] Failed
Priebe et al1998[116] Failed
Jafri et al 1998[117] Succeed Succeed
Shannon et al 2004a [91] Succeed failed
Table 6-2 Results of atrialventricular models on a single 1D domain a denotes non-CellML repository
file
The Rogers-McCulloch and Shannon models failed the unit test but were able to generate
the correct action potential waveforms The Tentusscher Hund and Courtemache models
were successfully parsed and unit checked However the COMSOL finite element solver
216
was unable to solve these successfully48
(These models can be solved using Matlab or
PCEnv in its 0D Formulation) The Ramirez Matsuoka and Winslow models contain
mathematical expressions currently not supported by the MML parsing application A
sample of the simulation results can be seen in Figure 6-2
48
Error includes Last time step does not converge
217
Figure 6-2 A sample of the simulated atrialventricular cell action potentials of cell models on a single
1D domain Tissue conductivity was set to zero
Top Earm et al (1990)
Bottom Shannon et al (2004)
218
62 1D Atrial conduction simulations
These simulations aim to determine the conductivity value where the action potential are
propagated at 05-1 ms or at the nearest velocity where a stable action potential can be
achieved using a normal 1D two domain geometric model Here a stimulus is applied at
one domain and propagated into the other The results can be seen in Table 6-3 These
values are used for later simulations to observe 1D SAN and atria interaction
Atria Ventricular Cell models Conductivity Values (Sm) Conduction Velocities (ms)
Earm et al 1990 8e-4 to 9e-3 13 to 4
Hielgmann et al 1987 15e-4 to 5e-4 04 to 1
Roger- McCulloch 1994 2e-4 to 9e-4 01 to 04
Lindbald et al1996 1e-4 to 5e-4 05 to 1
Beeler-Reuter 1997 1e-7 to 5e-7 04 to 1
Luo-Rudy 1994 1e-6 to 5e-6 11 to 4
Bondarenko et al 2004 5e-8 to 5e-7 07 to 13
Jafri et al1998 1e-7 to 5e-7 06 to 08
Shannon et al 2004 1e-6 to 8e-6 04 to 1
Table 6-3 AtriaVentricular conductivity value test A range of conductivity values was determined
where the waveform propagates close to 05-1 ms if possible
621 The SAN and atria model formulation
Various combinations of selected SAN and atriaventricular cell models were combined to
observe the basic characteristics of SAN-atrial interaction including action potential
characteristics and whether they can be parsed and solved for Three atriaventricular
models were chosen the Rogers-McCulloch (1994) (RM) (2 state variables) the Earm
(1990) atrial model (EM) (16 state variables) and the Shannon (2004) ventricular model
(SH) (46 state variables) All SAN models that were successfully solved for in the basic
test were connected to the above excitable cardiac cell models The atriaventricular models
were assigned a default conductivity value (RM = 9e-4 Sm EM = 9e-4 Sm SH = 3e-6
219
Sm) to examine whether the SAN was able to generate a successful impulse propagation
for both the simple 1D and a radially symmetric 2D model expressed as an equivalent 1D
formulation
A ModelML document was used to import and create mappings of variables and units of
the external models For the Kurata[101] SAN model the default time unit was in
milliseconds Using the system units mapping we can specify the global time variable as
seconds which will force the export utility to convert the Kurata equation to the ldquosecondrdquo
unit as shown below in the code below
ltsystem name=time_systemgt
ltmodel_groupgt
ltimport ref=SANgt
ltimport ref=Atriagt
ltmodel_groupgt
ltvariable_mappinggt
ltindependent_variable name=time units=secondgt
ltvariable ref=SANenvironmenttime units=millisecondgt
ltvariable ref=Atriaenvironmenttime units=secondgt
ltindependent_variablegt
ltvariable_mappinggt
ltsystemgt
The geometric models used are either the two domain 1D model for SAN models that do
not differentiate between central and peripheral cells or three domain 1D spatial models for
those that do
The models are implemented as either a generic 1D simulation or using the Joyner amp
Capelle[72] formulation to simulate a radially-symmetric 2D load as a 1D spatial model
For the generic 1D model the PDF solved for was
where V is the transmembrane potential is the surface to volume ratio is to tissue
conductivity is the membrane capacitance and is the ionic current
220
Figure 6-3 Radially-symmetric 2D geometry for simulating SAN-atrial interactions A geometry was
utilised by Joyner and Capelle[72] to investigate how a relatively small SAN region can drive a larger
hyperpolarised atrial load
Using the Joyner and Capelle model we can simplify their 2D setup into a 1D geometric
formulation The 2D model used by Joyner and Capelle is shown in Figure 6-3 This model
is composed of concentric circles each is separated by a distance The radius of each
circle can be described as r = j where j is an integer The Joyner and Capelle
formulation can be written as
(6-1)
where is the resistivity of the region between j and j+1 T is the thickness of the sheet
is the membrane potential of the region between j and j+1 and is the ionic current
is the membrane surface area which can be described as
(6-2)
where is the surface to volume ratio
221
(6-1) can be rewritten as
(6-3)
Letting (6-3) can be rewritten as
(6-4)
and
(6-5)
Let
(6-6)
Substituting
(6-7)
which can be rewritten as
(6-8)
222
or
(6-9)
To implement this formulation in ModelML an extra term is required to be inserted into
the default governing PDE equation found in the default 1D MML models (
) This can
be implemented by using the ltsourcegt term elements and MathML to describe the extra
formulation as shown below In this example the flux information and extra source terms
are attached to the ODEs found in the CellML document to convert it into a PDE equation
ltsubdomain name=SAN_DOMgt
ltgeometric_propertygt
ltgeometric_entity ref=geometrySANgt
ltgeometric_propertygt
ltphysics_propertygt
ltimport_property import_ref=SAN system_ref=membranegt
ltlayer name=mvgt
ltimport_equation ref=membraneapply[0]gt
ltfluxgt
ltvectorgt
ltapplygt
lttimesgt
ltcigt-sigSAltcigt
ltapplygt
ltdiffgt
ltbvargt
ltcigtxltcigt
ltbvargt
ltcigtVltcigt
ltapplygt
ltapplygt
ltvectorgt
ltfluxgt
ltsource operation=plusgt
ltapplygt
ltdividegt
ltapplygt
lttimesgt
ltcigtsigSAltcigt
ltapplygt
ltdiffgt
ltbvargt
ltcigtxltcigt
223
ltbvargt
ltcigtVltcigt
ltapplygt
ltapplygt
ltcigtxltcigt
ltapplygt
ltsourcegt
ltlayergt
ltimport_propertygt
ltimport_property import_ref=SAN system_ref=san_underlyinggt
ltphysics_propertygt
ltsubdomaingt
Simple 1D model simulations
Using the setup described in the previous section a number of simulations were undertaken
using the MML framework to investigate SAN-atrial interactions in a simple 1D cable
model of length 0015m The SAN was defined over the region with the
atria defined for For the atrial domain the RM polynomial the Earm-Noble
(1990) and the Shannon et al (2004) models were used For the SAN domain a number of
models were used as summarised in Table 6-4 to Table 6-6 For some SAN models both
central and peripheral cell types were used These were the Fitzhugh-Nagumo Garny and
Lovell et al models In these cases an additional central SAN region was defined over
In all the simulations the phenomena of propagation and entrainment
were studied Entrainment was defined as the generation of a coordinated frequency of
firing of all SAN cells in the domain In other words all SAN cells were synchronised to
the same rate of firing Propagation was defined as the successful excitation of the entire
atrial region due to the SAN region Membrane capacitance was set to ( ) and
surface-volume ration ( ) was arbitrarily fixed to unity All simulations were carried out
over a time interval of one second with initial conditions as set out in the CellML model
For the RM polynomial and Earm atrial models all SAN models except Endersen and
Kurata were able to generate a successful action potential propagation into the atrial region
Similarly when the Shannon model was used in the atrial region the Endresen and Kurata
SAN models were unable to generate propagation into the atrial region The full result can
be seen in Table 6-4 Table 6-5 and Table 6-6 and a sample of successful activations in
Figure 6-4 to Figure 6-6
224
SAN Model Propagation Observation
Fitzhugh Nagumo (1961) Successful Entrainment and propagation
Garny et al (2003) Successful Entrainment and propagation
Lovell et al (2004) Successful Entrainment and propagation for
when conductivity value is lowered to 1e-4
Noble amp DiFrancesco (1989) Successful Entrainment and propagation
Noble amp Noble (1984) Successful Entrainment and propagation
Dokos et al (1996) Successful Entrainment and propagation
Demir et al(1999) Successful Entrainment and propagation
Endresen (1997) Failed
Kurata et al (2002) Failed
Table 6-4 SAN-atrial 1D interactions The Rogers-McCulloch (1994) model was used for the atrial
region with various SAN models tested over the SAN domain The default conductivity was set to 9e-4
Sm for both regions
225
Figure 6-4 A sample of the simulations of SAN-atrial interaction in a simple 1D model using Rogers-
McCulloch model for the atrial region SANAtrial action potential waveforms are show at x= 0002
(SAN) and x=0012 (atrial) for two domain models or x=0002 (central SAN) x=0006 (peripheral SAN)
and x=0012 (atrial) for three domain models
Top Fitzhugh-Nagumo (1961)
Bottom Noble-Noble (1984)
226
SAN Model Propagation Observation
Fitzhugh Nagumo (1961) Successful Entrainment and propagation
Garny et al (2003) Successful Entrainment and propagation
Lovell et al (2004) Successful Entrainment and propagation when conductivity
lowered to 4e-4 Sm
Noble amp DiFrancesco (1989) Successful Entrainment and propagation when conductivity
lowered to 5e-5
Noble amp Noble (1984) Successful Entrainment and propagation when conductivity
lowered to 5e-5
Dokos et al (1996) Successful Entrainment and propagation
Demir et al(1999) Successful Entrainment and propagation when conductivity
lowered to 5e-5
Endresen (1997) Failed
Kurata et al (2002) Failed
Table 6-5 SAN-atrial 1D simulation summary The Earm et al (1990) model was used for the atrial
region with various SAN models tested over the SAN domain The default conductivity was set to 9e-4
Sm for both regions
227
Figure 6-5 A sample of the simulations of SAN-atrial interaction in a simple 1D model using Earm et
al model for the atrial region SANAtrial action potential waveforms are show at x= 0002 (SAN) and
x=0012 (atrial) for two domain models or x=0002 (central SAN) x=0006 (peripheral SAN) and
x=0012 (atrial) for three domain models
Top Demir et al (1999)
Bottom Noble-Noble (1984)
228
SAN Model Propagation Observation
Fitzhugh Nagumo (1961) Successful Entrainment and propagation
Garny et al (2003) Successful Entrainment and propagation when
conductivity lowered to 5e-5 Sm
Lovell et al (2004) Successful Entrainment and propagation when
conductivity lowered to 7e-6 Sm
Noble amp DiFrancesco (1989) Successful Entrainment and propagation
Noble amp Noble (1984) Successful Entrainment and propagation
Dokos et al (1996) Failed (Solver Error)
Demir et al(1999) Failed (Solver Error)
Endresen (1997) Failed
Kurata et al (2002) Failed
Table 6-6 SAN-atrial 1D simulation summary The Shannon et al (2004) model was used for the atrial
region with various SAN models tested over the SAN domain The default conductivity was set to 3e-6
Sm for both regions
229
Figure 6-6 A sample of the 1D Simulations of SAN-atrial interaction in a simple 1D model using
Shannon et al model for the atrial region SANAtrial action potential waveforms are show at x= 0002
(SAN) and x=0012 (atrial) for 2 domain models or x=0002 (central SAN) x=0006 (peripheral SAN)
and x=0012 (atrial) for three domain models
Top Fitzhugh-Nagumo (1961)
Bottom Lovell et al (2004)
230
Radially-Symmetric 2D SAN-Atrial simulation
Like the previous simple 1D simulation a simple 1D cable model of length 0015m was
used The SAN was defined over the region with the atria defined for
For the atrial domain the RM polynomial the Earm-Noble (1990) and the
Shannon et al (2004) models were used For the SAN domain a number of models were
used as summarised in Table 6-7 to Table 6-9 For some SAN models both central and
peripheral cell types were used These were the Fitzhugh-Nagumo Garny and Lovell et al
models In these cases an additional central SAN region was defined over
Membrane capacitance was set to ( ) and surface-volume ration ( )
was arbitrarily fixed to unity All simulations were carried out over a time interval of 1
second with initial conditions as set out in the CellML model The conductivity values
were set to match the simple 1D setup
Similar to the simple 1D simulation the Kurata and Endersen SAN model was unable to
generate any propagation into the atrial region The conductivity values of most these
simulations had to be lowered from the simple 1D case to observe any stable action
potential activity as shown in Table 6-7 to Table 6-9
231
SAN Model Propagation Observation
Fitzhugh Nagumo (1961) Successful Entrainment and propagation
Garny et al (2003) Successful Entrainment and propagation
Lovell et al (2004) Successful Entrainment and propagation when
conductivity lowered to 1e-4
Noble amp DiFrancesco (1989) Successful Entrainment and propagation when
conductivity lowered to 1e-4
Noble amp Noble (1984) Successful Entrainment and propagation when
conductivity lowered to 1e-4
Dokos et al (1996) Successful Entrainment and propagation when
conductivity lowered to 1e-4
Demir et al(1999) Successful Entrainment and propagation when
conductivity lowered to 1e-5
Endresen (1997) Failed
Kurata et al (2002) Failed
Table 6-7 Radially-symmetric 2D SAN-Atrial simulation summary The Roger-McColloch (1994)
model was used for the atrial region with various SAN models tested over the SAN domain The
default conductivity was set to 9e-4 Sm for both regions
SAN Model Propagation Observation
Fitzhugh Nagumo (1961) Successful Entrainment and propagation
Garny et al (2003) Successful Entrainment and propagation
Lovell et al (2004) Successful Entrainment and propagation when
conductivity lowered to 1e-4
Noble amp DiFrancesco (1989) Successful Entrainment and propagation when
conductivity lowered to 1e-4
Noble amp Noble (1984) Successful Entrainment and propagation when
conductivity lowered to 1e-4
Dokos et al (1996) Successful Entrainment and propagation when
conductivity lowered to 1e-4
Demir et al(1999) Successful Entrainment and propagation when
232
conductivity lowered to 1e-5
Endresen (1997) Failed
Kurata et al (2002) Failed
Table 6-8 Radially-symmetric 2D SAN-Atrial results The Earm et al (1990) model was used for the
atrial region with various SAN models tested over the SAN domain The default conductivity was set to
9e-4 Sm for both regions
SAN Model Propagation Observation
Fitzhugh Nagumo (1961) Successful Entrainment and propagation
Garny et al (2003) Irregular Waveform
Lovell et al (2004) Successful Entrainment and propagation when
conductivity lowered to 7e-6
Noble amp DiFrancesco (1989) Successful Entrainment and propagation
Noble amp Noble (1984) Successful Entrainment and propagation
Dokos et al (1996) Failed
Demir et al(1999) Failed
Endresen (1997) Failed
Kurata et al (2002) Failed
Table 6-9 Radially-symmetric 2D SAN-Atrial simulation summary The Shannon et al (2004) model
was used for the atrial region with various SAN models tested over the SAN domain The default
conductivity was set to 9e-4 Sm for both regions
622 Discussion
The basic CellML model simulations identified both usable cardiac models and limitations
in the MML parsing applications Unusable CellML models could be attributed to either
default parameter values that caused solver errors (such as convergence failures or other
solver-application errors) or unsupported CellML expression formats which could not be
parsed (MML parsing application error) The MML parsing application is currently limited
in its capability Additional development is required to increase the number of usable
CellML models can be parsed
233
For the propagation simulations both the Kurata and Endersen SAN models failed
consistently to generate an action potential in the atria for both the normal 1D and 1D radial
formulations By lowering the tissue conductivity value both models were able to generate
SAN automaticity but no propagation into the atria The Endersen model was only able to
attain a maximum membrane voltage of -7 mV This overshoot was perhaps too low to
successfully excite the atria domain The Kurata model was unable to excite the atrial
model possibly because of unit conversion issues The default unit of the Kurata model was
milliseconds which was converted to seconds for compatibility with the RM model The
default conductivity value had to be lowered by a ratio of one thousand before any activity
of the Kurata SAN could be observed
For the 1D radial formulation the conductivity values for most of the models had to be
lowered to observe SAN activity and propagation into the atrial region This is expected as
the radial formulation implicitly includes the increased electronic load of a 2D domain The
simulations of this section provide basic information including intrinsic AP characteristic
and tissue conductivity values that will be used in subsequent simulations
234
63 2D3D Models of the sinoatrial node pacemaker
631 Overview
The SAN is considered to be the natural pacemaker of the heart It resides in the wall of the
right atrium and is comprised of a large number of heterogeneous pacemaker cells The
SAN typically initiates the cardiac activation sequence whereby activation travels from the
SAN to the atria walls then through the atrioventricular node and the Purkinje fibre system
before finally activating the ventricular myocardium [67]
The SAN is composed of central and peripheral pacemaker cells which border the
surrounding atrial tissue with no well defined boundary between the SAN and atrial region
It is not well understood how a relatively small SAN region is able to drive a much larger
and hyperpolarized atrial region without itself being suppressed[72] One hypothesis for the
maintenance of SAN rhythm is that there exists a spatial gradient in tissue conductivity
which helps protect the SAN from the atrial myocardium[70] Furthermore studies over the
past decade have suggested that successful propagation from a focal point within the SAN
is related to the anisotropic nature of the SAN[118-119]
A related question is how the different SAN cells with different rates of intrinsic firing are
able to interact with each other and entrain to a common frequency in order to propagate
an action potential without being inhibited by the atrial region There are two main theories
on how SAN cells are able to synchronize The first theory suggests that a small group of
cells acts as the ldquodominantrdquo pacemaker site with the other cells driven by these dominant
cells The second theory argues that cells with different intrinsic frequencies mutually
interact with each other to achieve a consensus of when to fire[120]
There is a considerable amount of modelling data for cardiac tissues much built upon
previous cellular models based on experimental results[87] These cellular models can be
used in conjunction with spatial models to construct temporo-spatial models of cardiac
excitable tissues to study the effect and interactions of different regions This SAN test
study allows us to demonstrate the use of the MML framework to construct a solvable
temporo-spatial model from different reusable sources to investigate the dynamics of SAN
function
235
In the simulations of this section we used a combination of 2D and 3D models to observe
and compare SAN behaviours in relation to the tissue conductivity The geometric models
are introduced in an ascending order of complexity We also observe the propagation
pattern of impulses from the SAN to the atria including those from a realistic 3D SAN
model This information is later used to simplify the choice of the conductivity parameter
for the more complex arrhythmia simulations This construction of a range of ionic cell and
geometric models is simplified through the use of the MML modular approach
632 Methods
As a test case for the MML modelling framework the critical tissue conductivity values for
different types of geometric and cellular model setups will be determined This allows the
investigation of whether the SAN is able to pace the atrial region or whether the atrial
region is able to inhibit the SAN The use of different geometries and cellular models
allows an efficient investigation into the behaviour and appropriateness of these cellular
models as well as the effect of tissue architecture on SAN function and propagation into the
atria A number of geometric models will be used including two and 3D representations
consisting of simplified as well as anatomically realistic regions
Tissue conductivity in the atrial regions was fixed to a value that produced a stable
conduction velocity of 05ms whenever possible in 2D geometry Conductivity values in
the SAN were varied to see if the different models were able to frequency entrain and
propagate their impulse into the atria
Using the MML framework the relational and overall model information was stored in
ModelML the geometric and field information was stored in FML and the governing
cellular mathematical models were stored in CellML The ModelML document also
provide the mechanism to map related variable names from different external documents to
one global variable using the system construct as shown in the example code below
ltsystem name=membrane_voltagegt
ltmodel_groupgt
ltimport ref=cloherty_centralgt
ltimport ref=cloherty_perpgt
ltimport ref=earmgt
ltmodel_groupgt
236
ltvariable_mappinggt
ltstate_variable name=Vmgt
ltvariable ref=cloherty_centralmembraneVagt
ltvariable ref=cloherty_perpmembraneVagt
ltvariable ref=earmmembraneVgt
ltstate_variablegt
ltvariable_mappinggt
ltsystemgt
In general variables that describe similar attributes such as membrane voltage from
different cellular models are mapped into one system group Furthermore the underlying
currents of each cellular model are declared in its own system group In the code above
variables ldquoVardquo and ldquoVrdquo will be identified as ldquoVmrdquo in the local ModelML scope as well as
the solvable script generated This method allowed cellular models with different variable
names to be used together
Once constructed the documents were exported into a solvable script and solved using the
COMSOL Multiphysics finite-element software
The 2D conductivity values were used as a guide for the 3D simulations In these
simulations a simple 3D geometry was used to compare the tissue conductivity Realistic
anatomical SAN models were then used to observe propagation patterns using these values
to generate impulse from the SAN to the atria
Cellular models
To model the SAN the polynomial FitzHugh-Nagumo (FHN) [78-79] formulation or the
biophysically accurate Lovell et al model (LCCD) [66] were used The atrial region was
modelled using the Rogers-McCulloch model (RM) [94] or the Earm-Noble model (EN)
[95] All these models were written using the CellML 11 specification The FHN and RM
were implemented using a monodomain formulation as shown in equation (6-10) (6-11)
and (6-12) (6-13) with parameters and initial conditions shown in Table 6-10 The LCCD
and EN CellML documents were taken from the CellML repository these documents had
to be corrected for unit inconsistencies and minor mistakes For computational efficiency
the Garny[98] SAN model was used for the 3D anatomically realistic model instead of the
more complex LCCD model
237
(6-10)
(6-11)
(6-12)
(6-13)
Parameter Atrial Peripheral Central Units
a 013 -1 -1
b 0 -029 001
c1 026 19 18
c2 01 1 1
d 1 0 0
e 0013 006 006
A 0140 0035 00255
B -0085 -0030 -0032
k 1100 170 120
u(0) -85 -60 -60
v(0) 0 0 0
Table 6-10 FHN and RM model parameter values amp initial conditions
FML geometric setup
Various 2D and 3D models were used to investigate the influence of geometry and to note
the appropriateness of geometric complexity for these simulations Two 2D models were
used to investigate the SAN-atrial interaction a radially-symmetric 2D geometry and an
anatomically-accurate 2D representation A range of 3D models were used including a
238
simple geometry setup as well as realistic SAN representations consisting of three
variations each increasing upon the others in geometric element count
SAN geometric models were constructed using one of three external softwares (COMSOL
Multiphysics CAD49
AutoCAD50
or ScanIPScanFE51
) and imported into FML using the
MML geometric utility package The models were stored using boundary representation
solid modelling with geometric field objects and adjacency structure information for the
2D models and mesh representation for 3D models
Figure 6-7 Radially-symmetric 2D SAN model with A) atrial region P) peripheral region and C)
central region
The 2D radially-symmetric SAN model was composed of three concentric circular domains
representing the central peripheral and atrial regions as shown in Figure 6-7 The radius for
each region was 3mm 75mm and 15mm This simplified model provided a uniform and
complete boundary contact between each subdomain
A more complex 2D model was constructed from the Dobrzynski rabbit SAN data [69]
where the 3D dataset was projected onto a 2D plane and traced using AutoCAD The
complex setup provided a realistic model with interesting features including a complex
boundary of direct contact between the central and atrial regions as shown in Figure 6-8
49
COMSOL Multiphysics v 34 COMSOL AB Palo Alto CA 50
AutoCad 2006 Autodesk Inc San Rafael CA 51
Simpleware Ltd Exeter UK
239
Figure 6-8 Complex tissue geometric model (top) with A) atrial region P) peripheral region and C)
central region and the Dobrzynski rabbit SAN data which it is based on (bottom) (From [69])
To expand upon these 2D models a range of 3D models was created to observe the effect
of the extra dimension with tissue conductivity The 3D geometries can be classified as
simple or realistic
240
Figure 6-9 3D Simple 3D geometric setup where C-Central SAN P-Peripheral SAN and A-atrial With
side view x-y (left) and top view x-z (right)
The simple 3D model was constructed from rectangular blocks as shown in Figure 6-9
representing a generalised SAN-atria layout The atrium is represented by rectangular
block measuring 15mm by 12mm by 17mm the central region measures 3mm by 6mm by
17mm and the peripheral region measuring 7mm by 8mm by 17mm
241
Figure 6-10 Dobrzynski data visualisation a) x-z view b) x-y view and c) x-y-z view show the general
SAN shape d) x-z view e) x-y view and f) x-y-z view illustrate the SAN central and peripheral cells
The realistic 2D model was created by using the Dobrzynski et al[69] data (shown in Figure
6-10) The cell tissue data was used to create image slices for each y coordinate entry as
shown in Figure 6-11 (where each image represents the x and z coordinate) Connective
tissue types was ignored and replaced with atrial tissues assuming connective tissue has
little effect on overall SAN function[64] Each pixel on these images represents a 001mm
by 001mm resolution When the images are stacked together each voxel represents a
001x001x001mm tissue space These image slices were then imported into Simpleware
ScanIP to segment the SAN regions The segmented model was than exported into
242
Simpleware ScanFE where a mesh was created that could be used for finite element
simulation
Figure 6-11 x-z image slices generated using from Dobrzynski et al[69] rabbit SAN data This figure
shows some images of the dataset at y equal to a) 4mm b) 6mm c) 8mm d) 10mm e) 12mm and f)
14mm Black pixels indicates atrial cells Dark Grey pixels indicates Peripheral SAN cells and White
pixels indicates Central SAN cells
The unmodified Dobrzynski data was too fine in resolution leading to a very large and
computationally demanding model Using ScanFE the raw volume model was re-sampled
to reduce its size and element count and modified to remove artefacts and holes to create a
computationally tractable geometric model Three geometric models were created with
various total element counts One set of very low resolution voxels was created (as shown
in Figure 6-12) by re-sampling using a factor of 15 15 and 35 for the x y and z
dimensions respectively (27000 tetrahedral elements) A mid level resolution model (as
shown in Figure 6-13) was created by re-sampling using a factor of 5 5 and 35 for x
y and z (150000 tetrahedral elements) and a high resolution SAN model (as shown in
243
Figure 6-14) was re-sampled using a factor of 75 75 and 35 in the x y and z
dimension (425000 tetrahedral elements) These mesh models were imported into FML
and used to construct the overall temporo-spatial models
Figure 6-12 SAN low-resolution realistic geometric model re-sampled using (15 15 35) for x
y and z dimensions from Dobrzynski et al[69] data a) x-y-z view of the complete SAN-atrial model b)
x-y view of the complete SAN-atrial model c) x-y-z view of the SAN component and d) x-y view of the
SAN component
244
Figure 6-13 SAN mid-resolution realistic geometric model re-sampled using (5 5 35) for x y
and z dimensions from Dobrzynski et al[69] data a) x-y-z view of the complete SAN-atrial model b) x-
y-z view of the SAN component and c) x-y view of the complete SAN-atrial model
245
Figure 6-14 SAN high-resolution realistic geometric model re-sampled using (75 75 35) for x
y and z dimensions from Dobrzynski et al[69] data a) x-z view of the SAN-atrial model b) x-y view of
the SAN-atrial model c) x-y-z view of the SAN-atrial model and d) x-y-z view of the SAN component
633 2D simulation results
Summarised results of the 2D SAN simulations can be seen in Table 6-11 A number of
observations can be concluded from the dataset The FHN was able to drive the atria
models at the default conductivity values while the LCCD models was less able to drive the
atria models at the default values (RM 224e-4 Sm EN 44e-4 Sm) The conductivity
values had to be lowered to 3e-5 Sm for the RM complex model 1e-5 Sm for the EN
simple model and 3e-5 Sm for the EN complex model to observe entrainment and atrial
activation
246
Simple Geometry Complex Geometry
A B C A B C
FHN-RM 0 lt27e-5 gt27e-5 0 lt5e-6 gt5e-6
FHN-EN 0 lt9e-5 gt9e-5 NA lt2e-6 gt2e-6
LCCD-RM lt5e-6 lt8e-5 gt1e-4 NA lt2e-5 lt5e-5
LCCD-EN gt5e-4 lt5e-5 lt2e-4 gt4e-5 lt1e-6 lt3e-5
Table 6-11 Tissue conductivity values for SAN inhibition entrainment and successful impulse
propagation into the atrial regions Column A represents suppression of activity within the SAN and
atria Column B represents irregular propagation and Column C represents entrainment and
successful propagation All results are in Sm denotes that the default atrial conductivity had to be
lowered to observe activity
In the complex 2D models distinct waveform patterns caused by non-entraining SAN APs
were observed Both the FHN and LCCD SAN models were able to generate irregular
activation of the RM and EN atrial regions Figure 6-16 illustrates successful propagation
for the SAN using the complex 2D geometry and LCCD with RM models In models
exhibiting SAN entrainment and propagation the waveform propagates uniformly outwards
from the SAN into the atria For non-entraining SANs irregular waveform patterns are
caused by the peripheral region generating an action potential out of synchronicity with the
central region This causes non-uniform waveform generation leading to a spiral
propagation pattern from one side of the SAN to the other as is shown in Figure 6-17
247
Figure 6-15 The graph on the top is a typical entrained SAN propagating into the atria while the graph
on the bottom is a non-entrained SAN propagating into the atria
248
Figure 6-16 Entrained SAN propagating uniformly into the atria using the 2D complex geometry At
times a) 02s b) 03s c) 035s and d) 04s Lovell et al SAN model and Rogers-McColloch atrial model
were used where the conductivity were set to 2e-5 Sm and 3e-5 Sm