Last post by sebastian.boecker -
Our latest version SIRIUS 3.5 comes with several improvements. Download it from https://bio.informatik.uni-jena.de/software/sirius/.
We have a new overview tab for CSI:FingerID hits, which displays results of structure search for multiple molecular formulas. You can examine the predicted fingerprint of each compound (and molecular formula) independently of any database. We now offer the possibility to create and search in custom structure databases (suspect screening). Besides, we have a new Bayesian networks scoring function for CSI:FingerID which considers dependencies between different molecular properties. This and much more.
Note in passing: The CSI:FingerID web service has just passed the mark of processing data from 500,000 query compounds -- congratulations to CSI:FingerID, and thank you for your interest in our tools! (Be reminded that CSI:FingerID should be accessed via the SIRIUS application, not via the web page.)
If you have comments, ideas for improvements, feature requests etc, please answer to this post.
Last post by cbroeckl -
I currently am using a custom script for feature grouping which simply assumes that if retention times overlap and mass windows (plus a given ppm error) overlap, the represent the same compound. After each iteration, I apply a retention time adjustment as well. The tried-and-true XCMS functions are just much more well used and validated than my internal tools, so I was hoping there would be a way to utilize them that I had missed. I will look at the package you are developing - it does look interesting! Are you aware of the skyline/panorama tool sets? I know they are also working on vendor neutral QC monitoring. Interested to see how yours compares.
Last post by edmandsw -
You might be interested in an R package simExTargId I have been developing for real-time metabolomic experiment monitoring (with email notification) and MS/MS target identification. It makes use of xcms and CAMERA and sequentially concatenates xcmsSet objects as data is collected. It is still in development and has a few rough edges but it has been used regularly in our lab (it currently works for Agilent .d and Thermo .raw/.RAW data files).
Last post by edmandsw -
As far as I'm aware this isn't possible. The retention time correction using the obiwarp method for example has to be reassessed with a new centre sample.
See the help file
?retcor.obiwarpSo the retention time deviation for each file has to be re-calculated.
Additionally for grouping the minfrac and minsamp arguments will be affected by additional samples in each group as you concatenate.
It shouldn't be (computationally speaking) too much of a big deal to re-do the retention time correction and grouping each time you peak-pick an additional file(s). The most time-consuming part is definitely the xcmsSet function.
Fantastic, thanks for getting back to me so quickly. I read Martin Morgan's explanation also and it is now clear to me (although probably quite superficially) how BiocParallel is working.
Got now an explanation from Martin Morgan (https://support.bioconductor.org/p/96856/). Basically, you could use the progressbar, but you have to increase the number of tasks, so that the progress bar will be updated more frequently. Note however that a) the number of tasks should not be larger than the number of files you're processing and b) there might be a performance decrease with too many tasks.
So, in your case you could:
Now, for your 400 file experiment you might want to increase the number of tasks to get more frequent callbacks and updates of the progress bar.
Hope this helps.
with the switch to BiocParallel the progress information are no longer printed immediately - this seems to have to do with the way BiocParallel handles the sub-processes. I know that is annoying, but there is not much we can do within xcms.
I'll get in contact with the BiocParallel developers to check if we can fix that.
It is probably something minor/trivial but since updating to xcms3 (v1.50.1) (and the deprecation of the nSlaves argument change to BPPARAM of BiocParallel) I am no longer receiving lovely reassuring progress messages printed to the R console. The strange thing is in previous versions of xcms the progress messages would appear soon after initiation of the xcmsSet function regardless of the number of mzXML files in the directory.
I have tried the progressBar argument of the SnowParam function but it was stuck at 0% for over an hour.
With the ~200 mzXML files I am currently peak-picking I did not receive any console message for over two hours:
Then all of a sudden there were messages previously typical of a single-threaded process:
However I was able to check the multi-threaded process was running by monitoring the CPU usage.
When the dataset size is small as is the case for faahKO, the progress messages appear much sooner. Here is a reproducible but perhaps not very useful example:
Is is necessary to DIY/Jerry-rig your own progressCallBack function now?
cdffiles <- list.files(cdfpath, recursive = TRUE)Although this didn't work as expected either.
Many thanks in advance,
Early-career Members Network (EMN) / Webinar: Machine learning powered metabolomic network analysis [ONLINE NOW]Last post by Jan Stanstrup -
The last webinar "Machine learning powered metabolomic network analysis" by Dr. Dmitry Grapov is now online.