FAIMS support

[SGhosh2019]

Hi,
Does DIANN support FAIMS .raw files?

[vdemichev]

Hi, yes, provided the Cv was fixed during the run.

[SGhosh2019]

Hi again,

Sorry, not very clear to me. What do you mean by 'CV fixed during the run'; I have 2 CVs and 3CVs in the method.

[vdemichev]

HI, for example FAIMS runs from this paper https://www.mcponline.org/content/early/2020/02/12/mcp.TIR119.001906 (they are with 'single CVs') are fully supported by DIA-NN

[SGhosh2019]

Hi Vadim,

Thank you. I guess multiple CV files have to be extracted per CV for DIA-NN. I will try that. Just wondering if DIA-NN also reports data points across peak and cycle time?

[vdemichev]

Hi, in the stats.tsv file DIA-NN reports mean peak width at FWHM (full width at half maximum), measured in minutes and scans. This allows to infer the cycle time. The average number of data points per peak is reported by DIA-NN in the log when analysing with Scan window set to 0.

[SGhosh2019]

Thank you

[vdemichev]

Hi, have you tried running multiple-CV FAIMS acquisitions with DIA-NN? Any success?

Vadim

[SGhosh2019]

Hi,
Yes, I extracted multiple FAIMS annotation into separate raw files and uploaded to DIA-NN. It did work technically without throwing any error, but I was not sure if FDR was inflated during the prediction. Even multi-CV .raw files were accepted if I remember correctly, but I think only one CV was selected during processing. Do you have plans to include multiple CV support in the future?

[SGhosh2019]

Congratulation on the scanning SWATH paper. I am excited to read it!

[vdemichev]

OK, many thanks for the information! Yes, would be cool of course to have full support here, the reason I asked was to check if maybe it's already fully supported ))
I don't think FDR will be a problem, quantification might be, identification numbers might also be a bit on a low side. Would you be able to maybe share such a file (a multi-CV one) for me to take a look at (the smallest available)?

[SGhosh2019]

Yes of course. I can share a HeLa file acquired with 2 CVs in a 2-hour gradient. Hope that will be ok!

[vdemichev]

Yes, would be very cool, many thanks! Can you please email me the link (my email is at the bottom of the first page of the DIA-NN manual https://github.com/vdemichev/DiaNN/blob/master/DIA-NN%20GUI%20manual.pdf)?

[vdemichev]

Preliminary, it looks like when splitting a multi-CV FAIMS file, DIA-NN should perform just fine. This is probably not fully optimal performance-wise (with proper support it's likely possible to improve the data quality a bit), but should be OKish. When analysing the original .raw file, DIA-NN does indeed consider all CV channels at once, but does so in a strongly suboptimal way, so identification numbers are suboptimal and quantification is unreliable.

So for now, until full support for multiple CVs is implemented, I do recommend splitting the raw files in separate channels.

[vdemichev]

So the strategy is this:

• split all multi-CV files to obtain one file per CV channel
• analyse each CV channel as a separate experiment in DIA-NN
• combine the reports using R, select the 'best' channel for each precursor ion, discard all other channels for this precursor
• perform protein quantification using MaxLFQ with the diann R package or the "iq" R package (the latter is currently much faster)

[sampie]

Hi

May I ask, how the FAIMS DIA-data files were split? With what tool?

[kabalak]

A very good question: using https://github.com/PNNL-Comp-Mass-Spec/FAIMS-MzXML-Generator yields only .MzXML files which cannot be handles by Dia-NN?

[FloRDQC]

Hi,

Does anyone knows how to split Thermo multi-CV raw files prior to DIA-NN processing ?
I have tried with the above mentioned FAIMS-mzXML generator and then converted the splited files to mzML with MSConvert but I did get an error with DIA-NN.
Any other idea on how to do this ?

[kabalak]

The only way I can think is to use Thermo's FreeStyle tool: Nesvilab/FragPipe#662 (comment)
But directly working with the non-CV-split .raw files also works, but the question remains, whether the quantifications are reliable enough in that case. In terms of IDs, I did not observe crude differences between directly taken .raw files and CV-split .raw files.

[FloRDQC]

Thank you so much ! It works with FreeStyle (as soon as you manually enter the cv value and not use the auto-filters as I did before). I then exported the splitted files using the function 'Export to raw' of FreeStyle.

Regarding the use of no-split files, I asked Vadim and received this answer :
"Lack of error without splitting is not indicative. Multiple-CV runs are just not supported. Basically, identification performance is most likely only slightly affected (but can be severely affected, I simply don't know), however quantification can be affected significantly. The most reasonable quantification mode is probably Robust LC (high precision), but even then no guarantees that it works OK."

I am going to try both and compare the results in terms of IDs and quantification accuracy.

[kabalak]

Regarding the use of no-split files, I asked Vadim and received this answer : "Lack of error without splitting is not indicative. Multiple-CV runs are just not supported. Basically, identification performance is most likely only slightly affected (but can be severely affected, I simply don't know), however quantification can be affected significantly. The most reasonable quantification mode is probably Robust LC (high precision), but even then no guarantees that it works OK."

I am going to try both and compare the results in terms of IDs and quantification accuracy.

Did you have any chance to make this comparison and what is the bottom-line message for the outer world?

[TTCooper-PhD]

Thank you so much ! It works with FreeStyle (as soon as you manually enter the cv value and not use the auto-filters as I did before). I then exported the splitted files using the function 'Export to raw' of FreeStyle.

Regarding the use of no-split files, I asked Vadim and received this answer : "Lack of error without splitting is not indicative. Multiple-CV runs are just not supported. Basically, identification performance is most likely only slightly affected (but can be severely affected, I simply don't know), however quantification can be affected significantly. The most reasonable quantification mode is probably Robust LC (high precision), but even then no guarantees that it works OK."

I am going to try both and compare the results in terms of IDs and quantification accuracy.

Any progress on this?