1 / 11

Embedded workspaces

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

erik
Download Presentation

Embedded workspaces

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Embedded workspaces David Nickerson 7th International CellML Workshop 25 March 2013 Waiheke Island, Auckland, New Zealand

  2. 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).

  3. 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?

  4. A solution – embedded workspaces • Mercurial subrepositories • A little concerning:

  5. 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.

  6. 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>

  7. 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

  8. …on the local file system • My Model/ • … • .hgsubstate, defines: • Use HH repository @ changeset755e83040c8ea71167d2bb50c2593f4f0092fa67 • Use physical-constants repository @ changeset c506f07a2d935261f0117d8ed7d2667b7dcf7b78

  9. 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.

  10. …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.

  11. 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?

More Related