Jump to content

CryoNAV Key Concepts: Difference between revisions

From CryoNAVwiki
Bot edit via cryonavedit.py: remove obsolete template-system language
Bot edit via cryonavedit.py: add pipeline and tilt-series detail screenshots
 
Line 8: Line 8:


== Immutable processing branches ==
== Immutable processing branches ==
[[File:CryoNAV pipeline.png|center|thumb|700px|Pipeline view: the original chain (left) and an alternate ''Branch AAA'' forked from the Bead/Seed Models step (right) are drawn side by side, allowing direct comparison of parameter choices.]]


Each processing run is stored as an immutable record. Re-running a step with different parameters creates a new parallel branch rather than overwriting the original, allowing users to compare results from different parameter choices side by side. Downstream steps must be re-run on the new branch, but the original processing path remains intact.
Each processing run is stored as an immutable record. Re-running a step with different parameters creates a new parallel branch rather than overwriting the original, allowing users to compare results from different parameter choices side by side. Downstream steps must be re-run on the new branch, but the original processing path remains intact.

Latest revision as of 23:57, 20 May 2026

Concepts that recur throughout CryoNAV's interface and workflow.

The pipeline catalog

CryoNAV's processing pipeline is described by a catalog of pipeline modules (motion correction, CTF estimation, alignment, reconstruction, denoising, etc.). Each module declares its parameters and its dependencies on other modules. The same catalog drives the parameter forms in the UI, the validation rules, and the construction of command-line invocations: there is no separate template store to keep in sync.

When the user submits a step, the parameter values are supplied at submission time and recorded with the run; downstream steps are scheduled once their upstream dependencies succeed.

Immutable processing branches

Pipeline view: the original chain (left) and an alternate Branch AAA forked from the Bead/Seed Models step (right) are drawn side by side, allowing direct comparison of parameter choices.


Each processing run is stored as an immutable record. Re-running a step with different parameters creates a new parallel branch rather than overwriting the original, allowing users to compare results from different parameter choices side by side. Downstream steps must be re-run on the new branch, but the original processing path remains intact.

Branches are anchored at the table and ID of the upstream step they fork from, which keeps lineage unambiguous even after intermediate files are cleaned up. Because every processing step stores its complete parameter set in the database, intermediate files can be selectively deleted to reclaim storage without losing the ability to reproduce results: the full pipeline can be re-executed from raw frames at any time.

Curate before reconstruct

In a typical cryo-ET experiment, a substantial fraction of collected tilt series may be unusable due to thick ice, excessive specimen drift, contamination, or poor CTF fits. Identifying these problematic datasets early, before investing hours of compute time, saves significant resources.

CryoNAV makes curation a first-class operation within the data browsing interface, supported by automatic thumbnail generation, star ratings, tags, and combined filtering. See Grid Visualization for the visual tools and Sample & Experiment Mgt. for tagging and rating workflows.

Project-based collaboration

Projects serve as the unit of collaboration. CryoNAV's role-based access control has four levels:

  • System Administrator -- manages user accounts, monitors system health, configures available computing resources.
  • Project Owner -- can invite team members and assign roles. Multiple owners can be assigned per project; ownership can be transferred.
  • Editor -- can submit jobs and edit project data.
  • Viewer -- can browse data only.

See also