CryoNAV Key Concepts - Revision history

Admin: Bot edit via cryonavedit.py: add pipeline and tilt-series detail screenshots

2026-05-20T21:57:07Z

Bot edit via cryonavedit.py: add pipeline and tilt-series detail screenshots

← Older revision		Revision as of 23:57, 20 May 2026
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.

Admin: Bot edit via cryonavedit.py: remove obsolete template-system language

2026-05-20T20:36:25Z

Bot edit via cryonavedit.py: remove obsolete template-system language

← Older revision		Revision as of 22:36, 20 May 2026
Line 1:		Line 1:
	Concepts that recur throughout CryoNAV's interface and workflow.		Concepts that recur throughout CryoNAV's interface and workflow.

	== ~~Processing templates~~ ==		== The pipeline catalog ==

	CryoNAV ~~manages~~ processing ~~jobs through two reusable~~ template ~~types:~~		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.

	* '''Processing templates''' capture the ~~parameter set for~~ a ~~single processing~~ step ~~(e.g., an alignment template specifies fiducial marker size, rotation angle search range~~, ~~and number of alignment iterations). Each template is tied to one step type and can be shared across team members and reused across projects.~~		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.
	* '''Computing templates''' define the ~~infrastructure allocation: CPUs, GPU requirements, memory limits, SLURM partition~~ and ~~Quality-of-Service settings, or local process limits.~~

	~~Individual processing steps can be chained into multi-step '''workflow templates'''~~ with automatic dependency tracking. A standard workflow might define: motion correction -> alignment and CTF estimation -> reconstruction -> optional denoising. Each step submits once its predecessor completes successfully; ~~failed~~ steps ~~halt the remainder of the chain~~.

	== Immutable processing branches ==		== Immutable processing branches ==
Line 14:		Line 11:
	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.

	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.		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 ==		== Curate before reconstruct ==
Line 30:		Line 27:
	* '''Editor''' -- can submit jobs and edit project data.		* '''Editor''' -- can submit jobs and edit project data.
	* '''Viewer''' -- can browse data only.		* '''Viewer''' -- can browse data only.

	~~Processing templates and computing templates are shared among all users within the deployment.~~

	== See also ==		== See also ==

Admin: Bot edit via cryonavedit.py: migrate to sidebar-target titles

2026-05-20T20:30:36Z

Bot edit via cryonavedit.py: migrate to sidebar-target titles

New page

Concepts that recur throughout CryoNAV's interface and workflow.

== Processing templates ==

CryoNAV manages processing jobs through two reusable template types:

* '''Processing templates''' capture the parameter set for a single processing step (e.g., an alignment template specifies fiducial marker size, rotation angle search range, and number of alignment iterations). Each template is tied to one step type and can be shared across team members and reused across projects.
* '''Computing templates''' define the infrastructure allocation: CPUs, GPU requirements, memory limits, SLURM partition and Quality-of-Service settings, or local process limits.

Individual processing steps can be chained into multi-step '''workflow templates''' with automatic dependency tracking. A standard workflow might define: motion correction -> alignment and CTF estimation -> reconstruction -> optional denoising. Each step submits once its predecessor completes successfully; failed steps halt the remainder of the chain.

== Immutable processing branches ==

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.

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 [[CryoNAV Grid Visualization Tools|Grid Visualization]] for the visual tools and [[CryoNAV Sample Experiment Management|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.

Processing templates and computing templates are shared among all users within the deployment.

== See also ==

* [[CryoNAV Data Lifecycle|CryoEM Data Lifecycle]]
* [[CryoNAV Sample Experiment Management|Sample & Experiment Mgt.]]

[[Category:Core Concepts]]