Waters dda and lockmass fixes #2770
Conversation
Fixes failure when using --ddaProcessing when non-MS function is present (INFDAAP-113) Partial fix precursor m/z are not lockmass corrected for realtime lockmass corrected data (INFDAAP-258)
We read DDA scans twice, once to build a list of RTs to export and once to actually export. The binary spectra data is only needed on the second read but was being read both times. Fixed so the data is only read when needed.
Intention is that precursor m/z is the lockmass corrected setmass This did not always happen as precursor m/z was calculated during building of the ddaIndex which happend before lockmass correction was called Changed so that precursor m/z is calculated as the DDA scan is about to be exported and so after lockmass correction has been called
Code assumed that lockmass function in SONAR/HDMSe data would not be multidimensional which is not correct. This lead to it trying to read the lockmass function of the SONAR test data as if it was not multidimensional resulting in a crash. This didn't break before because IsLockMassFunction(...) was incorrectly returning False for the lockmass function
| if (useDDAProcessor_) | ||
| { | ||
| setMass = ie.setMass; | ||
| getDDAPrecursorMasses(index, setMass, ddaPrecursorMass); |
There was a problem hiding this comment.
Does this mean only the DDA processing mode will get lockmass-corrected m/zs? I suppose that is the most important case but it would be nice to be consistent to always provide all lockmass-corrected m/zs for all m/zs when lockmass is applied. Was an SDK function that just takes an m/z and returns the lockmass-corrected m/z not feasible?
There was a problem hiding this comment.
I think the only other cases where you could lm correct the setmass would be for SONAR data. If you applied the correction to SONAR data then you would introduce a change that the SONAR quad window positions would vary slightly from spectrum to spectrum as lockmass correction varies over time.
There is an SDK function which returns a lockmass correction
int getLockMassCorrection(const CMassLynxBaseProcessor mlLockMassProcessor, const float retentionTime, float* pGain);
though that gives a 'gain' you have to multiply with your m/z to get the lockmass corrected version, a method which takes the uncorrected m/z and returns the corrected version would be nicer. The correction we are applying isn't quite as simple as that though. The lockmass correction which is used is the correction for the RT of the survey scan proceeding the MSMS spectrum, though in practice this will only make a tiny difference. The rationale behind this is that the setmass was selected based on measurements of the survey scan.
There was a problem hiding this comment.
Good to know about the SDK function. I'd like to use for the setMass even when DDA processing mode hasn't been applied. But you're right that's probably the only situation it makes sense. It would probably be undesirable for the m/z bounds of DIA isolation windows to change, for example.
|
The lockmass refiner test fails as it should. I'll handle updating that reference data. And thanks very much for the PR! It's great to get updates directly from the vendors! |
|
Superceded by #2778 |
a Failure to export Waters DDA data if none-MS functions are present
b Can't lockmass correct precursor m/z of Waters DDA where mass spectra are lockmass corrected in the instrument
c allows other fixes below
a When we build the "DDAIndex" prior to exporting data using the -ddaProcessing option we used to read but not use all of the spectra binary data. We've made use of a new endpoint to the SDK which makes it possible to read the necessary meta data (RT, setmass) without also reading the binary data
a The intention of the ddaprocessor is that the precursor is the lockmass corrected setmass. This often doesn't work because the precursor m/z values were calculated before lockmass correction was applied. We've changed it so precursor m/z is calculated just before they are needed.
a Uses a new SDK endpoint which allows you to specify that spectra produced by the DDAProcessor should be centroided.
a Switch to using an endpoint in the MassLynx SDK to identify the lockmass function. This fixes issues where lockmass spectra were being exported even though 'ignoreCalibrationScans' option was being used.