Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Learn from rustims #64

Open
douweschulte opened this issue Feb 10, 2025 · 7 comments
Open

Learn from rustims #64

douweschulte opened this issue Feb 10, 2025 · 7 comments
Labels
A-core Area: core structures, traits, and algorithms

Comments

@douweschulte
Copy link
Member

@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)
@douweschulte douweschulte added the A-core Area: core structures, traits, and algorithms label Feb 10, 2025
@mobiusklein
Copy link

  • 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
Copy link

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
Copy link

mobiusklein commented Feb 10, 2025

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
Copy link

theGreatHerrLebert commented Feb 11, 2025

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
Copy link

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
Copy link
Member Author

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-core Area: core structures, traits, and algorithms
Projects
None yet
Development

No branches or pull requests

3 participants