Extension of bruker precursor information

[xjasg]

• Extension of the analysis of Bruker files (precursor information) based on the timsconvert Python code
• MS_inverse_reduced_ion_mobility, MS_collisional_cross_sectional_area, MS_peak_intensity.

[chambm]

As far as I can tell, these attributes are not allowed in mzXML 3.2 and there's no newer schema AFAIK. If it's not in the schema, we can't write it, so as not to produce schematically invalid files. Is there a need for this, or were you just being thorough by supporting the new parameters in all our serializable formats?

[xjasg]

Yes, I have extended this so that the new keys are written and also because the tests would otherwise fail.

[chambm]

Which test failed if you didn't write these attributes? There's a lotof metadata in mzML that doesn't fit in mzXML, so we don't diff metadata AFAIK.

[xjasg]

Maybe something else is wrong, but without these changes I got this as test result:

• spectrum:
  index: 2
  id: merged=2 frame=2 scanStart=211 scanEnd=235
  defaultArrayLength: 0
  precursorList:
  precursor:
  spectrumRef:
  isolationWindow:
  cvParam: isolation window target m/z, 1426.71440688228, m/z
  cvParam: isolation window lower offset, 1.5, m/z
  cvParam: isolation window upper offset, 1.5, m/z
  selectedIons:
  selectedIon:
  cvParam: selected ion m/z, 1426.71440688228, m/z
  cvParam: inverse reduced ion mobility, 1.403511815279, volt-second per square centimeter
  cvParam: peak intensity, 272.0, number of detector counts
  activation:
  cvParam: collision-induced dissociation
  cvParam: collision energy, 42.0

• spectrum:
  index: 2
  id: scan=3
  defaultArrayLength: 0
  precursorList:
  precursor:
  spectrumRef:
  isolationWindow:
  cvParam: isolation window lower offset, 1.5
  cvParam: isolation window upper offset, 1.5
  selectedIons:
  selectedIon:
  cvParam: peak intensity, 272.0, number of detector counts
  cvParam: selected ion m/z, 1426.71440688228, m/z
  activation:
  cvParam: collision energy, 42.0, electronvolt
  cvParam: collision-induced dissociation

Error testing on C:\github\pwiz\pwiz\data\vendor_readers\Bruker\Reader_Bruker_Test.data\Hela_QC_PASEF_Slot1-first-6-frames.d (config-combineIMS-centroid.mzML-threshold-top3): [C:\github\pwiz\pwiz\utility\misc\VendorReaderTestHarness.cpp:435] Assertion failed: !diff_mzXML

[brendanx67]

Mind if I ask who you are xjasg. Your GitHub profile is pretty thin and appears to have been created for this work. We always appreciate help. Just hard not to be curious about the source, e.g. especially whether you work at Bruker or happen to be a talented programmer working in a lab with a Bruker instrument. Thanks for your contribution to the project!

[xjasg]

@brendanx67 : Hi Brendan, my name is André Schöngraf. I come from Thuringia in Germany and work as an external developer for the company Zontal. I don't know if the names mean anything to you, but I'm mainly involved with Wolfgang Colsman and Antje Mohr. They wanted to expand the precursor info for Bruker. I don't know if I'm talented, but I hope so ;-)

[chambm]

OK I figured out the mzXML failure. We do check the selectedIons for mzXML<->mzML because that's very important scan metadata that so far we've assumed mzXML could represent. That's not true for the ion mobility attributes, so when those are present in the mzML but aren't serialized in mzXML the difference will trigger the test failure.

All the vendor formats currently store the current scan's ion mobility in the <scan> element, which I missed when I earlier reviewed this PR. But actually according to the CV properties of the ion mobility terms, <selectedIon> is technically correct and <scan> is incorrect. However, ProteoWizard has been writing IM attributes to <scan> for years, so I don't think I want to change it. So the part of this PR that puts IM and CCS in the selectedIon should be removed as redundant. The peak intensity is still a good addition!

Note that your way of calculating 1/k0 is a little different than the existing one that puts the value in the <scan> element. If your method is superior then I'd like to understand why and just change the current TimsSpectrum::oneOverK0() function to use that method. I suppose we can add CCS to the <scan> element although that will technically be invalid mzML (I'm not sure there is a valid way to put it in mzML right now except as a userParam).

This code:

 for (auto it = scanNumberByOneOverK0.begin(); it != scanNumberByOneOverK0.end(); ++it)
                {
                    if (it->second == round((info.scanEnd - info.scanBegin) / 2.0) + info.scanBegin)

needs to be fixed to just directly lookup the 1/k0 value in the oneOverK0ByScanNumberByCalibration_ map.

[xjasg]

I have revised this and created a new branch. I'll create a new PR in the next few days if that's okay for you.