Optimized collision energy spectra

[sneumann]

Issue by schymane from Thursday Nov 21, 2013 at 12:28 GMT Originally opened as https://github.com/sneumann/RMassBank/issues/41

---

A new case at Eawag: standard spectra recorded with one MS/MS only with optimized collision energies in one run. This is then the CE used in our target methods.

• use current options and save "optimized CE" rather than e.g. HCD60 (quick fix?)
• read out the CE from the mzML (not such a quick fix)
• There may be a "rule" for the optimization based on m/z

mstravs, schymane to discuss

[sneumann]

Comment by sneumann from Thursday Nov 21, 2013 at 13:12 GMT

I would favour extracting the energy from the raw files. Steffen.

[sneumann]

Comment by meowcat from Monday Nov 25, 2013 at 08:41 GMT

---

• read out the CE from the mzML (not such a quick fix)

Reading out the CE per se is not a problem; current mzR does this at least for our files. (However assigning the read CE to a spectrum in the spectraList or subsequently using it in the output is something we'd have to implement.)

The problems are rather: (here for readout in general, not specific for optimized collision energy spectra)

• things like distinguishing CID and HCD - not in the standard mzR output. They can be fake-distinguished if we mandate that in the spectraList there should never be CID and HCD at the same energy, but this is a fake fix and rules out experiments that are not unreasonable per se. It can be read out with the XML snippet I posted once, but again this is work.
• our standard Orbitrap experiment which has two resolutions per energy - also not read by mzR and I don't even remember whether it's in the mzML at all. However since we basically found out that the multiple resolutions don't really help much (except for multiplicity filtering but this could be done as well with two spectra at the same resolution), we could think about dropping this experiment in the future.

The thing is that if we want to support direct readout, we have two options: use direct readout throughout, which would be consistent but quite some work to implement; or introduce another parameter which asks how CE should be determined, which adds even more clutter to everything.

[sneumann]

Comment by meowcat from Friday Nov 29, 2013 at 09:29 GMT

---

If this is one way to address the problem with a lack of CE in mzML for some instruments AND the problem with "optimized CE" experiments where one batch of files has MS/MS with different a CE for different compounds (Issue #41), that may be worth considering...

"Jein". Adding the CE to the filelist in order to map compounds, files and spectra to entries in the spectraList is one thing. To make mbWorkflow use some read-out CE (or a CE specified somewhere else) instead of a CE loaded from the spectraList, is an additional task. It's not impossible or anything, but requires some thought. For example: how do we specify this in the settings file? how would we reproducibly assign a MassBank accession number? will there ever be one CID and one HCD optimized spectrum (or any other combination of "multiple optimized spectra" for which there has to be a way to determine accession numbers?)

To clarify for Steffen and Erik, who were not yet involved when the spectraList was introduced: one raison-d'être of spectraList (versus reading all possible information directly from raw files) is to reproducibly assign MassBank accession numbers, such that if I specify a set of spectra recorded in an experiment, the generated spectra for a given compound will always have the same MB accession numbers. In this way, one can easily replace a spectrum if it is bad for some reason, without having to worry about what accession number it will get when regenerated, and whether it is already taken, etc.

[sneumann]

Comment by tsufz from Monday Dec 02, 2013 at 07:45 GMT

---

Should we add a DB table were the assigned accession numbers are stored? This could help people without DB or else to keep overview on their files? However, this is a minor issue.

Am 29.11.2013 10:29, schrieb meowcat:

To clarify for Steffen and Erik, who were not yet involved when the spectraList was introduced: one raison-d'être of spectraList (versus reading all possible information directly from raw files) is to reproducibly assign MassBank accession numbers, such that if I specify a set of spectra recorded in an experiment, the generated spectra for a given compound will always have the same MB accession numbers. In this way, one can easily replace a spectrum if it is bad for some reason, without having to worry about what accession number it will get when regenerated, and whether it is already taken, etc.

Dr. Tobias Schulze

Wissenschaftlicher Mitarbeiter / Research Scientist Department Wirkungsorientierte Analytik / Effect-Directed Analysis

Helmholtz-Zentrum für Umweltforschung GmbH - UFZ Helmholtz Centre for Environmental Research - UFZ Permoserstraße 15 / 04318 Leipzig / Germany phone +49 341 235 1083 / fax +49 341 235 451083 tobias.schulze@ufz.de / www.ufz.de

Sitz der Gesellschaft: Leipzig Registergericht: Amtsgericht Leipzig, Handelsregister Nr. B 4703 Vorsitzender des Aufsichtsrats: MinDirig Wilfried Kraus Wissenschaftlicher Geschäftsführer: Prof. Dr. Georg Teutsch Administrativer Geschäftsführer: Dr. Heike Graßmann

Bitte denken Sie an die Umwelt bevor Sie diese E-Mail ausdrucken. Please consider the environment before printing this e-mail.

[schymane]

To revisit this again:

I would favour extracting the energy from the raw files.

I don't see any other option right now if we want to make this functional. I'm currently trying to extract target compounds from DD-MS/MS, all I have is the mz and RT. We have a list of our target collision energies somewhere but it's hit and miss. Best thing is from the raw data to be sure. Wrt the accession numbers, we still have a whole lot of upper numbers available, we could set optimised CE numbers to e.g. 80+.

In terms of clashing accession numbers, an output of current accession numbers would be a nice addition to the "repack" script, I also already had an idea how to do this and should do it for our Eawag records anyway, when mixing EAs and EQs and various adducts...

[schymane]

Steffen to look into expanding mzR capabilities for global solution to these issues. See https://github.com/sneumann/mzR-playground/issues/17