Waters data

[schymane]

Other updates to the XCMS Online are: • Waters Instrument users now have a reader for RAW data on XCMS Online Follow-up?

[meowcat]

Possibly they use this here? http://www.metabolomics-forum.com/viewtopic.php?p=1694&sid=3c42930252391db6584e9141260d6119#p1694 https://github.com/stanstrup/chemhelper If so, we should check what this package does (however we need a computer with Waters software on it - surely somewhere we could have that?) and consider a new backend for msmsRead for Waters data. This is, IF it really helps us to process something that we can't process now.

[schymane]

So, we need to check if this can give us recalibrated data to work with in RMassBank. Steffen/Erik, can you follow up (medium priority)? We should have some test data (and Steffen maybe has some background knowledge, keyname "stanstrup"). It looks like it needs some additional dependencies ("MassLynx need to be installed and masswolf need to be in path") but also "This functions converts waters' .raw files to mzData. This function is slow and only exists because other conversion software does not currently correctly remove lockmass scans (masswolf) or does not give calibrated data (ProteoWizard)". Looks like it has some potential to help.

[meowcat]

I wrote a thing which, starting from a normal ProteoWizard mzML, can extract the lockmass scans and make a retention time dependent recalibration. Also it can separate the low energy from the high energy scans (which are all marked MS1). If we can feed this data into the xcms workflow (which will be necessary to handle the data properly because it averages masses) we should be able to get out peaks which we then can recalibrate. @sneumann @ermueller

[schymane]

Priority high: mid-late October. Visit 1st week of November to institute with Waters data to get records happening. Test data: UJI.

[meowcat]

Just wanted to try someting and found that xcmsRaw can't read proteowizard-converted Waters mzML out of the box - the reason for this is that they store their scans in blocks according to scan type (for example 1-800 MS1, 801-1600 MSe, 1601-1900 lockmass) and the 801 will start at 2 seconds again...

Possible solutions are: either on the XCMS side something is done to read unsorted scans, or we have to either construct an xcmsRaw ourselves, or find a way to read them without XCMS.

[sneumann]

http://proteowizard.sourceforge.net/tools/filters.html sortByScanTime This filter reorders spectra, sorting them by ascending scan start time. If that doesn't help, we need to think about something clever.

[schymane]

Alternative plan that was mentioned was to get a calibrated netCDF through xcmsRaw - didn't Erik have something there?

[schymane]

netCDF: if we have exact RT, may be able to use this. Need something to find the precursor.

[meowcat]

This TOF thing is really strange. If you look at the headers, the base peak mass is correct / recalibrated apparently, however the real base peak mass (the mass at max intensity) returned by peaks() is not calibrated.

Here a recalibration done without any involvement of the lockmass, just mz of the header (real, calibrated) base peak vs mass error of the scan base peak...

[schymane]

We now have a working XCMS method with netCDF. Raw function needs exporting and documentation @ermueller Check peak quality on UJI data @schymane

[ermueller]

Function exported and with docs in fixed in 7318648

[schymane]

We can either work around via xcmsRaw and get to waters via netCDF. Closing for now

[stanstrup]

To update this. Newer versions of Proteowizard should work. It is unclear if the lockmassrefiner needs to be used. It apparently depends on the version of masslynx installed and what was used to generate the data. it is a big mess.