FieldML

FieldML is an open format for storing and exchanging models containing field information. It is able to represent a wide variety of field value types, including scalar, vector, tensor, logical, and strings. Fields are defined over domains explicitly in terms of functions. Domains may be nested to form embedding hierarchies

The Cardiac Atlas Project--An Imaging Database for Computational Modeling and Statistical Atlases of the Heart

MOTIVATION: Integrative mathematical and statistical models of cardiac anatomy and physiology can play a vital role in understanding cardiac disease phenotype and planning therapeutic strategies. However, the accuracy and predictive power of such models is dependent upon the breadth and depth of noninvasive imaging datasets. The Cardiac Atlas Project (CAP) has established a large-scale database of cardiac imaging examinations and associated clinical data in order to develop a shareable, web-accessible, structural and functional atlas of the normal and pathological heart for clinical, research and educational purposes. A goal of CAP is to facilitate collaborative statistical analysis of regional heart shape and wall motion and characterize cardiac function among and within population groups. RESULTS: Three main open-source software components were developed: (i) a database with web-interface; (ii) a modeling client for 3D + time visualization and parametric description of shape and motion; and (iii) open data formats for semantic characterization of models and annotations. The database was implemented using a three-tier architecture utilizing MySQL, JBoss and Dcm4chee, in compliance with the DICOM standard to provide compatibility with existing clinical networks and devices. Parts of Dcm4chee were extended to access image specific attributes as search parameters. To date, approximately 3000 de-identified cardiac imaging examinations are available in the database. All software components developed by the CAP are open source and are freely available under the Mozilla Public License Version 1.1 (http://www.mozilla.org/MPL/MPL-1.1.txt)

An overview of the CellML API and its implementation

<p>Abstract</p> <p>Background</p> <p>CellML is an XML based language for representing mathematical models, in a machine-independent form which is suitable for their exchange between different authors, and for archival in a model repository. Allowing for the exchange and archival of models in a computer readable form is a key strategic goal in bioinformatics, because of the associated improvements in scientific record accuracy, the faster iterative process of scientific development, and the ability to combine models into large integrative models.</p> <p>However, for CellML models to be useful, tools which can process them correctly are needed. Due to some of the more complex features present in CellML models, such as imports, developing code <it>ab initio </it>to correctly process models can be an onerous task. For this reason, there is a clear and pressing need for an application programming interface (API), and a good implementation of that API, upon which tools can base their support for CellML.</p> <p>Results</p> <p>We developed an API which allows the information in CellML models to be retrieved and/or modified. We also developed a series of optional extension APIs, for tasks such as simplifying the handling of connections between variables, dealing with physical units, validating models, and translating models into different procedural languages.</p> <p>We have also provided a Free/Open Source implementation of this application programming interface, optimised to achieve good performance.</p> <p>Conclusions</p> <p>Tools have been developed using the API which are mature enough for widespread use. The API has the potential to accelerate the development of additional tools capable of processing CellML, and ultimately lead to an increased level of sharing of mathematical model descriptions.</p

Constraints on a Massive Dirac Neutrino Model

We examine constraints on a simple neutrino model in which there are three massless and three massive Dirac neutrinos and in which the left handed neutrinos are linear combinations of doublet and singlet neutrinos. We examine constraints from direct decays into heavy neutrinos, indirect effects on electroweak parameters, and flavor changing processes. We combine these constraints to examine the allowed mass range for the heavy neutrinos of each of the three generations.Comment: latex, 29 pages, 7 figures (not included), MIT-CTP-221

Revision history aware repositories of computational models of biological systems

<p>Abstract</p> <p>Background</p> <p>Building repositories of computational models of biological systems ensures that published models are available for both education and further research, and can provide a source of smaller, previously verified models to integrate into a larger model.</p> <p>One problem with earlier repositories has been the limitations in facilities to record the revision history of models. Often, these facilities are limited to a linear series of versions which were deposited in the repository. This is problematic for several reasons. Firstly, there are many instances in the history of biological systems modelling where an 'ancestral' model is modified by different groups to create many different models. With a linear series of versions, if the changes made to one model are merged into another model, the merge appears as a single item in the history. This hides useful revision history information, and also makes further merges much more difficult, as there is no record of which changes have or have not already been merged. In addition, a long series of individual changes made outside of the repository are also all merged into a single revision when they are put back into the repository, making it difficult to separate out individual changes. Furthermore, many earlier repositories only retain the revision history of individual files, rather than of a group of files. This is an important limitation to overcome, because some types of models, such as CellML 1.1 models, can be developed as a collection of modules, each in a separate file.</p> <p>The need for revision history is widely recognised for computer software, and a lot of work has gone into developing version control systems and distributed version control systems (DVCSs) for tracking the revision history. However, to date, there has been no published research on how DVCSs can be applied to repositories of computational models of biological systems.</p> <p>Results</p> <p>We have extended the Physiome Model Repository software to be fully revision history aware, by building it on top of Mercurial, an existing DVCS. We have demonstrated the utility of this approach, when used in conjunction with the model composition facilities in CellML, to build and understand more complex models. We have also demonstrated the ability of the repository software to present version history to casual users over the web, and to highlight specific versions which are likely to be useful to users.</p> <p>Conclusions</p> <p>Providing facilities for maintaining and using revision history information is an important part of building a useful repository of computational models, as this information is useful both for understanding the source of and justification for parts of a model, and to facilitate automated processes such as merges. The availability of fully revision history aware repositories, and associated tools, will therefore be of significant benefit to the community.</p

CellML metadata standards, associated tools and repositories

The development of standards for encoding mathematical models is an important component of model building and model sharing among scientists interested in understanding multi-scale physiological processes. CellML provides such a standard, particularly for models based on biophysical mechanisms, and a substantial number of models are now available in the CellML Model Repository. However, there is an urgent need to extend the current CellML metadata standard to provide biological and biophysical annotation of the models in order to facilitate model sharing, automated model reduction and connection to biological databases. This paper gives a broad overview of a number of new developments on CellML metadata and provides links to further methodological details available from the CellML website

The Cardiac Atlas Project—an imaging database for computational modeling and statistical atlases of the heart

Motivation: Integrative mathematical and statistical models of cardiac anatomy and physiology can play a vital role in understanding cardiac disease phenotype and planning therapeutic strategies. However, the accuracy and predictive power of such models is dependent upon the breadth and depth of noninvasive imaging datasets. The Cardiac Atlas Project (CAP) has established a large-scale database of cardiac imaging examinations and associated clinical data in order to develop a shareable, web-accessible, structural and functional atlas of the normal and pathological heart for clinical, research and educational purposes. A goal of CAP is to facilitate collaborative statistical analysis of regional heart shape and wall motion and characterize cardiac function among and within population groups

Minimum Information About a Simulation Experiment (MIASE)

The original publication is available at www.ploscompbiol.orgReproducibility of experiments is a basic requirement for science. Minimum Information (MI) guidelines have proved a helpful means of enabling reuse of existing work in modern biology. The Minimum Information Required in the Annotation of Models (MIRIAM) guidelines promote the exchange and reuse of biochemical computational models. However, information about a model alone is not sufficient to enable its efficient reuse in a computational setting. Advanced numerical algorithms and complex modeling workflows used in modern computational biology make reproduction of simulations difficult. It is therefore essential to define the core information necessary to perform simulations of those models. The Minimum Information About a Simulation Experiment describes the minimal set of information that must be provided to make the description of a simulation experiment available to others. It includes the list of models to use and their modifications, all the simulation procedures to apply and in which order, the processing of the raw numerical results, and the description of the final output. MIASE allows for the reproduction of any simulation experiment. The provision of this information, along with a set of required models, guarantees that the simulation experiment represents the intention of the original authors. Following MIASE guidelines will thus improve the quality of scientific reporting, and will also allow collaborative, more distributed efforts in computational modeling and simulation of biological processes.The discussions that led to the definition of MIASE benefited from the support of a Japan Partnering Award by the UK Biotechnology and Biological Sciences Research Council. DW was supported by the Marie Curie program and by the German Research Association (DFG Research Training School ‘‘dIEM oSiRiS’’ 1387/1). This publication is based on work (EJC) supported in part by Award No KUK-C1-013-04, made by King Abdullah University of Science and Technology (KAUST). FTB acknowledges support by the NIH (grant 1R01GM081070- 01). JC is supported by the European Commission, DG Information Society, through the Seventh Framework Programme of Information and Communication Technologies, under the VPH NoE project (grant number 223920). The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript.Publishers versio

FieldML-Haskell-01

<p>This prototype is an attempt at using Haskell to prototype FieldML design ideas. These ideas are based on discussions of the FieldML design work group at the Auckland Bioengineering Institute at Auckland University. Current members of the FieldML design group are: Poul Nielsen, Richard Christie, Alan Wu and myself (Randall Britten). In the past, others have also contributed to these discussions, notably Andrew Miller, Caton Little, Chris Bradley and Peter Hunter.</p> <p>The key structures are in FieldML/Core.hs</p> <p>Some examples are in FieldML_test_mesh01.hs and FieldML_test1.hs.</p> <p>The unit tests can be run using "runhaskell FieldML_test1.hs".</p> <p>Recent results of the unit tests are in "test-log.txt".</p