Biomedical Engineering Reference
In-Depth Information
tational demands of solving models increases due to increased resolution or com-
plexity of the models, parallel processing is needed. However, optimal parallel pro-
cessing strategies depend on the particular problem being solved. Also the lifetime
of modelling codes is often an order of magnitude greater than the lifetime of the
computer hardware and it is notable that the architecture of parallel machines has
changed over the last few decades from vector processors, to symmetric multiple
processors (SMPs), to clusters of processors, to clusters of multiple core processors,
through to using General Purpose Graphical Processing Units (GPGPUs). Code that
assumes a particular parallel algorithm or a particular parallel architecture may not
be appropriate for a future problem or future parallel hardware. For these reasons a
design goal of OpenCMISS is that the code uses a general
n
hierar-
chical parallel environment where n is the number of computational nodes,
p
×
p
(
n
)
×
e
(
p
)
is
the number of processing systems on the computational node and e(p) is the number
of processing elements for each processing system. Examples of this hierarchy are:
•
(
n
)
multi-core or SMP
n
=
1,
p
(
n
)
>
1,
e
(
p
)=
1;
•
pure cluster
n
>
1,
p
(
n
)=
1,
e
(
p
)=
1;
•
multi-core cluster
n
>
1,
p
(
n
)
>
1,
e
(
p
)=
1;
•
multi-core cluster with GPUs
n
>
1,
p
(
n
)
>
1,
e
(
p
)
>
1.
The fourth design goal is that OpenCMISS should be able to be used, understood
and developed by both novices and experts. Modern bioengineering and physiome
science requires a team of scientists, graduate students and post-doctoral researchers
from varied backgrounds, each with a different skill set. It is unrealistic to expect
that each member of the team will become an expert in every area of modelling
and computation. The design of OpenCMISS thus abstracts and encapsulates model
details in a number of objects of hierarchical complexity. The hierarchy of these
objects allows complex details to be hidden from the users, if required, and the object
interface allows an expert to manipulate object parameters whilst the novice user
makes use of sensible default parameter values for common cases.
The final design goal, as mentioned earlier, is to incorporate Application Pro-
gramming Interfaces (APIs) for the physiome markup languages CellML and
FieldML.
Software systems
OpenCMISS is written in Fortran 95/2003 with an object-based approach for high
level objects. It has bindings for Fortran and C and uses SWIG (swig.org) inter-
faces for C++ and python. It uses the Mozilla trilicense (mozilla.org/MPL) that is
being used for other open source Physiome projects. Standard software engineering
practices are followed, including the use of a source code repository on Source-
Forge (sourceforge.net/projects/opencmiss), Doxygen for documentation, testing
via a Buildbot system, validation against analytic test cases, and a tracker system -
all described further below.
Although the main source code revision control system for OpenCMISS is cur-
rently hosted on SourceForge using Subversion, distributed version control systems
(DVCSs) such as Git or Mercurial, are currently being evaluated as an alternative.
