Closed Pancreas-Pratik closed 3 years ago
Thanks for reporting! This happens because when you provide only one name to the graph.name
argument, only the nearest-neighbor graph is stored, and not the shared-nearest-neighbor (SNN) graph. By default (when no graph name is given) the clustering algorithm uses the SNN graph, which is why you're getting different results with/without the parameter here.
The graph.name
parameter was not well documented, so I've updated it to more fully explain the behaviour of the parameter and explain that you should provide a vector of two names, one for the NN graph and one for the SNN graph.
If you think the clustering results are better using the NN rather than SNN graph, you can certainly use that. You might also find that increasing the clustering resolution when using the SNN graph might give a similar clustering result (separate that cluster 9 from 6)
Thank you very much for helping me understand, @timoast! I really appreciate the Satija Lab's effort! It must be challenging to keep up with everything and everyone, but you guys are great at it! Hope you never stop! :1st_place_medal:
Thank you Satija Lab for the incredible work that has been done with Seurat! You guys are miracle workers!
Here is the bug:
I am using the pbm3k dataset from SeuratData as the reproducible example.
I think there is a bug when using the
graph.name
argument. Please correct me if I'm wrong.Simply using the
graph.name
argument generates clustering that is different when not using thegraph.name
argument. (either more or less clusters, more or less cells in clusters)Similar clustering differences happen when using the default algorithm for
FindClusters
as well. Here I used algorithm 4.I thought specifying a
graph.name
should keep everything consistent. I actually prefer the clustering generated with thegraph.name
argument included in my dataset. I'm wondering what is happening.Here is what was done:
Here is the full workflow for with the
graph.name
argument: