110 likes | 229 Views
Embedded workspaces. David Nickerson 7 th 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
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?