no files detected during import of library from fragpipe

support
no files detected during import of library from fragpipe kguehrs  2021-06-15
 

Hello Skyline team,

I tried to import MSFragger results into skyline. I followed the procedure given in tutorial on the following website by the develeopers of FragPipe.

https://msfragger.nesvilab.org/tutorial_skyline.html

I used the default method "DIA_Umpire_speclib" and the analysis by Fragpipe was successful. I can see the expected number of mzml, pepxml, calibrated.mgf, and interact....pep.xml files in the MSFragger subdirectory of the directory that also contains the raw files. This subdirectory also contains the protein.fas and tsv files generated by MSFragger.

The import of the interact...pep.xml files however failed with the error message shown in the attached file. For me, all the files described in the nesvilab tutorial are available and assume that here is either some file structure problem or some more syntax problem that I do not understand.

Best Karl-Heinz

 
 
Nick Shulman responded:  2021-06-15
That error message is not saying that it could not find a particular file.

The error message "No spectra were found..." means that BiblioSpec looked through your peptide search results and did not find any peptide spectrum matches that were supposed to be added to the library.

Sometimes this can happen if you have set too high of a cutoff score on that first page of the Import Peptide Search wizard.
You have that cutoff score set to 0.98. You could try setting it to a lower number and see if you get any results. Sometimes, if your peptide match scores are really messed up, it is necessary to set that cutoff score to zero, but usually when you do that your .blib file ends up including a lot of very low quality spectra. But setting the cutoff score to zero is a good way to troubleshoot errors like this.

If you would like, you could send us your peptide search result files and everything else.

You can package all of those files up into a .zip file and upload it here:
https://skyline.ms/files.url
-- Nick
 
matt.chambers42 responded:  2021-06-18
Just lost a long reply I'd been typing up for a couple days because the site forced me to log back in after finally posting it.

The gist was that BiblioSpec doesn't currently work with FragPipe DiaUmpire because their mzMLs use the wrong nativeID for their pepXMLs. I'm looking into adding a hack so if the nativeID lookup fails for "index=N" it will also try "scan=N+1" and vice versa.
 
fcyu responded:  2021-10-16

Hi Matt,

Thanks for your hint.

The mzML from DIA-Umpire does not have any native_id attribute. Then, MSFragger writes the index=N, where N = scan number - 1, as the native_id in the pepXML. Hope it helps.

Best,

Fengchao

 
fcyu responded:  2021-10-17

Some discussions in the FragPipe GitHub issue page (https://github.com/Nesvilab/FragPipe/issues/497). Adding a native_id to the mzML file from DIA-Umpire can solve this issue. Am I correct?

Thanks,

Fengchao

 
matt.chambers42 responded:  2021-10-29

Hi Fengchao,

Did the pepXML native_id format change in the last few MSFragger versions? I tested with 3.2 and now the pepXML does contain native_id="index=xxx" which matches the mzML ids from DIA-Umpire (the id attribute IS the nativeId in mzML, you don't need a separate attribute). So although I did go ahead and add a hack for BlibBuild that would allow it to match scan="123" to index="122", it shouldn't be necessary anymore.

-Matt

 
fcyu responded:  2021-10-29

Hi Matt,

Yes, MSFragger writes native_id to pepXML for mzML and mzXML files. If there is a accession="MS:1000796" name="spectrum title", MSFragger will use it as the native_id. If not, it will use the index=xxx as the native_id.

Best,

Fengchao

 
matt.chambers42 responded:  2021-10-31

Do I understand correctly that you don't take the mzML spectrum id verbatim as the pepXML native_id? That would be the correct behavior. Spectrum title cvParam values are not required to be unique and often are not. But spectrum ids and native_ids should be referring to a unique entity (which in pepXML may happen multiple times if there are multiple charge states). I think mzXML should use scan=xxx but using index is not terrible.