Closed aaronkwong closed 11 months ago
Thank you for the detailed report! I was able to reproduce your results and I don't think you're doing anything incorrectly. Rather, this is most likely caused by the fact that smoothing splines (and loess) tend to get a bit unstable at the extreme ends of their range. Since the curves are based on smoothing splines, this can sometimes cause issues like the one you're seeing.
I think the best thing to do in these cases is to try adjusting the extend
parameter in getCurves
. I've found that setting extend = 'n'
or extend = 'pc1'
can sometimes mitigate these stability issues. (Briefly, this argument controls how Slingshot constructs an initial guess of the pseudotime values based on the MST for cells that lie beyond the center of terminal clusters or before the center of the initial cluster).
Fortunately, both seem to produce reasonable results on your toy dataset (while setting cluster 4 as the starting cluster), though 'pc1'
might be slightly better.
extend = 'n'
:
extend = 'pc1'
:
Thank you so much for the detailed and quick response, very well explained.
Aaron
Hello,
I am experiencing some unexpected behavior when drawing the curves from slingshot. It seems that specifying the label of a particular cluster as the "start.clus" results in a different cluster being used as the start when the curves are drawn.
Given a test dataset of embeddings (emb) and cluster labels (clusters):
When running slingshot with the start.clus= "4", the curves drawn appear to start from cluster "0"
Interestingly, if start.clus is set to "0" instead, it produces curves which appear to start from cluster "4"
I have attached the script and toy dataset to reproduce these results. Could this be an issue with the labels getting mixed up in the function drawing the curves? or perhaps I am specifying the start.clus incorrectly?
Thanks, Aaron
start_clus_issue.zip