Spectronaut/MSstats: should fragments of non-identified peptides contribute to protein abundance?
Adrian Hautmann
Dear MSstats community,
I analyze Orbitrap Astral DIA data using Spectronaut and MSstats.
Protein abundance results differ substantially between Spectronaut and MStats, due to the "Precursor Filtering : Identified (Q-value)" in the quatification settings of spectronaut.
When "Quantification Data Filtering" is not marked (as inteded by the MSStats Report (v.3.7.3) report scheme) , low-level MS2 signals that appear to be background can produce protein abundance estimates despite the absence of accepted identifications. Given the Astral’s high MS2 sensitivity, this seems particularly relevant.
Is this expected and desirable behavior, or should these signals be excluded before MSstats processing?
Should Spectronaut’s “Quantification Data Filtering” be enabled, and which settings (particularly Precursor Filtering etc.) would you recommend?
Thank you!
Adrian
Swaraj Patil
This is a real gap rather than a misconfiguration. SpectronauttoMSstatsFormat has a filter_with_Qvalue argument that defaults to FALSE, so by default MSstats applies no q-value cutoff at all. If Spectronaut's own quantification filtering is also off, nothing filters, which is most likely why your two sets of abundances diverge.
Set filter_with_Qvalue = TRUE and qvalue_cutoff = 0.01 to enable it. Note that the switch turns on filters for both EG.Qvalue and PG.Qvalue, though qvalue_cutoff sets the threshold for EG.Qvalue only; PG.Qvalue is fixed at 0.01.
Worth knowing it does not drop rows. It blanks the intensity and leaves the row in place, so MSstats treats the measurement as censored and imputes it rather than ignoring it. I would filter here rather than upstream in Spectronaut, since that keeps the full feature by run grid visible to MSstats.
Your point about the Astral is well taken, and I will raise internally whether the default should change.
Best,
Swaraj
Adrian Hautmann
Hi Swaraj,
Thank you for the clarification and taking your time to consider my request. Especially, the helpful consideration that keeping Spectronauts filtering off and not deleting the rows, helps with imputation.
Still, one issue remains:
some of my precursors have EG.Qvalue < 0.01, but EG.Identified = FALSE, and Spectronaut reports no accepted protein identification in that run (PG.Qvalue (Run-Wise).
However, the experiment-wide PG.Qvalue is below 0.01, so filtering on EG.Qvalue and PG.Qvalue would still retain these intensities. (I think also EG.QValue is determined across all runs and not run specific)
Does the converter consider run-wise protein or EG confidence?
Would you recommend an additional filter using PG.Qvalue (Run-Wise) or EG.Identified, or is retaining these signals as observed intensities for protein abundance estimation intended behavior?
Best,
Adrian
Swaraj Patil
Good question. We looked at it internally and the answer is no on both counts.
EG.Identified reflects the cutoff you set in Spectronaut's own interface rather than an independent measure, so it is not something the converter can reason about. The
q-value columns are the meaningful input.
On run-wise PG.Qvalue, we are not filtering on it. Protein-group q-value estimation is still an open problem and the metric is not considered reliable enough to filter on by default. EG.Qvalue is calculated more soundly, which is why the precursor-level filter is the one we lean on. If you want the run-wise PG filter for your own analysis it is straightforward to apply to the report before conversion.
So retaining those signals is intended, with the caveat that the filtering we do apply is at the precursor and experiment-wide protein level rather than run-wise.
Best,
Swaraj
Adrian Hautmann
Hi Swaraj,
Thank you for taking the time to discuss this and explain the rationale.
This clarifies why the converter retains these intensities rather than applying Spectronaut’s run-wise protein filter.
I have also read the recent MSstats+ paper:
Incorporating peak-quality metrics seems a promising approach to reducing the influence of potentially interfering MS2 signals. This might mitigate my problem.
Thank you again for your helpful guidance!
Best,
Adrian