When using umap with init_pos=paga, got strange result

When i use umap with the parameter init_pos=‘paga’, I got a strange result.

sc.pl.umap(adata,color='louvain')

no error

Versions:

scanpy==1.4.4 anndata==0.6.22.post1 umap==0.3.9 numpy==1.17.3 scipy==1.3.1 pandas==0.25.0 scikit-learn==0.21.2 statsmodels==0.10.1 python-igraph==0.7.1 louvain==0.6.1

[ivirshup]

Thanks for posting that code, it’s very helpful for figuring this stuff out.

I tried running that code on one of our example datasets, and wasn’t able to reproduce your results (however, one of the variables pos_coord wasn’t defined):

import scanpy as sc
import numpy as np
import pandas as pd
import matplotlib.pyplot as plt
import seaborn as sns
import anndata
import matplotlib as mpl
import scipy

sc.logging.print_versions()
# scanpy==1.4.4.post1 anndata==0.6.22.post1 umap==0.3.10 numpy==1.17.3 scipy==1.3.1 
# pandas==0.25.3 scikit-learn==0.21.3 statsmodels==0.10.1 python-igraph==0.7.1 louvain==0.6.1

sp = sc.datasets.pbmc3k()
sc.pp.normalize_total(sp,target_sum=1e6,key_added='norm_factor')
sc.pp.log1p(sp)
sp.raw=sp
sc.pp.highly_variable_genes(sp, n_top_genes=2000)
sc.pl.highly_variable_genes(sp)
sp = sp[:, sp.var['highly_variable']]
sc.pp.scale(sp, max_value=10)
sc.tl.pca(sp, svd_solver='arpack')
sc.pl.pca_variance_ratio(sp, log=True)
sc.pp.neighbors(sp, n_neighbors=10, n_pcs=30)
sc.tl.diffmap(sp)
sc.pp.neighbors(sp, n_neighbors=20, use_rep='X_diffmap')
sc.tl.louvain(sp,resolution=1)
sc.tl.paga(sp)
_, axs = plt.subplots(ncols=1, figsize=(24, 10), gridspec_kw={'wspace': 0.05, 'left': 0.12})
# Modified this call because pos_coord wasn't defined:
# sc.pl.paga(sp,color='louvain',layout='fa',pos=pos_coord,threshold=0.2,ax=axs)  
sc.pl.paga(sp,color='louvain',layout='fa',threshold=0.2,ax=axs)
from scanpy.tools._utils import get_init_pos_from_paga as init
sc.tl.umap(sp,init_pos=init(sp))
sc.pl.umap(sp,color='louvain')

The final plot looks normal enough:

Right now, there are a lot of variables in this script. There’s a few things to try:

• Check if pos_coord is causing the issue
• I noticed your scanpy version wasn’t the same as the current release, could you update that?
• If you run the script with the dataset I used, does your plot still have those strange rectangular layouts?
• Can you cut down the number of commands you used, and potentially even the amount of data? This will limit the number of variables that could be causing the behavior.

[dhtc]

@ivirshup Yeah, it was the same data as the privious plot. I tried calling sc.tl.umap(sp, init_pos=“paga”) but meet an error. I just use the get_init_pos_from_paga function to solve this error as mention in #769 .Thanks!

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Invalid use of type(CPUDispatcher(<function rdist at 0x7f90e19f58c8>)) with parameters (array(float64, 1d, C), array(float64, 1d, C))
Known signatures:
 * (array(float32, 1d, A), array(float32, 1d, A)) -> float32
 * parameterized
[1] During: resolving callee type: type(CPUDispatcher(<function rdist at 0x7f90e19f58c8>))
[2] During: typing of call at /datc/dh_data/.conda_env/scrna/lib/python3.6/site-packages/umap/umap_.py (797)


File "../../../../.conda_env/scrna/lib/python3.6/site-packages/umap/umap_.py", line 797:
def optimize_layout(
    <source elided>

                dist_squared = rdist(current, other)
                ^

This is not usually a problem with Numba itself but instead often caused by
the use of unsupported features or an issue in resolving types.

To see Python/NumPy features supported by the latest release of Numba visit:
http://numba.pydata.org/numba-doc/latest/reference/pysupported.html
and
http://numba.pydata.org/numba-doc/latest/reference/numpysupported.html

For more information about typing errors and how to debug them visit:
http://numba.pydata.org/numba-doc/latest/user/troubleshoot.html#my-code-doesn-t-compile

If you think your code should work with Numba, please report the error message
and traceback, along with a minimal reproducer at:
https://github.com/numba/numba/issues/new