Lockmass gap correction

Topic: Lockmass gap correction (Read 13755 times) previous topic - next topic

Lockmass gap correction

January 08, 2013, 04:28:06 AM

Hi,
I have a question regarding the correction of the gaps caused by lockmass scans.
I´m working with waters Masslynx files that I've converted to netCDF format using the Databridge software from Waters.
When setting “ lockMassFreq=TRUE” in xcmsSet I got an error message for some of the files of my dataset. Going back to those chromatograms I realised there was a problem during lockmass acquisition: it seems that occasionally the sampling baffle failed to rotate to the correct sample/reference position so that a reference scan was taken when a sample scan should have been taken (or vice versa). As a result, the lockmass scans do not adjust to a fix frequency in those chromatograms.
I wonder if there is any way of correcting those gaps other than using the lockmass frequency (for example using the lockmass data file?)
Thanks,

Re: Lockmass gap correction

Reply #1 – January 08, 2013, 04:54:15 AM

If you convert using Databridge the lockmass scans should already be removed...?

You can find another workaround here: http://metabolomics-forum.com/viewtopic ... =352#p1135

Re: Lockmass gap correction

Reply #2 – January 08, 2013, 06:18:31 AM

Ok, so I may be mistaken then on what databridge conversion does? I Know the lockmass scans are not included in my datafile after databridge conversion to netCDF, but I assumed that the gaps would still be there... What I wanted to do was to use the gap filling function developed by P. Benton and see if it results in an improvement in peak picking / peak quantitation.

Re: Lockmass gap correction

Reply #3 – January 08, 2013, 06:40:02 AM

I'm sorry you are right. Databridge doesn't do the fill-in that Paul Benton's function does. I never got Paul's function to work with my data since it relies on the interscan times. With my data it is not consistently different enough for lockmass scans.
I have another approach I will PM you that does do the fill-in but uses a less elegant way to find the lockmass scans.

Re: Lockmass gap correction

Reply #4 – February 02, 2013, 11:23:40 AM

Hey guys,

just saw this thread. For some reason the forum has stopped sending me alerts when new messages are posted.

Anyways, I just wanted to let you know that there is a new version of the lock mass gap correction that I put in the last version of xcms, ie its in the current stable release. With this version xcms will read the lock mass function files to get the scan times directly from the files. This is a good alternative if for some reason the scans weren't regular or something odd happened. To run it you need to have your lock mass function CDF files in the same folder as your analysis files. The naming schema that I found to happen was that the lock mass files were always called myFileName02.CDF. If this is different on your conversion then you need to change the 0x.CDF to 02.CDF. Then use the lockMassFreq=TRUE and everything should be good. The peak detection will only happen on the 01.CDF files and keep the 02.CDF (lock mass files) for correction.

I hope that this is going to clean up a lot of the issues with the lock mass correction. There's always a lot that happens with the lock mass correction, we always find interesting things happening with our data.

Let me know how you get on.

Paul

EDIT: Asun - In the paper for the lock mass gap correction we looked at the integrated intensity of the peaks but not really peak picking detection. We did find that most of the same peaks were detected along with some peaks that were not detected previously. This was using the mzData format. I would be very interested to know what results you get and if it makes a difference to the peak detection quality.

Re: Lockmass gap correction

Reply #5 – February 07, 2013, 05:19:12 AM

Hi Paul,

Sorry for my late response. I was already using the last xcms version (1.34) setting the lockMassFreq=TRUE, but for some reason it does not work with my files. I was getting the same warning message whether I had the xx02.CDF files in the folder or not.

Warning in AutoLockMass(lcraw) :
Lock mass frequency wasn't detected correctly

Asun

Re: Lockmass gap correction

Reply #6 – February 20, 2013, 06:18:25 AM

Asun,

I guess I should just check the forum daily.

Apologies for the very late response.

I would be very interested in having a look at a file and the corresponding 02.CDF file if you don't mind. It would help me debug. Otherwise I can send you some code to run.

Paul

Re: Lockmass gap correction

Reply #7 – July 11, 2013, 05:46:16 AM

Hello everybody,

I encountered the same issue as you Asun, and tried to fix it according to Paul's answer, but I still get the following error message trying to apply the lockMassFreq correction...

Warning in AutoLockMass(xRaw) :
Lock mass frequency wasn't detected correctly

Any idea to fix it ?

Thanks for your help

Raphaël

Re: Lockmass gap correction

Reply #8 – July 11, 2013, 06:15:30 AM

I cannot help you on Paul's function, but I made a script using a different approach (see supplementary here: http://link.springer.com/article/10.100 ... 013-6954-6 and the script can be found here: http://msbi.ipb-halle.de/msbi/BeyondProfiling).
With this script you convert the waters raw files with masswolf, then fix the lockmass scans by replacing with the previous scan as per Paul's method. Then a fixed set of mzData files are writing and you use them without lockMassFreq.

Jan

Re: Lockmass gap correction

Reply #9 – July 12, 2013, 10:00:30 AM

Thank you for your answer Jan ! I'll try it and will give you a feedback.

Raphael

Re: Lockmass gap correction

Reply #10 – August 07, 2013, 08:32:00 AM

Hello Jan,

I tried your script and it worked. Thanks a lot for you help !

Best,

Raphaël

Lockmass gap correction : MSE data conversion

Reply #11 – September 02, 2013, 09:20:37 AM

Hello Jan,

The script worked very well with MS1 data, but I tried it with MSE data (also from a Synapt Waters) and here is the error statement :

First function is not of type MS, is this MS^E data? Continuing anyway.
Second function is not of type MS, is this MS^E data? Continuing anyway.
(got computer name: C-TAC)
Calculating sha1-sum of mzXML
--done (mzXML sha1):8160c2c3905aba20aeb020ca843c7e61bd71c8df

Only one file is created and then the script stop at the second one, probably the MSE one ?

Thanks a lot for your help.
Best,
Raphaël

Re: Lockmass gap correction

Reply #12 – September 02, 2013, 09:58:12 AM

Hi. The output you copied is from masswolf as far as I can see. Does R/the script give some error?. The script runs masswolf twice with different settings when mse is detected to get the mse, then write out two mzData files.

When you say only one file is created is that one mzXML or one mzData?
What do you mean the script stops? Hangs forever? or some error?

In the script I search the raw data for a specific string to detect an MSE file. So if they changed that string in the raw data (my machine is older, I know the new files look slightly different) it won't detect it is MSE.
The easiest way to figure out what is going one would be to send me an example file.

Best,
Jan

Re: Lockmass gap correction

Reply #13 – September 03, 2013, 01:27:16 AM

Hello Jan,

Thanks for your fast answer.
You're right. The screenshot is from masswolf. Here is the one from R :

Error in writeLines(unlist(log_convert_warning), fileConn) :
invalid 'text' argument
Then the script stops : close(fileConn)
The only created file is a mzXML one.

How would you like me to send you an exemple file ? (approximately 80 Mo)
If we cannot read the MSE file, how could I edit the script in order to read only the MS1 trace and the lockmass trace ?

Best,

Raphaël

Re: Lockmass gap correction

Reply #14 – September 03, 2013, 03:27:02 AM

That error is the symptom of some problem. it doesn't really give me any clue what is wrong.
Can you zip it and share it on dropbox or similar?

Jan.