nf-core/proteomicslfq

The input to the pipeline can be specified in two mutually exclusive ways:

• using a path or URI to a PRIDE Sample to Data Relation Format file (SDRF), e.g. as part of a submitted and annotated PRIDE experiment (see here for examples). Input files will be downloaded and cached from the URIs specified in the SDRF file. An OpenMS-style experimental design will be generated based on the factor columns of the SDRF. The settings for the following parameters will currently be overwritten by the ones specified in the SDRF:

  • fixed_mods,
  • variable_mods,
  • precursor_mass_tolerance,
  • precursor_mass_tolerance_unit,
  • fragment_mass_tolerance,
  • fragment_mass_tolerance_unit,
  • fragment_method,
  • enzyme

• by specifying globbing patterns to the input spectrum files in Thermo RAW or mzML format (e.g. /data/experiment{1,2,3}_rep*.mzML). An experimental design should be provided with the expdesign parameter.

Set this parameter to your e-mail address to get a summary e-mail with details of the run sent to you when the workflow exits. If set in your user config file (~/.nextflow/config) then you don't need to specify this on the command line for every run.

This optional parameter can be used to specify a root folder in which the spectrum files specified in the SDRF are searched. It is usually used if you have a local version of the experiment already. Note that this option does not support recursive searching yet.

If the above --root_folder was given to load local input files, this overwrites the file type/extension of the filename as specified in the SDRF. Usually used in case you have an mzML-converted version of the files already. Needs to be one of 'mzML' or 'raw' (the letter cases should match your files exactly).

Since the database is not included in an SDRF, this parameter always needs to be given to specify the input protein database when you run the pipeline. Remember to include contaminants (and decoys if not added in the pipeline with --add-decoys)

--database '[path to Fasta protein database]'

If decoys were not yet included in the input database, they have to be appended by OpenMS DecoyGenerator by adding this flag (TODO allow specifying type). Default: pseudo-reverse peptides

If --add-decoys was set, this setting is used during generation and passed to all tools that need decoy information. If decoys were appended to the database externally, this setting needs to match the used affix. (While OpenMS tools can infer the affix automatically, some thirdparty tools might not.) Typical values are 'rev', 'decoy', 'dec'. Look for them in your database.

Prefix is highly recommended. Only in case an external tool marked decoys with a suffix, e.g. sp|Q12345|ProteinA_DECOY change this parameter to suffix.

Activate OpenMS-internal peak picking with the tool PeakPickerHiRes. Skips already picked spectra.

Perform peakpicking in memory. Use only if problems occur.

Which MS levels to pick as comma separated list, e.g. --peakpicking_ms_levels 1,2. Leave empty for auto-detection.

A comma-separated list of search engines to run in parallel on each mzML file. Currently supported: comet and msgf (default: comet) If more than one search engine is given, results are combined based on posterior error probabilities (see the different types of estimation procedures under --posterior_probabilities). Combination is done with ConsensusID. See also its corresponding --consensusid_algorithm parameter for different combination strategies. Combinations may profit from an increased --num_hits parameter.

Specify which enzymatic restriction should be applied, e.g. 'unspecific cleavage', 'Trypsin' (default), see OpenMS enzymes. Note: MSGF does not support extended cutting rules, as used by default with Trypsin. I.e. if you specify Trypsin with MSGF, it will be automatically converted to Trypsin/P= 'Trypsin without proline rule'.

Caution: for Comet we are estimating the fragment_bin_tolerance parameter based on this automatically.

Caution: for Comet we are estimating the fragment_bin_tolerance parameter based on this automatically.

Specify which fixed modifications should be applied to the database search (eg. '' or 'Carbamidomethyl (C)', see Unimod modifications in the style '({unimod name} ({optional term specificity} {optional origin})'). All possible modifications can be found in the restrictions mentioned in the command line documentation of e.g. CometAdapter (scroll down a bit for the complete set). Multiple fixed modifications can be specified comma separated (e.g. 'Carbamidomethyl (C),Oxidation (M)'). Fixed modifications need to be found at every matching amino acid for a peptide to be reported.

