Incorrect dpt on dense toggle-switch
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 2.6k
- Forks
- 779
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 27
Description
Hi, thanks for this great library!
I was playing around with data simulated from the toggleswitch model and was very much surprised to see the result of running the dpt on my simulated data.
The script I am running is the following:
adata = sc.tl.sim('toggleswitch',
nrRealizations=5,
tmax=200,
branching=False)
sc.pl.sim(adata)
sc.pp.neighbors(adata)
sc.tl.louvain(adata)
sc.tl.diffmap(adata)
adata.uns['iroot'] = 0
sc.tl.dpt(adata)
sc.tl.umap(adata)
sc.pl.umap(adata,
edges=True,
edges_width=1,
color=['louvain', 'dpt_pseudotime'],
legend_loc='on data')
In short, I am simulating five realizations of the two-genes toggleswitch model with 200 time steps in each realization and allowing to have multiple realizations from the same branch (otherwise there would be only two possible realizations).
The problem I face is that the result of the pseudo-time computation seems (and is, since I know how the data was generated) wrong. Here are the plots displayed when running this script:

and

As you can see, for some reason, there is like a "jump" being made between the two steady states of the system, resulting in a final time (t=1) being somewhere between the starting point and one steady state. Running the same simulation with branching=True and only two realizations doesn't seem to have this issue.
Since I'm a working student at the ICB, I talked to some people here about it, and we found out the following:
- using
method='gauss'in theneighborscall did help in some situations, but playing with more random datasets later on invalidated this hypothesis. - using less data points (time steps per realization), the intuition was that the high density of points in similar region could have an impact, did work to some extent, but after running some tests, I could still find very pathological situations.
It would be great if someone could look into this, I was told to mention @falexwolf
Thanks!
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.
Research direction
Run the supplied toggleswitch simulation through sc.pp.neighbors, sc.tl.diffmap, and sc.tl.dpt, comparing dense non-branching realizations with the branching case. Investigate how neighbor construction and DPT handle the dense steady-state regions; done means pseudotime follows the simulated trajectory without the reported jump between steady states.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- bioinformatics, machine-learning
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100