Error message when running CIBERSORT

[ValerieCrolley]

To Whom it may Concern,

I'm trying to run CIBERSORT as part of the immunedeconv package, and the following error message appears:

Warning message:
The path argument of write_tsv() is deprecated as of readr 1.4.0.
ℹ Please use the file argument instead.
ℹ The deprecated feature was likely used in the immunedeconv package.
Please report the issue at
https://github.com/omnideconv/immunedeconv/issues.

I'm still trying to get it to run on my data (other issues), but it doesn't look like this issue has been flagged to you so far.

[LorenzoMerotto]

Hello,

Thank you for signaling the issue. Unfortunately I fear that this problem is related to the CIBERSORT script in itself and not to the immunedeconv package, Since each user has its own version I don't think it is possible for us to fix it.
This is just a warning message so the analysis should run once you fix your data :)

[ValerieCrolley]

I've managed to solve that issue, but now I'm having the same issue as in error #124, and the solution listed is stated to use the version of CIBERSORTx from their website (https://cibersortx.stanford.edu/download.php) rather than from https://github.com/IOBR/IOBR/blob/905127ffa32aee5e1fa6c305c2e14e7c918a5967/R/CIBERSORT.R

Unfortunately, using the version of CIBERSORT.R from the website (which for me is version 1.02) has not solved my issue: instead, I get the same error as in error #79 . The solution for that error is apparently to run a newer version of CIBERSORT (v1.04), which is the one giving me the error from #124 . As you can see, this has left me going somewhat in circles. Any ideas how I might fix this issue?

(I can set up a new issue for this if you'd like, but I thought I'd add it to this one as it' still a CIBERSORT issue)

[grst]

@LorenzoMerotto, I think this one is actually ours:

immunedeconv/R/immune_deconvolution_methods.R

Line 260 in 28fce56

write_tsv(as_tibble(gene_expression_matrix, rownames = "gene_symbol"), path = tmp_mat)

[LorenzoMerotto]

@ValerieCrolley I'll try to wrap up the discussion:

• Immunedeconv is based on the latest version of the CIBERSORT script, officially labelled as v 1.04
  The script must have been obtained from the official CIBERSORT website. This version includes the possibility of running the analysis in absolute_mode, a functionality that was not available in the first version. Having an older version will lead to issues as cibersort can not run #79 (unused parameters)

• Any other version of the script will produce errors as in genes not being identical between reference and my gene expression data #124

• The warning message discussed in this issue will be fixed with the new release of immunedeconv

@grst Unfortunately there are a ton of CIBERSORT scripts available online. What if we pick the last version (the one that's working for us) and we introduce a form of control, for example with sha256? The downside of this is that even minor changes will produce some errors but I doubt that users are editing the script

[grst]

In #79 I suggested we check the version identifier in the first line of the script. sha256 might indeed be a bit too strict.

Ideally, we would get permission of the authors to include the source code into immundeconv, but in the past I wasn't very successful in getting a response from the authors for various requests.

[LorenzoMerotto]

The problem is that the problematic script has the same first line identifier as the good one

[grst]

Well, strictly speaking, it's not the first line. But I get your point.
Ok for sha256 checks, but it should be possible to have multiple allowed checksums, and there needs to be a good error message that helps the user actually figure out what the problem is.

[LorenzoMerotto]

What should the multiple checksums correspond to?
Another possibility would be to run the CIBERSORT script on some test data (es one sample) and check that the results obtained are the same. In this way we would not need to pass trough immunedeconv

[grst]

What should the multiple checksums correspond to?

different versions of the script of which we know they work. I only have one version, but there might be different ones that we become aware of

Another possibility would be to run the CIBERSORT script on some test data (es one sample) and check that the results obtained are the same. In this way we would not need to pass trough immunedeconv

Interesting idea, but maybe overkill? 🤷

[LorenzoMerotto]

I'm open to other suggestions

We could also use the sha256 and issue a warning in case of wrong script.
Something like
This script does not match the version that is recommended for immunedeconv. You can perform deconvolution but errors might be generated

[ValerieCrolley]

Hi Both,

I think the main issue is that there's no way now to find the version of CIBERSORTX.R which works with immunedeconv - the new CIBERSORT website will only give access to a Docker container (which doesn;t give access to the v1.04 CIBERSORTX.R file needed for immunedeconv. Older versions of the CIBERSORTX website will only let you donwnload v1.02 (which does not work), and attempting to download versions of CIBERSORTX from anywhere else also doesn't work. This basically still leaves me stuck, as I'm needing a version of a file that there's no way to get access to...

[jackchenry]

Have you had any updates on this issue?

I am having the same problem, I can't get access to CIBERSORT.R v1.04 since they removed it from their website. Your package doesn't work with v1.02 or v1.03 on their website or the modified script published by someone else.

[LorenzoMerotto]

Hi @jackchenry. Thank you for your interest in this topic.
Unfortunately the main idea behind immunedeconv was to create a repository for published methods with a common interface. Outside of quanTIseq, that our team developed, we are not trying to edit too much the other methods. Since CIBERSORT group is a bit strict I'm not sure about how much freedom we have to move around. Maybe @grst can help clear this up.

@jackchenry a solution would be to use another deconvolution method such as EPIC or quanTIseq. I could also have a look at the script that you are using. Please write me an email (merotto.lorenzo@gmail.com)

[grst]

Took me a while to get access, but the script that can be downloaded from the cibersort website is indeed version 1.02.

It probably wouldn't be very hard to support that version on our part (I think it's just a different function signature).

[grst]

For future reference, the CIBERSORT source code may happen to be available from various places on github, accessible via the code search: https://github.com/search?q=%22CIBERSORT+R+script+v1.04%22&type=code

One example: https://github.com/cansysbio/HGSOC_TME_Heterogeneity/blob/b697b8a6113d31196715f6ef581648237f8e9414/Scripts/3/CIBERSORT.R

[fedenichetti]

@ValerieCrolley nice to see you here as well! I had the same problem, I solved by taking the CIBERSORTx script from here https://github.com/cansysbio/HGSOC_TME_Heterogeneity/blob/b697b8a6113d31196715f6ef581648237f8e9414/Scripts/3/CIBERSORT.R .
With it and LM22.txt, deconvolute_cibersort() worked.