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.
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.
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.
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:
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.
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.
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.
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.