OpenMS and frequently mass shifts in Unimod

[ypriverol]

Description of feature

@MaLLLiYA @timosachsenberg @jpfeuffer @daichengxin :

We have been analysing some of the datasets and we found some interesting unexpected PTMs (mass shits), most of them are here:

https://unimod.org/modifications_list.php?a=search&value=1&SearchFor=Unidentified+modification+of&SearchOption=Contains&SearchField=

1970 |   | Unknown:162 | Unidentified modification of 162.1258 found in open search | 162.125595 | 162.2267 | H(18) C(8) O(3)

Can we make sure these mods works in OpenMS? Also, Can you let us know @timosachsenberg how you can search with OpenMS tools for a delta mass when the mod is not defined on OpenMS?

[jpfeuffer]

I think you have to add the mods as CUSTOM0..CUSTOM9 to the unimod.xml in the OpenMS share.

[daichengxin]

In search engine adapter, there is a mass_offsets paramter. Is it applicable?

[ypriverol]

I think you have to add the mods as CUSTOM0..CUSTOM9 to the unimod.xml in the OpenMS share.

But can this be done dynamically, or we need to add this inside OpenMS and wait for the release?

[jpfeuffer]

I think this is a comet specific extension, right?
It sounds like this is a MS1 offset only. I am not sure if it will consider those offsets for every fragment.

If this is what you want, it might work.

[ypriverol]

This is a good point, if this mass shift is for unexpected PTM - for example 1970 | | Unknown:162 | Unidentified modification of 162.1258 found in open search | 162.125595 | 162.2267 | H(18) C(8) O(3) in order to identify those peptides, the precursor mass offset should define that mass offset but also the fragment tolerance?

[timosachsenberg]

by default search engines assume that the mass shift on the precursor is also observed on the fragments carrying the PTM (e.g., no neutral loss on the PTM is assumed).

[jpfeuffer]

I think you have to add the mods as CUSTOM0..CUSTOM9 to the unimod.xml in the OpenMS share.

But can this be done dynamically, or we need to add this inside OpenMS and wait for the release?

This can be done dynamically.

[jpfeuffer]

by default search engines assume that the mass shift on the precursor is also observed on the fragments carrying the PTM (e.g., no neutral loss on the PTM is assumed).

@timosachsenberg But the "mass_offsets" parameter is not for a PTM. You cannot associate a specific AA to that mass_offset, so it wont know which fragments would hold this mass_offset. Therefore I assume this is an MS1-only feature of Comet.

[timosachsenberg]

Agree. I really think easiest is to modify the unimod.xml entries for the custom mods. Then it is automatically understood by all tools.

If we can't modify unimod.xml we need to add parameters to all tools that should understand the custom modification (because otherwise peptide masses are not calculated correctly in downstream tools).

[ypriverol]

My point is more generic: some of these "custom" pipelines, MOD mass-shifts should be easy to pass ass custom mods without the need to recompile the entire OpenMS pipeline. If you think, it is supported, then we can try one example and see if really custom mass shifts can be analyzed in quantms.

[jpfeuffer]

Yes it's supported. You will need to add the custom unimod.xml to every step though. You can just add the XML entry with

echo "<modification name="foo" mass=123.4/>" >> Openmsshare/unimod.xml

No, it is not easy to "just" support this in the whole pipeline because you would need to encode everything about that modification in every output file you write to make sure that the next tool understands what this mass shift is. Either you will have super verbose files or you need a common file like that unimod.xml

[ypriverol]

I was thinking and mentioned to Timo that it would be good to support mass shifts as mods in OpenMS. The idea is that we can add a mass shift and keep it in the entire workflow rather than the unimod.