Using full or smart profiling in cases where quant files are being aggregated from separate analyses

[Cajun-data]

Hi Vadim - I am looking for guidance on library generation from DIA data. For speeding up analyses, I have found it beneficial to run datasets in parallel on different CPUs/instances of DIA-NN and then perform a DIA library generation step combined with MBR on the resulting quant files together. You state this in your manual:

It is actually possible to even transfer .quant files to another computer and reuse them there - without transferring the original raw files. Important: it is strongly recommended to only reuse .quant files when both mass accuracies and the scan window are fixed to some values (non-zero), otherwise DIA-NN will perform optimisation of these yet again using the first run for which a .quant file has not been found. Further, when using MBR or creating a spectral library from DIA data with Library generation set to smart or full profiling, .quant files should only be reused if they have been generated in exactly the same order as the current order of raw files, that is with MBR DIA-NN currently cannot combine multiple separate analyses together.

My question is how does your guidance apply to the situation I've described above? Which type of library generation would you recommend in this case?

I ask because I have tested both full and ID/RT/IM profiling and observed a large increase in protein identifications for full profiling in the data I am working with, but it is not entirely clear to me why there would be such a difference - perhaps full profiling has a less conservative FDR estimation?

For context, the DIA library I am working with is fairly small and the datasets are relatively consistent in terms of precursor overlap
Library size:

[4:20] 33977 target and 371 decoy precursors saved

[vdemichev]

Hi James,

In your case basically it means that only IDs, RT and IM profiling should be used, which is the default (and is the best in all known scenarious). However, I am not sure if this limitation on smart profiling actually applies to 1.9.1 or 1.9.2, i.e. maybe the code that caused it has since then been removed - i.e. might work fine.

perhaps full profiling has a less conservative FDR estimation?

In 1.9 and later FDR 'conservativeness' is comparable between profiling modes, the limitation originated from certain code in older versions that assumed the order of files. As I noted, this could have been fixed already, I will check.

and observed a large increase in protein identifications for full profiling in the data I am working with.

Do you happen to have the logs saved (on the same machine, without .quant files transfer) that demonstrate this?

Best,
Vadim