Steps Module#
Functionality#
The step is the core functionality of the pipeline. By chaining steps after each other, you can create processing queues. We first show the available steps and then look at the lifecycle of a step.
Available steps#
Step |
Description |
Input files |
Output files |
|---|---|---|---|
Implements the Batch-step functionality of MZmine3. |
|
|
|
CLI binding for Sirius. Predicts CSI:FingerID |
|
|
|
Shrinks an Mgf file to just contain the first n compounds |
|
|
Lifecycle of a step#
Each step has 5 lifecycle methods that will be called at certain times.
Note
This information is not necessary to understand as you can just work on the ‘pipeline abstraction level’ but it can help you figuring out what went wrong IF something goes wrong.
The pipeline was created with a big abstraction in mind between step and pipeline in order for you to just think about steps, its required parameters, input and output filetypes and nothing more. Everything else is not required to know to operate the pipeline.
1. Install#
First Install is called. This method checks weather all the systems and libraries are set up correctly. This logic is shared among all executions of this step. The config you set here will be the same for each execution of the step.
2. Setup#
In setup, the step gets configured for this specific run. This can mean setting processing parameters or temporary variables that will be used at run, but will not necessarily be used on the next execution of the step.
3. Run#
Run does exactly what it says. It runs the step on either the input of the pipeline (if it is the first step), or on the output of the previous step. It then returns paths to files for the next step to use.
4. Metadata#
After execution, a metadata.json file is generated by each step containing version numbers or other important metadata that should not be lost.
5. Citation and Disclaimer#
Before the step terminates, the citation information and necessary disclaimers are printed to console and also logged to inform the user.