creating and plotting dendrograms do not see the same dendrogram
@fidelram is already working on this.
Since Dec 3, 2020.
- Dominant language
- Python
- Stars
- 2.6k
- Forks
- 779
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 27
Description
- I have checked that this issue has not already been reported.
- I have confirmed this bug exists on the latest version of scanpy.
- (optional) I have confirmed this bug exists on the master branch of scanpy.
Minimal code sample (that we can copy&paste without having any data)
np.random.seed(seed=0)
df = pd.DataFrame(np.random.randn(50,50))
fake = sc.AnnData(df)
fake.obs["groups"] = np.random.choice(a="a.b.c".split("."), size=50)
fake.obs["groups"] = fake.obs["groups"].astype("category")
sc.tl.dendrogram(fake, groupby = "groups")
sc.pl.dendrogram(fake, groupby = "groups")
using data matrix X directly
Storing dendrogram info using `.uns["dendrogram_['groups']"]`
WARNING: dendrogram data not found (using key=dendrogram_groups). Running `sc.tl.dendrogram` with default parameters. For fine tuning it is recommended to run `sc.tl.dendrogram` independently.
using data matrix X directly
Storing dendrogram info using `.uns['dendrogram_groups']`
Description
So as you can see in the reproduction, it looks like sc.tl.dendrogram(fake, groupby = "groups") stores the created dendrogram like this .uns["dendrogram_['groups']"] = dendro_data.
But it looks like sc.pl.dendrogram(fake, groupby = "groups") expects to access this dendrogram like this fake.uns['dendrogram_groups'] and when it can't find it, it creates a new dendrogram and stores it in fake.uns['dendrogram_groups'].
My guess is that there is a mismatch in the logic of the code that builds the names of dendros in sc.tl.dendrogram vs the code that builds the names in sc.pl.dendrogram. If I had more time i would try to track it down for you and maybe even send a PR. Sorry though, I dont.
Can anyone confirm that this is NOT the expected behavior?
Versions
WARNING: If you miss a compact list, please try `print_header`!
-----
anndata 0.7.5
scanpy 1.6.0
sinfo 0.3.1
-----
OpenSSL 19.1.0
PIL 8.0.1
anndata 0.7.5
annoy NA
autoreload NA
backcall 0.2.0
botocore 1.19.22
brotli NA
certifi 2020.11.08
cffi 1.14.3
colorama 0.4.3
cryptography 3.2.1
cycler 0.10.0
cython_runtime NA
dateutil 2.8.1
decorator 4.4.2
defusedxml 0.6.0
fbpca NA
fsspec 0.8.4
get_version 2.1
h5py 3.1.0
igraph 0.8.3
intervaltree NA
invoke 1.4.1
ipykernel 5.3.4
ipython_genutils 0.2.0
ipywidgets 7.5.1
jedi 0.17.2
jinja2 2.11.2
jmespath 0.10.0
joblib 0.17.0
kiwisolver 1.3.1
legacy_api_wrap 0.0.0
leidenalg 0.8.3
llvmlite 0.34.0
logzero 1.6.3
markupsafe 1.1.1
matplotlib 3.3.3
mpl_toolkits NA
natsort 7.0.1
numba 0.51.2
numexpr 2.7.1
numpy 1.19.4
packaging 20.4
pandas 1.1.4
parso 0.7.1
pendulum 2.1.2
pexpect 4.8.0
pheno_tools 0.0.1
pickleshare 0.7.5
pkg_resources NA
prompt_toolkit 3.0.8
ptyprocess 0.6.0
pycparser 2.20
pygments 2.7.2
pyparsing 2.4.7
pytz 2020.4
pytzdata NA
s3fs 0.4.2
scanorama 1.7
scanpy 1.6.0
scipy 1.5.3
seaborn 0.11.0
setuptools_scm NA
sinfo 0.3.1
six 1.15.0
sklearn 0.23.2
sortedcontainers 2.3.0
sphinxcontrib NA
statsmodels 0.12.1
storemagic NA
tables 3.6.1
texttable 1.6.3
tornado 6.1
tqdm 4.52.0
traitlets 5.0.5
typing_extensions NA
umap 0.4.6
urllib3 1.25.11
wcwidth 0.2.5
xlrd 1.2.0
yaml 5.3.1
zmq 20.0.0
-----
IPython 7.19.0
jupyter_client 6.1.7
jupyter_core 4.7.0
jupyterlab 2.2.9
notebook 6.1.5
-----
Python 3.8.6 | packaged by conda-forge | (default, Oct 7 2020, 19:08:05) [GCC 7.5.0]
Linux-4.4.0-1106-aws-x86_64-with-glibc2.10
36 logical CPU cores, x86_64
-----
Session information updated at 2020-12-02 22:22
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.