Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Labels cycling cells as doublets #9

Open
mzhibo opened this issue Sep 22, 2021 · 2 comments
Open

Labels cycling cells as doublets #9

mzhibo opened this issue Sep 22, 2021 · 2 comments

Comments

@mzhibo
Copy link

mzhibo commented Sep 22, 2021

Hi,
Thank you for developing this great tool!
I tried AMULET on two of 10x Multiome datasets and found two issues:

  1. it labeled most of the Mki67+ cycling cells as multiples, which makes sense based on the design of this tool. This might be an issue if the sample contains considerable number of cycling cells. I would suggest doing more performance test using datasets with cells in cycling phase.
  2. the doublets labeling does not seem to be consistent with the doublets identified from the RNA assay. Scrublet prediction is consistent with the shared marker gene expression and higher number of nUMI per cell. Since the 10x multiome kit measures both atac and RNA from the same cell, I don't know how to interpret this difference.
    I have attached a plot of the multiples comparison
    Do you have any suggestions how to examine the accuracy of the AMULET predictions? Or do you have recommendations on how to fine-tune the prediction?
    I am thinking excluding the cluster of cells that is known to be in cycling phase based on the RNA assay.
    AMULET_multiplets(snATAC)_vs_Scrublet_doublets(snRNA)
    AMULET_multiplets_vs_CyclingCells
    ?
@ajt986
Copy link
Member

ajt986 commented Sep 22, 2021

Thank you for sharing these analyses! It's actually encouraging to see that AMULET does well at detecting the proliferating cells. It is not surprising to see that the majority of these cells are detected as multiplets when using the default parameters since these cells are expected to have >2 reads overlapping.

For calling multiplets with these cells, AMULET should be run using --expectedoverlap 4 (I would grab the new shell script I just updated, or run the steps separately to ensure this parameter is used in both steps of the algorithm). Here, since we expect 2 copies of the maternal and paternal chromosomes each (i.e., 4 chromosomes), multiplets will be the cells/nuclei that systematically have more than 4 reads overlapping. In this case, you can use 2 different csv files to subset the cells into proliferating and non-proliferating cells. For example, the barcodes in the Mki67 cluster would be proliferating and the rest would be non-proliferating. Run the non-proliferating cells with --expectedoverlap 2 (default) and the proliferating with --expectedoverlap 4. There may not be as many multiplets detected for the proliferating cell case due to AMULET requiring sufficient read depth/sequencing saturation.

For comparison with RNA assay multiplets, one of the differences is that AMULET also detects homotypic multiplets (i.e., multiplets from the same cell type) and these types of multiplets will not be captured by methods like scrublet that compare cells with simulated doublets. There should still be some overlap between the two methods though. The UMAPs are hard to compare since some doublet cells are hiding under singlets in the UMAP. How do the UMIs look for AMULET multiplets? I would also inspect clusters that have a majority of multiplets, especially for simulation based methods just to ensure that a cell type with a similar expression profile to other cell types is not being misidentified as multiplet clusters. Similarly, for AMULET, if there are cells that break the assumption that the expected number of chromosomes in the cell is 2, further analyses will need to be done to identify those cells first. If both of these check out, what would the multiplet removal % look like if taking the union of the two methods?

@mzhibo
Copy link
Author

mzhibo commented Sep 23, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants