Error when creating spectral library from .mzID and .mgf export from PEAKS

Error when creating spectral library from .mzID and .mgf export from PEAKS Juan C. Rojas E.  2022-06-30

Hi team,

The most recent version of Skyline-daily ( is now preventing me to create a spectral library from a PTM search from the export created for Scaffold (.mzID and .mgf files). I have been using this since creating a spectral library with the export for Skyline (.pep.xml and .mzxml) simply takes too long for timsTOF data.

As Matt pointed out (, it seems to be an issue with PTMs. I can create a spectral library when only Cys carbamidomethylation and Met oxidation are considered (PEAKS DB attached search). But when I try to create it with the results of all default PTMs withing PEAKS (PEAKS PTM attached search) then I receive a warning that does not allow me to finish.

What could be the problem? Let me know if I can help in any other way.
Juan C.

Matt Chambers responded:  2022-06-30

The problem is that PEAKS is including UNIMOD ids that have been deleted. And instead of marking those deleted accessions as such (or as obsolete) in their xml/obo downloads, UNIMOD just excludes them entirely. So our software has no way of knowing what those ids mean because we use an updated version of UNIMOD.

The fastest workaround here is to delete the unknown mods from the mzIdentML. This one may be the only deleted one and it wasn't actually referenced in the search results:
<SearchModification residues="H" massDelta="72.021126" fixedMod="false">
<cvParam accession="UNIMOD:915" cvRef="UNIMOD" name="Ethoxyformyl" />
You may have to delete and re-import several times to find all the deleted mods (accession 20000915 refers to UNIMOD:915). The 915 mod is near the end of the list so it shouldn't take many times (probably that's the only one).

If you can, deselect this mod your PEAKS settings. I am trying to get a version of unimod.obo from UNIMOD that includes the deleted ids so we can avoid this problem in the future.

Juan C. Rojas E. responded:  2022-06-30

Hi Matt,

There could be a way, but it is not feasible for the "all PTM" default searches. I guess some edits to the default internal library of PTMs is possible, but not something that can easily be done from the GUI.

What about marking those obsolete mass shifts as mass shifts that are not recognized as it does for custom PTMs not available in unimod? Then it is up to the user if it bothers in looking it up from the unimod database to keep them or not?

Juan C.

Matt Chambers responded:  2022-06-30

Right now ProteoWizard is designed to always expect to know what a cvParam accession refers to. Being able to download a newer version of the CVs to see if an unknown accession has been recently added is something that is planned, but not implemented yet. And getting those updated CVs would be necessary in order to tell the difference between an accession that is properly defined in a newer version of a CV than we're using locally, and an accession that is wrong or deleted. The latter kind of accession could be safely skipped as you suggest, but the former kind should just get the details from the internet if possible, and if not, should probably error out, at least in the general case. For unknown UNIMOD accessions I agree it would be reasonable to just show them as "unknown" mass shifts if there's no internet connection.

Matt Chambers responded:  2022-07-13

Unknown Unimod accessions should be marked as such in the next Skyline-daily.