I changed my computer and re-installed the whole packages, with the latest R version (3.5.1). Since then, xcms does not work anymore, remaining stacked at the first line
Hi everybody, I\'m performing large-scale LCMS metabolomic profiling, and I\'m looking for a R script that performs quality control-based robust LOESS signal correction to correct for analytical drift within and across analytical batches (such as in Dunn, W. B., Broadhurst, D., Begley, P., Zelena, E., Francis-McIntyre, S., Anderson, N., Brown, M., Knowles, J. D., Halsall, A. et al. (2011) Procedures for large-scale metabolic profiling of serum and plasma using gas chromatography and liquid chromatography coupled to mass spectrometry. Nat Protoc 6: 1060-1083). I would be extremely pleased if somebody could help, thanks and see you in washington
Jan I just used another version of proteowizard than the one we previously utilized to generate the files I'm working on, and this time it worked well, converting the data into the centroid mode (12Mo instead of 163Mo!, with m/z with zero line witdhs). The good version of proteowizard to use would be 3.0.6994 and over. I must admit that we should have looked at the size of the files generated after proteowizard, I'll keep you posted on our continuation by the way, I finished to succesfully install chemhelper and all dependancies thanks anyway jc
mmmmhh I see. We are using proteowizard to convert the raw data into mzXML, using the peakpicking filter (I thought it convert profile data into centroided ones?), such as:
for (i in 1:length(FILES)){system (paste(converter," --mzXML --32 --filter "peakPicking true 1" --filter "polarity negative" -o Negative -v",FILES))} for (i in 1:length(FILES)){ system (paste(converter," --mzXML --32 --filter "peakPicking true 1" --filter "polarity positive" -o Positive -v",FILES))}
Thanks, I'm going yo provide you with some mzxml files I used; I also noticed that the last step crashed everything: cl <- makeCluster(detectCores()) clusterExport(cl,c("input","xraw_orbifix")) parLapply(cl,input,function(x) xraw_orbifix(x[1],x[2])) stopCluster(cl)
instead we used: for (i in 1:length(files)){ xraw_orbifix(files,outname) }
but it's slow 'zzzzz......
I just sent you a sample files containing 4 runs in mzXML format, using an ftp service; I sent you the hypertext link at stanstrup@gmail.com, hope it's correct many thanks
Hi Jan, if you do not enjoy yet of the summer sun, I can help you enjoy my orbitrap problems . So I start running orbifilter on selected mzXML files, and obtained fixed files in the mzData format which appeared nice when viewed with mzmine for instance. The problem is that it takes very very long to process the files with orbifilter (> 7 hrs per file!). The input mzxml file are roughly 163Mo, reduced to 46Mo after fixing and transforming in the mzdata format. My server is not a formula 1, but even if I'm using a more powerfull machine I would suspect that the processing time would still be undue. What is your feedback on your trials? again many thanks jc
thanks jan, just to be sure of how it works: first I run obifilter on the mzXML files, then I process the orbifilter corrected files with xcms the usual way. Is that right? Sorry to be so basic thanks jc
Hi Jan, sorry but I'm unable to install the packages (metshot and chemhelper), althouth I started from the beginning (https://github.com/stanstrup/chemhelper). I'm using R 3.1.2. There is something wrong with Rcpp, althought I tried to installed it manually from the a dowloaded zip file. Is there something I did wrong?thanks, jc
Many thanks, it will help. I already tested matchedFilter and it worked pretty well, with a good peak intensity extraction, although peak duplication is still the same, but I will try to fix this with your script. I will post the results soon. jc
Hi Jan, yes I checked that the peak is detected in all samples. In fact I spiked plasma samples with 33 different standards to see whether xcms correctly extracted the corresponding ions. The peak picking step worked quite well since it detected 32 out of 33. But then the problem occured when I compared the extracted peak ions from xcalibur and the reported peak intensities area in the report table which is often eratic and does not correspond to the xcalibur reality: half of the spiked molecules had a stable peak area from one sample to the others in the xcms report table, and the other half is just unreliable, whereas the EIC xcms pictures comparatively indicate a good extraction (see my previous message above for one example). What I shall add is that about half of the features in my report table matrix are duplicated, sometimes 6 times, which apperared to me unusual if I compared to what we used to obtain with our QTOF (almost no peak duplication). I suspect a problem during the integration, although I also compared with the peak intensity (using the maxo argument) which did not improved our results either. Hereafter is the last script I used:
Hi there, I'm facing an unresolved problem; we are using a qexactive + in dual mode (+/-) @30000 mass resolution. After conversion into mzXML, we discovered that some features intensity are eratically reported in the diffreport table .tsv, whereas both the EIC caption and also the raw EIC are excellent. See figures below as an illustration I would really appreciate help since we tested many different scripts without any subtantial improvements thank you
raw xcalibur EIC [attachment=2:8i42r00r]xcalibur raw EIC.JPG[/attachment:8i42r00r]
I'm using a q-exactive plus connected to a uplc through an ESI source. After using xcms, the differport matrix contains a lot (too much) of variables with zero intensities, mainly in the samples, less so in the QC's. Here is the script I use
. So I start running orbifilter on selected mzXML files, and obtained fixed files in the mzData format which appeared nice when viewed with mzmine for instance. The problem is that it takes very very long to process the files with orbifilter (> 7 hrs per file!). The input mzxml file are roughly 163Mo, reduced to 46Mo after fixing and transforming in the mzdata format. My server is not a formula 1, but even if I'm using a more powerfull machine I would suspect that the processing time would still be undue.