|
|
| Line 1: |
Line 1: |
| Concepts that recur throughout CryoNAV's interface and workflow.
| | #REDIRECT [[CryoNAV Key Concepts]] |
| | |
| == 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 [[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.
| |
| | |
| Processing templates and computing templates are shared among all users within the deployment.
| |
| | |
| == See also ==
| |
| | |
| * [[CryoEM Data Lifecycle]]
| |
| * [[Sample & Experiment Mgt.]]
| |
| | |
| [[Category:Core Concepts]]
| |
