Learn from rustims

[douweschulte]

@theGreatHerrLebert has some nice things already built in rustims that we could look into taking up. Below is a list of things I found that are missing in the current mzcore:

• get_num_protonizable_sites
• simulate_charge_state_for_sequence
• convolved isotope model
• IMS calculations (eg 1/k0 and CCS)
• reading+writing timsTOF files (either in mzdata or its dependency)

[mobiusklein]

• mzdata already supports reading timsTOF data using timsrust for decoding, enabled by the bruker_tdf feature, both in the form of single or summed spectra and in ion mobility frames. Unfortunately, it's not yet documented, and the IonMobilityFrame type is less well-exercised than I'd like.

  mzdata::IonMobilityFrameLike implementations use mzpeaks::FeatureLike types instead of peaks reflecting that they are a coordinate spread across a dimension, usually time, but otherwise mirror mzdata::SpectrumLike types. Computationally, they are more expensive to manipulate. The "right" design is application-dependent, to some extent.

• The CCS<->IM calculation is an instrument setting-dependent, vendor-specific operation.

[theGreatHerrLebert]

Hey guys, thanks for looking into my code!
• I think it makes sense to use timsrust for I/O, as long as you can live with NO-SDK mode. If someone is interested in accessing timsTOF data from Rust by calling the Bruker translation functions (TOF → m/z and Scan → inverse ion mobility), I could ask if Sander would be open to a pull request that introduces this functionality. We found that invoking the timsrust functions right now can yield significant differences compared to SDK-based index translation. This is a known issue also within alphaTIMS.
• The conversion between CCS and inverse mobility (and vice versa) implements the Mason–Schamp equation. This should be usable for all devices employing low-field IMS—as long as you have a rough idea of the gas pressure and gas type used, it should not be vendor specific.
• The convolution algorithm for isotopes is based on these slides.

[mobiusklein]

Thank you for the links, and the comment about the SDK vs. no SDK output. I was seeing tiny differences vs. ProteoWizard but there are calibration options that the timsdata library has but that ProteoWizard doesn't use (https://github.com/ProteoWizard/pwiz/blob/a435cb154aedb2ad9413f29c4aeb86d3c115b242/pwiz_aux/msrc/utility/vendor_api/Bruker/timsdata_cpp_pwiz.h#L131C77-L139). There were other mentions of calibration that I couldn't associate with a function either.

My statement about CCS calculation portability was w.r.t. different instrument vendors whose devices work differently, e.g. TWIMS, because getting from their reported values to K0 is harder.

[theGreatHerrLebert]

Yes, as far as I understand, the Bruker SDK uses a patented algorithm (some polynomial), so unfortunately at this time there is no way to extract data calibrated using this method from the raw files.

The Mason–Schamp equations indeed might not work for TWIMS, since TWIMS might violate some equation’s assumptions. However, it should work fine for timsTOF. If you’re interested, I could create a pull request for them and the convolution isotope composition generator algorithm, using your isotope building blocks instead of mine.

[mobiusklein]

The convolutional algorithm would be good to have. Does it have to be converted to a profile and then re-centroided to be useful?

I might re-implement it in another project too, for my own education. I've put off fine structure generation since I haven't had a dataset where it was necessary, but having hammers and recognizing nails and all that. I have an implementation of the BRAIN algorithm from http://pubs.acs.org/doi/abs/10.1021/ac402731h which is fast, but specifically doesn't do fine structure.

[douweschulte]

Sounds like a fancy isobaric distribution algorithm. If it is al round superior to the current implementation feel free to swap it out. Otherwise it might be good to keep both of them around (or all three as Davids also is complementary).

[theGreatHerrLebert]

There is also the isospec algorithm, might be of interest for the project as well. This one is also part of OpenMS.

[jspaezp]

https://github.com/jspaezp/timsrust-calibration

@mobiusklein
@theGreatHerrLebert

this is as close as i've gotten to implement a calibration that works with my data.
It is my understanding that it is not the same polinomial bruker uses in the sdk but works a lot better on my data than the linear interpolation bundled with timsrust.

Its nothing fancy ... was just a lot easier to "figure out" when one of our timstofs had a failed chiller and had the "blessing" of collecting data with a 10 degree temperature offset.

[mobiusklein]

I just started playing with that after I backported it to work with timsrust v0.4.1. I was curious how you came to those equations since I want to make a vocabulary of grid models.

[jspaezp]

can you elaborate what you mean by vocabulary of grid models ? (the equations were a long run of ... comparing results from diann and sage from the same files and doing several attempts at regression, (in parallel) using the internal m/z for DDA files then some discussions with Brian Searle to write the terms in terms of physics and then some claude auto-research feeding the data with the large mass errors from the temperature shift we had in-house ... I have somewhere a branch or two in my fork of timsrust that has some of the forensics)

[mobiusklein]

What I have in mind is that almost all vendors report a digitized grid along the m/z axis, with some form of calibration converting the grid coordinates to m/z. For TOFs, it's some variant of $t=k\times\sqrt{m/z}$ so $\sqrt{m/z} = t/k$, with the value of $k$ some blend of factors from the hardware, and acquisition software. Being able to name a grid reconstruction procedure makes it easier to reuse once we know the equation. This idea was an important part of imzML's space savings, and could have been an even larger boon for mzMLb though it failed for other reasons. I'm working towards something similar on mzPeak.

The goal there is to be able to "make a space" for vendors to natively write their grids as long as they tell us how to decode them. Then we maintain the rest of the structure for them. It is admittedly a building it so people will come approach which is known to be doomed in the modern age.