Specify which variable modifications should be applied to the database search (eg. '' or 'Oxidation (M)', see Unimod modifications in the style '({unimod name} ({optional term specificity} {optional origin})'). All possible modifications can be found in the restrictions mentioned in the command line documentation of e.g. CometAdapter (scroll down a bit for the complete set). Multiple variable modifications can be specified comma separated (e.g. 'Carbamidomethyl (C),Oxidation (M)'). Variable modifications may or may not be found at matching amino acids for a peptide to be reported.

Range of integers with allowed isotope peak errors (MS-GF+ parameter '-ti'). Takes into account the error introduced by choosing a non-monoisotopic peak for fragmentation. Combined with 'precursor_mass_tolerance'/'precursor_error_units', this determines the actual precursor mass tolerance. E.g. for experimental mass 'exp' and calculated mass 'calc', '-precursor_mass_tolerance 20 -precursor_error_units ppm -isotope_error_range -1,2' tests '|exp - calc - n * 1.00335 Da| < 20 ppm' for n = -1, 0, 1, 2.

Percolator provides the possibility to use so called description of correct features, i.e. features for which desirable values are learnt from the previously identified target PSMs. The absolute value of the difference between desired value and observed value is then used as predictive features.

1 -> iso-electric point

2 -> mass calibration

4 -> retention time

8 -> delta_retention_time * delta_mass_calibration

Specifies how search engine results are combined: ConsensusID offers several algorithms that can aggregate results from multiple peptide identification engines ('search engines') into consensus identifications - typically one per MS2 spectrum. This works especially well for search engines that provide more than one peptide hit per spectrum, i.e. that report not just the best hit, but also a list of runner-up candidates with corresponding scores.

The available algorithms are:

• PEPMatrix: Scoring based on posterior error probabilities (PEPs) and peptide sequence similarities. This algorithm uses a substitution matrix to score the similarity of sequences not listed by all search engines. It requires PEPs as the scores for all peptide hits.
• PEPIons: Scoring based on posterior error probabilities (PEPs) and fragment ion similarities ('shared peak count'). This algorithm, too, requires PEPs as scores.
• best: For each peptide ID, this uses the best score of any search engine as the consensus score.
• worst: For each peptide ID, this uses the worst score of any search engine as the consensus score.
• average: For each peptide ID, this uses the average score of all search engines as the consensus score.
• ranks: Calculates a consensus score based on the ranks of peptide IDs in the results of different search engines. The final score is in the range (0, 1], with 1 being the best score.

To make scores comparable, for best, worst and average, PEPs are used as well. Peptide IDs are only considered the same if they map to exactly the same sequence (including modifications and their localization). Also isobaric aminoacids are (for now) only considered equal with the PEPMatrix/PEPIons algorithms.

Limits the number of alternative peptide hits considered per spectrum/feature for each identification run. This helps to reduce runtime, especially for the PEPMatrix and PEPIons algorithms, which involve costly 'all vs. all' comparisons of peptide hits per spectrum across engines.

This allows filtering of peptide hits based on agreement between search engines. Every peptide sequence in the analysis has been identified by at least one search run. This parameter defines which fraction (between 0 and 1) of the remaining search runs must 'support' a peptide identification that should be kept. The meaning of 'support' differs slightly between algorithms: For best, worst, average and rank, each search run supports peptides that it has also identified among its top consensusid_considered_top_hits candidates. So min_consensus_support simply gives the fraction of additional search engines that must have identified a peptide. (For example, if there are three search runs, and only peptides identified by at least two of them should be kept, set min_support to 0.5.) For the similarity-based algorithms PEPMatrix and PEPIons, the 'support' for a peptide is the average similarity of the most-similar peptide from each (other) search run. (In the context of the JPR publication, this is the average of the similarity scores used in the consensus score calculation for a peptide.) Note: For most of the subsequent algorithms, only the best identification per spectrum is used.

Infer proteins through:

• 'aggregation' = aggregates all peptide scores across a protein (by calculating the maximum) (default)
• 'bayesian' = compute a posterior probability for every protein based on a Bayesian network (i.e. using Epifany)
• ('percolator' not yet supported)

Note: If protein grouping is performed also depends on the protein_quant parameter (i.e. if peptides have to be unique or unique to a group only)

This can be protein level if 'strictly_unique_peptides' are used for protein quantification. See --protein_quant