purityX cannot read XCMS output file

[Hrodwin]

Hi,
I am currently working with a XCMS workflow with Galaxy France and it seems to be a compatibility problem with the XCMS output RData. The RData provided by the final step of XCMS (groupChromPeaks) is not read by purityX:

Error in print(xset@filepaths) : 
  no slot of name "filepaths" for this object of class "XCMSnExp"
Execution halted

The problem does not come from usegalaxy.fr, it seems to come from the purityX wrapper. Is that du to the fact that purityX is made for FIA-MS/MS data while purityA is conceived for LC-MS/MS? I am in dire need to use purityX with LC-MS/MS.
Best regards,
Quentin Ruin

[Tomnl]

Hi Quentin,

Thanks for flagging this.

I think this is due to the current tool purityX and underlying function here not being compatible with current the XCMS object structure (i.e. XCMS >=3.* - where XCMSnExp was implemented)

I should be possible to fix by adding a conversion within the wrapper (that is done in some of the other tools). Will take a bit of time to update the Galaxy tools though as they need to update to the latest version of msPurity as well.

Do you have a Galaxy history on usegalaxy.fr that I could check please? (I might be able to sort a quick fix in the meantime)

Myself and @RJMW will look into updating the wrappers.

Note

• All other functions within msPurity can now handle either the original xcmsSet object format or the XCMSnExp object format. This tool and underlying R function (purityX) has been left behind a bit because I didn't think there was much interest in the purityX approach compared to the other tools.

[Hrodwin]

Hi again,
I have a demo Galaxy history where I encountered that problem:
https://workflow4metabolomics.usegalaxy.fr/u/quentin_ruin/h/purityxtest
Thanks for your explanations and your concern!
Let me know if there is any problem with the history.

[Hrodwin]

Hi again (again),
After a few investigation, I might have some clue:
The old XCMSnExp objects can be transtyped into a modern XCMSset object with a function designed by Guildas le Corguille that has been implemented into other tools:

getxcmsSetObject <- function(xobject) {
  # XCMS 1.x
  if (class(xobject) == "xcmsSet")
    return(xobject)
  # XCMS 3.x
  if (class(xobject) == "XCMSnExp") {
    # Get the legacy xcmsSet object
    suppressWarnings(xset <- as(xobject, "xcmsSet"))
    if (!is.null(xset@phenoData$sample_group))
      sampclass(xset) <- xset@phenoData$sample_group
    else
      sampclass(xset) <- "."
    return(xset)
  }
}

Thus by downloading my latest XCMS RData and using this function, I was able to modify the xdata XCMSExp object of the RData into a XCMSset object xset as mentioned above:

load(path) # loading RData files downloaded from Galaxy XCMS
xset <- getxcmsSetObject(xdata)
rm(xdata)
save(list=ls(),file = out_path)

Then, I loaded the output file (from out_path) into Galaxy and purityX accepted it (despite a memory limitation of the tool, which has been reported to the Galaxy Team). It may just be necessary to encapsulate this function in the wrapper, applying it if the object contained in the RData is an XCMSnExp named 'xdata', and renaming it 'xset' by transtyping it to XCMSset.
Hope this is clear enough and might help.

[Tomnl]

Thank you for doing this!

Good that it is running if you do the conversion "manually". Hopefully it gives the desired result when the memory limit is changed. Let me know if you see another issue please.

Yes you are correct - the wrapper needs to updated to add that functionality. It might make sense for this to occur as part of a version bump to the latest bioconda version of msPurity.

[Hrodwin]

Thanks a lot!
One more thing I'm afraid: the memory is now sufficient and the files are compatible after manually reformatting, however the console output containing the desired purity table is not written into the output .tsv file of the Galaxy tool:

peakID meanPurity medianPurity   sdPurity  sdePurity  cvPurity pknmPurity

1      1  0.7668987    0.7974175 0.11689277 0.02835066 15.242270       3.00
2      2  0.1617367    0.1486087 0.03161732 0.01195023 19.548638       8.00
3      3  0.9277477    0.9380126 0.08004239 0.03025318  8.627603       2.00
4      4  0.3859825    0.3597241 0.10925345 0.03153875 28.305287       9.75
5      5  0.1835078    0.1699386 0.04193459 0.01482612 22.851672       8.00
6      6  1.0000000    1.0000000 0.00000000 0.00000000  0.000000       1.00
          i       mz
1  46642.23 50.51572
2  11390.24 51.01612
3  51165.44 51.05732
4  21644.78 51.49571
5  13937.01 51.51464
6 271156.59 53.01843

Sorry for adding yet more work on the stack!

[Tomnl]

Ah sorry about this.

I see the output names do not match the one in the script. i.e. purityX.tsv should actually be purityX_output.tsv (similar problem for the RData)

https://github.com/computational-metabolomics/mspurity-galaxy/blob/master/tools/msPurity/purityX.xml#L133-L136
https://github.com/computational-metabolomics/mspurity-galaxy/blob/master/tools/msPurity/purityX.R#L178

I must have changed at some point and then the test result got deleted so didn't notice the output was missing.

OK - so two issues to fix here

1. Add xcms conversion snippet to wrapper
2. Ensure output files are being taken correctly

Will hopefully have time next week to fix this

[Tomnl]

@Hrodwin - I have updated the Galaxy wrapper for this fix see #54

Should be available from the Galaxy toolshed to use now.

(I am working on a version bump to the latest bioconda version as well - if you would prefer to wait for that)

[Tomnl]

The Galaxy wrapper "version bump" to v1.28.0 of msPurity is also available on the toolshed as well

[Hrodwin]

I have tried my workflow again with the new version (v1.28.0-galaxy0) and I'm now able to get outputs by prodiving reformatted RData files. However, with current XCMS outputs I'm still stuck with the error Error in get(ls()[ls() == xset_name]) : invalid first argument. I suspect this comes from the fact that the loadRData() function still returns return(get(ls()[ls() == xset_name])) instead of return(get(ls()[ls() %in% xset_name]))

Then, the function is still called using loadRData(opt$xset_path, opt$rdata_name) that does not consider the new XCMS case where data is store in a feature called "xdata" instead of "xset" or "xa", leading to something like loadRData(opt$xset_path, c("xset", "xdata", "xa"))?

[Tomnl]

Ah OK. That should be a straight forward fix then.

I can fix whilst looking into the other issue you posted

[Tomnl]

@Hrodwin - this should be fixed in v1.28.0+galaxy1 🤞

[Hrodwin]

All good! Tested and functional 👍

[Tomnl]

Great! Thanks for letting me know. I will close the issue now