Skip to main content

Messages

This section allows you to view all Messages made by this member. Note that you can only see Messages made in areas you currently have access to.

Messages - Jan Stanstrup

256
XCMS / Re: error with "scanrange" variable of xcmsSet
My guess:

When you don't set the "method" in the xcmsSet the default method "matchedFilter" is used. The MatchedFilter method does not have a scanrange parameter.
You need to set method='centWave'. That is most often the superior method anyway.
257
XCMS / Re: Lockmass gap correction
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
258
XCMS / Re: Lockmass gap correction
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
261
XCMS / Re: memory error during fillpeak step
I think I found an unfortunate behavior that is causing fillpeaks to need an excessive amount of memory.

The problem seems to be here:
Code: [Select]
   argList <- apply(ft,1,function(x) list(file=x["file"],id=as.numeric(x["id"]),
                                          params=list(method="chrom",
                                            gvals=gvals,
                                            prof=prof,
                                            dataCorrection=object@dataCorrection,
                                            polarity=object@polarity,
                                            rtcor=object@rt$corrected[[as.numeric(x["id"])]],
                                            peakrange=peakrange)
                                          ))
gvals is repeated for each sample as far as I can see.

This is the object I used for testing (we have a bigger set where it runs out of memory):
Code: [Select]
An "xcmsSet" object with 456 samples

Time range: 0.6-361 seconds (0-6 minutes)
Mass range: 60.0429-999.9048 m/z
Peaks: 1050355 (about 2303 per sample)
Peak Groups: 4232
Sample classes: data_converted_pos

Profile settings: method = bin
                  step = 0.005

Memory usage: 266 MB

So gvals is 4232 x 456  and takes 7.6 MB. When it is repeated for each sample that eats 3.5GB alone in this case and would increase to the power of 2 when you increase the number of samples.
If I understand correctly gvals is the same in each index of the list. So can the structure of argList be changed to only have one copy?


edit: not to mention that the memory requirement is multiplied by the number of cores you want to use for gapfilling  :shock:
264
Compound identification / Re: Rdisop: Isotope patterns of labeled compounds
initializeCHNOPSMgKCaFe() was just to show you how to build the list of elements you should use with initializeElements.


Quote
new=list()

new[[1]]=initializeCHNOPSMgKCaFe()[[1]]
new[[1]]$mass=13
new[[1]]$isotope$mass=new[[1]]$isotope$mass[2:3]
new[[1]]$isotope$abundance=new[[1]]$isotope$abundance[1:2]


new[[2]]=initializeCHNOPSMgKCaFe()[[2]]


new[[3]]=initializeCHNOPSMgKCaFe()[[4]]


getMass(getMolecule( "C6H12O6" ,elements=new))


EDIT: dang... too slow... and I guess initializeElements is not needed if you use my example.
266
XCMS / Re: Lockmass gap correction
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.
268
Other / Re: Convert Orbitrap ".RAW" data files to other type of file
Hi Thaer ;)

netCDF is pretty much obsolete. mzXML, mzData or mzML are better supported now.

msconvert from Proteowizard (proteowizard.sourceforge.net) is the newest and only program that is updated so that is your best bet. Get the 32 bit version if you want a GUI.


Cheers,
Jan.
269
XCMS / Re: Choose the best parameters to analyse UPLC-qTof data
I haven't tried the delete workaround myself. I have another workaround that I will release at some point.

As you can see yourself it seems to be working. but you need to check something: if the masses are the same. I don't know if it uses the lockmass function (it is those you delete) for the calibration. If you can verify that the masses are identical in the file you created then that workaround works too.
270
XCMS / Re: Choose the best parameters to analyse UPLC-qTof data
Quote
So, are you saying that I can't use the msconvert or massWolf corvesion with lock mass?
Yes. Masswolf as I said mixes the normal scans with the lockmass scans. and msconvert doesn't calibrate the data. Databridge in theory can convert all in one batch. However they are so eager to inform you that you have several traces/functions so they make a popup for each files. And it seems to stop randomly... never the less it is the only consistently working way available at the moment.

Understanding the quality of the data only through some calculations with XCMS is over-complicating things heavily. Does your peaks tail? Do they have the usual intensity achieved on your setup? Is the lockmass intensity at at reasonable level?. Are the retention times as they should be? Is the baseline at a reasonable level? How is the mass accuracy? Some of these can definitely be assessed by some calculations. But it is way faster to just look at the chromatogram first and see if everything looks normal. You can't spot things you are not looking specifically for with a computer. Luckily a human can.

For BPI plot see:
?plotChrom