Closed Captain-Pam closed 2 years ago
Hi @Captain-Pam, thanks for flagging this. Working on a fix now.
Ok, so it seems there's a couple of things happening:
I believe this is a bug I recently introduced into EWCE::standardise_ctd
. I'll fix this and make a push.
In the meantime, I'll add an extra safety feature to MAGMA.Celltyping
that ensures the "specificity_quantiles" matrices are computed when they're missing the from the CTD.
Could you try updating to MAGMA.Celltyping
v2.0.6 and try again?
ctd_species
It looks like you're specifying ctd_species = "mouse"
when in fact the genes are already in human format (for "ctd_AIBS"). Since you have standardise=TRUE
(the default), the CTD gets passed to EWCE::standardise_ctd
and tries to convert "mouse" genes to human genes. Thus, there's no genes left in the matrix and you get an error.
Specifying the correct species seems to work:
ctd <- MAGMA.Celltyping::get_ctd("ctd_AIBS")
ctd <- EWCE::standardise_ctd(ctd, input_species = "human", force_standardise = TRUE)
And using the full example:
ctd <- MAGMA.Celltyping::get_ctd("ctd_AIBS")
magma_dirs <- MAGMA.Celltyping::import_magma_files()
MAGMA_results <- MAGMA.Celltyping::celltype_associations_pipeline(
magma_dirs = magma_dirs,
ctd = ctd,
ctd_species = "human",
ctd_name = "ctd_AIBS_test",
run_linear = TRUE,
run_top10 = TRUE,
run_conditional=TRUE)
In the latest CTD files supplied in get_ctd
, I've already converted them all into 1:1 human orthologs so the user doesn't have to do that extra step (though note that ewceData::ctd()
still provides the CTD as mouse genes).
That said, if you're ever unsure which species a CTD is in, you can use this nifty function i added to orthogene
, which guesses the correct species pretty consistently.
res <- orthogene::infer_species(gene_df = ctd[[1]]$mean_exp)
See #117 for info on how I implemented this within MAGMA.Celltyping
.
Hey, Great ! Thank you for always improving this tool! I'm going to try out the upgraded version recently. 1)I found that some datasets (ctd) may not download and where can I download the data that has been collated? 2) Is MAGMA.Celltyping the same analysis method as MAGMA Gene Property Analysis on FUMA platform? 3) Why transfer cell type data from mice to humans? Is it because mice and humans have different genetic nomenclature?
I hope to look forward to hearing from you
------------------ 原始邮件 ------------------ 发件人: "neurogenomics/MAGMA_Celltyping" @.>; 发送时间: 2022年7月30日(星期六) 凌晨4:44 @.>; @.**@.>; 主题: Re: [neurogenomics/MAGMA_Celltyping] Error running after using new version of .rds files (Issue #107)
Ok, so it seems there's a couple of things happening:
I believe this is a bug I recently introduced into EWCE::standardise_ctd. I'll fix this and make a push.
In the meantime, I'll add an extra safety feature to MAGMA.Celltyping that ensures the "specificity_quantiles" matrices are computed when they're missing the from the CTD.
Could you try updating to MAGMA.Celltyping v2.0.6 and try again?
It looks like you're specifying ctd_species = "mouse" when in fact the genes are already in human format (for "ctd_AIBS"). Since you have standardise=TRUE (the default), the CTD gets passed to EWCE::standardise_ctd and tries to convert "mouse" genes to human genes. Thus, there's no genes left in the matrix and you get the `` error.
Specifying the correct species seems to work: ctd <- MAGMA.Celltyping::get_ctd("ctd_AIBS") ctd <- EWCE::standardise_ctd(ctd, input_species = "human", force_standardise = TRUE)
And using the full example: ctd <- MAGMA.Celltyping::get_ctd("ctd_AIBS") magma_dirs <- MAGMA.Celltyping::import_magma_files() MAGMA_results <- MAGMA.Celltyping::celltype_associations_pipeline( magma_dirs = magma_dirs, ctd = ctd, ctd_species = "human", ctd_name = "ctd_AIBS_test", run_linear = TRUE, run_top10 = TRUE, run_conditional=TRUE)
In the latest CTD files supplied in get_ctd, I've already converted them all into 1:1 human orthologs so the user doesn't have to do that extra step. That said, if you're ever unsure which species a CTD is in, you can use this nifty function i added to orthogene, which guesses the correct species pretty consistently. res <- orthogene::infer_species(gene_df = ctd[[1]]$mean_exp)
Also note that ewceData::ctd() still provides the CTD as mouse genes.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
1)I found that some datasets (ctd) may not download and where can I download the data that has been collated?
Which ctd were you looking for specifically? It looks like I did indeed miss uploading several, so I just added these now and they should be available via get_ctd
. Only one I'm still working on is "ctd_TabulaMurisSenis", which I've added a note to in the docs and will try to upload soon.
2) Is MAGMA.Celltyping the same analysis method as MAGMA Gene Property Analysis on FUMA platform?
Actually no, they are totally independent pipelines that just happen to use a lot of the same underlying software (eg MAGMA).
3) Why transfer cell type data from mice to humans? Is it because mice and humans have different genetic nomenclature?
Currently all comprehensive single-cell atlases for human are single-nucleus (not single-cell), meaning a lot of the RNA transcripts are lost, making the data lower quality and more difficult to distinguish cell subtypes from. Mouse atlases like Zeisel2018 or TabulaMuris, by contrast, are single-cell and therefore higher quality (despite being different species). There's definitely tradeoffs, but you can read more in the original paper: https://www.nature.com/articles/s41588-018-0129-5
1:1 gene orthologs are converted between species using the package orthogene
(also developed by our lab), which leaves ~16k comparable genes between mouse and human.
1. Bug description
I noticed the upgrade of the R package and downloaded the rds file, which has a change in file type (dgCMatrix) compared to the rda file.
(A clear and concise description of what the bug is.) Running celltype_associations_pipeline gives the error "Error in apply(ctd_1lvl[[.matrix_name]], 2, function(x) { : dim(X) must have a positive length". The problem may lie in the check_quantiles.R function
Console output
Expected behaviour
(A clear and concise description of what you expected to happen.)
2. Reproducible example
Code
(Please add the steps to reproduce the bug here. See here for an intro to making a reproducible example (i.e. reprex) and why they're important! This will help us to help you much faster.)
Data
(If possible, upload a small sample of your data so that we can reproduce the bug on our end. If that's not possible, please at least include a screenshot of your data and other relevant details.)
3. Session info
(Add output of the R function
utils::sessionInfo()
below. This helps us assess version/OS conflicts which could be causing bugs.)