Download
1 / 11
110 likes | 237 Vues
The 7th International CellML Workshop focused on the challenges of model integration in CellML, emphasizing the importance of provenance tracking and version management. This session introduced embedded workspaces, which leverage Mercurial subrepositories to maintain detailed records of model origins and modifications. By allowing arbitrary CellML components to be imported, researchers can create modular and reusable models while addressing potential issues when source models change. The workshop highlighted best practices for using embedded workspaces to prevent problems and ensure accurate documentation of model evolution.
E N D
Embedded workspaces David Nickerson 7th International CellML Workshop 25 March 2013 Waiheke Island, Auckland, New Zealand
Background • PMR Workspaces • Independent mercurial repositories. • Detailed provenance record. • Contains many types of data. • CellML 1.1 model hierarchies • Modularity and reuse. • Ability to ‘import’ arbitrary CellML componentsto assemble and create powerful models. • Define common models once and reuse them where necessary (libraries of modules).
The Problem? • When importing existing models, what happens when the source model changes? • Imported components may not exist. • Parameterizations may no longer match requirements. • … • What happens when a bugs are fixed in the source model(s)? • Provenance tracking. • Versioning and model differences. • What about when I use a library module and find bugs in it?
A solution – embedded workspaces • Mercurial subrepositories • A little concerning:
A solution – embedded workspaces • Mercurial subrepositories • A little concerning: (but we can help avoid problems with some best practice guidelines?) • A little technical but very powerful • Requires working directly with mercurial • And knowing what you are doing (mostly) • PMR web interface presents information, but no other tools making use of this feature at present (I think). • Allows relative URLs to be used for all imports, irrespective of the actual location of the source content. • Can be nested to any depth, but need to be careful about doing so.
In CellML (my-model.xml) <import xlink:href=“HH/gating-variable.xml”> <component name=“hGate” component_ref=“gate”/> </import> <import xlink:href=“physical-constants/mohr_taylor_newell_2008.xml”> <component name=“constants” component_ref=“codata_2006_universal”/> </import>
On the local file system… • My Model/ • HH/ • gating-variable.xml • … • physical-constants/ • mohr_taylor_newell_2008.cellml • my-model.xml • .hgsub, defines: • HH http://models.cellml.org/w/andre/hodgkin-huxley-model • physical-constants http://models.cellml.org/workspace/mohr_taylor_newell_2008
…on the local file system • My Model/ • … • .hgsubstate, defines: • Use HH repository @ changeset755e83040c8ea71167d2bb50c2593f4f0092fa67 • Use physical-constants repository @ changeset c506f07a2d935261f0117d8ed7d2667b7dcf7b78
The benefits… • .hgsub and .hgsubstate are normal resources in the “My Model” workspace, so all changes are tracked in the history of the workspace • If the source location for an embedded workspace is changed, you know exactly who, when, and why for the change. • Similarly for the version of the source workspace being used. • Requires specific user action to change “My Model” workspace to a different version of the HH model • Protected from potentially incompatible upstream changes.
…the benefits • Local changes in ‘HH’ or ‘physical-constants’ can easily be contributed back to original source • Accurately reflecting provenance of any changes in the source workspace(s). • Because this is all done in mercurial, collaborating independent of the central PMR server is trivial.
The future • Embedded workspaces with other types of data • Generic FEM meshes customized to specific image data? • Curated experimental data used to challenge many different models? • Support in software tools • How much of the technical detail can be abstracted away from the user?
