addClusters() taking too long

[Rodolfo-Cabrera]

Hello,

I used addClusters() a month ago with the same dataset (but using the default values for the tutorial), and it worked fine. I had to re-do the LSI, and now the addClusters() function is taking too long to complete. Currently, it's running one that hasn't finished. It has been 12+ hours when before it took around 2 or less. Should it be taking this long?

The code that I'm running is the following. I do not have the log file as it is still running and I don't know when it's going to finish.

addArchRThreads(threads = 6) #and 180GB of memory to use. R is only using 2.3GB steadly while running addClusters()
addArchRGenome("hg38")

ATAC_seq2 <- addIterativeLSI(
  ArchRProj = ATAC_seq2,
  useMatrix = "TileMatrix", 
  name = "IterativeLSIres0.2-0.6sample10k_test", 
  iterations = 5, 
  clusterParams = list(
    resolution = c(0.2, 0.3, 0.4, 0.5, 0.6),
    sampleCells = 10000, 
    n.start = 10
  ), 
  varFeatures = 10000, 
  dimsToUse = 1:50
)

ATAC_seq2 <- addClusters(
  input = ATAC_seq2,
  reducedDims = "IterativeLSIres0.2-0.6sample10k_test",
  method = "Seurat",
  name = "Clusters_CutOff3res0.2-0.6sample10k_test",
  resolution = 0.8,
  corCutOff = 0.3,
  dimsToUse = 1:50
)

Console shows the following information of what it has been able to do

Filtering 6 dims correlated > 0.3 to log10(depth + 1)
2022-07-13 10:11:10 : Running Seurats FindClusters (Stuart et al. Cell 2019), 0.005 mins elapsed.
Computing nearest neighbor graph
Computing SNN
Modularity Optimizer version 1.3.0 by Ludo Waltman and Nees Jan van Eck

Number of nodes: 61035
Number of edges: 1418636

Running Louvain algorithm...
0%   10   20   30   40   50   60   70   80   90   100%
[----|----|----|----|----|----|----|----|----|----|
**************************************************|
Maximum modularity in 10 random starts: 0.8397
Number of communities: 8308
Elapsed time: 10 seconds #This is the last printed message, afterwards it's just Rstudio showing that it's running.
#RStudio is not frozen. I can still edit the script, save it and move around RStudio

My ArchRProject has 8 samples with 61,035 cells. I updated ArchR 1.0.2 a week ago and the last time I ran addClusters() was with the 1.0.1 version.

I appreciate any help or tips you could give me to find out what is happening?

Thank you!

Update: After more than 900 minutes it finished. I upload the logfile in case it helps
ArchR-addClusters-186115f6ad545-Date-2022-07-13_Time-10-11-10.log
s

[Zepeng-Mu]

I'm seeing a similar issue. My problem is that Number of communities is unusually high, such as around 400. And then it took ArchR very long time to somehow "merge" these communities into a more reasonable number of clusters, like around 30 depending on the resolution. This is something that only happened in the latest version of ArchR I believe and is the main step that takes very long time. Previously the Number of communities is basically the number of final clusters. I'm not sure why this is happening and whether it's an intended change from previous releases.

[ZunpengLiu]

Got the same issue.

[rcorces]

Interesting. My gut response is that this is unlikely a problem with ArchR. The code to Clustering.R where addClusters() is located hasnt been updated for 2-3 years. So I dont think this is a code change in ArchR that has caused a new problem. addClusters() is really just a wrapper around Seurat::FindClusters(). That being said, I dont see code changes in Seurat that would explain this either. The place where @IsmaelMaza 's code is hanging is during Seurat::FindClusters().

If you really think this is an ArchR problem, it would be helpful to see how long it takes to run the relevant command on the same data using release_1.0.1 and release_1.0.2

[Rodolfo-Cabrera]

Hello, I changed to version 1.0.1 and redo the analysis. This time is took 2 minutes and found fewer communities (549). This is what the console output looks like.

ArchR logging to : ArchRLogs\ArchR-addClusters-2d94575d18df-Date-2022-07-14_Time-16-48-57.log
If there is an issue, please report to github with logFile!
Filtering 26 dims correlated > 0.3 to log10(depth + 1)
2022-07-14 16:48:57 : Running Seurats FindClusters (Stuart et al. Cell 2019), 0.002 mins elapsed.
Computing nearest neighbor graph
Computing SNN
Modularity Optimizer version 1.3.0 by Ludo Waltman and Nees Jan van Eck

Number of nodes: 61035
Number of edges: 994510

Running Louvain algorithm...
0%   10   20   30   40   50   60   70   80   90   100%
[----|----|----|----|----|----|----|----|----|----|
**************************************************|
Maximum modularity in 10 random starts: 0.8156
Number of communities: 519
Elapsed time: 6 seconds
493 singletons identified. 26 final clusters.
2022-07-14 16:51:10 : Testing Biased Clusters, 2.223 mins elapsed.
2022-07-14 16:51:11 : Testing Outlier Clusters, 2.23 mins elapsed.
2022-07-14 16:51:11 : Assigning Outlier Clusters (n = 12, nOutlier < 5 cells) to Neighbors, 2.23 mins elapsed.
2022-07-14 16:51:11 : Assigning Cluster Names to 14 Clusters, 2.24 mins elapsed.
2022-07-14 16:51:12 : Finished addClusters, 2.248 mins elapsed.

I have also attached the logfile. Another change I did, because I'm working in my personal laptop, the cores I'm using are just 1 instead of 6. I don't know what is happening with version 1.0.2. Could it be that addClusters() calls another R script that is shared among several functions ? and that script was modified during the 1.0.2 update and its now affecting addClusters(). I sorry I can't do more but I do not have experience with troubleshooting.

Thank you for the tip and I hope this helps to find what is happening.

ArchR-addClusters-2d94575d18df-Date-2022-07-14_Time-16-48-57.log

[rcorces]

I'm willing to be wrong on this but its just very odd that the code for addClusters() hasnt changed since release_1.0.0.
From your two log files, there are multiple other packages changing version between the logfile using release_1.0.2 and the logfile using release_1.0.1

For example, in the logfile using release_1.0.2 you have:

SeuratObject_4.0.4
Seurat_4.1.0

and in the logfile using release_1.0.1 you have:

SeuratObject_4.1.0
Seurat_4.1.1

The other main inconsistency that I can see from what you've shared is that with release_1.0.2 you get this message from getReducedDims():

Filtering 6 dims correlated > 0.3 to log10(depth + 1)

and with release_1.0.1 you get this message:

Filtering 26 dims correlated > 0.3 to log10(depth + 1)

but the code for getReducedDims() hasnt changed either.

Can you confirm that you are using the same exact ArchRProject object when testing with 1.0.1 and 1.0.2? An can you re-install 1.0.2 and test with the same versions of Seurat and SeuratObject just to make doubly sure?

[Rodolfo-Cabrera]

I agree, several packages does differ because he first time I used a shared server and I don't have credentials to modify the packages version there (that's why I had to revert ArchR version in my personal computer). I'll redo it in my computer and do it in both ArchR versions.

[Rodolfo-Cabrera]

Hello again. I found the issue for my case.
I wanted to start from the beginning (new arrows and all) to prevent any confusion with arrows previous data and logs. Also, I redid the script to also verify any problem in the code, and I found that the issue is the amount of dimension in my LSI.

The first time I had 1:50 dimensions in the code

ATAC_seq2 <- addIterativeLSI(
  ArchRProj = ATAC_seq2,
  useMatrix = "TileMatrix", 
  name = "IterativeLSIres0.2-0.6sample10k_test", 
  iterations = 5, 
  clusterParams = list(
    resolution = c(0.2, 0.3, 0.4, 0.5, 0.6),
    sampleCells = 10000, 
    n.start = 10
  ), 
  varFeatures = 10000, 
  dimsToUse = 1:50 #<----
)

When I moved everything to my computer, I had a typo and reduced the dimensions to 1:30. This is when it ran fast.
Now, with version 1.0.1, I used 1:50 and I am having the same slow process with a high number of communities as before with version 1.0.2.
Side note, in both cases, I had the addClusters() with dimension 1:50 and it didn't affect the speed (because there were only 30?) nor throw an error of not enough dimensions when the LSI only had 30.

ATAC_seq2 <- addClusters(
  input = ATAC_seq2,
  reducedDims = "IterativeLSIres0.2-0.6sample10k_test",
  method = "Seurat",
  name = "Clusters_CutOff3res0.2-0.6sample10k_test",
  resolution = 0.8,
  corCutOff = 0.3,
  dimsToUse = 1:50 #<--- this stayed the same in both attempts. The slow and the fast one.
)

As for why it worked a month ago, it is most likely that I had fewer dimensions than 50 (I overwrote my script, so I cannot confirm, sorry)

I appreciate your help with this issue very much, and I apologize it went down to a code typo. I will still make the mock run with both versions and report if I find anything new.

[rcorces]

Thanks @IsmaelMaza for solving this. I've made the following changes on the dev branch. I've added a warning message in getReducedDims() that will now let you know if you are requesting dimensions that do not exist in your ArchRProject. 6d26bcd

I also updated the dimsToUse param in addIterativeLSI() to mention that increasing the number of dims could cause downstream issues,
be4d9fc

[Zepeng-Mu]

I'm only using 30 LSI but see the same issue:

> projCmb3 <- addClusters(
+   input = projCmb3,
+   reducedDims = "ReducedMNN50",
+   scaleDims = T,
+   corCutOff = 0.75,
+   dimsToUse = 1:30,
+   name = "ClustersMNN50",
+   resolution = 0.8,
+   maxClusters = 100,
+   # ... = list(nn.method = "rann", method = "igraph"),
+   force = T
+ )
ArchR logging to : ArchRLogs/ArchR-addClusters-2603a5915a7-Date-2022-07-15_Time-15-29-12.log
If there is an issue, please report to github with logFile!
Overriding previous entry for ClustersMNN50
2022-07-15 15:29:12 : Running Seurats FindClusters (Stuart et al. Cell 2019), 0.01 mins elapsed.
Computing nearest neighbor graph
Computing SNN
Modularity Optimizer version 1.3.0 by Ludo Waltman and Nees Jan van Eck

Number of nodes: 322265
Number of edges: 9275790

Running Louvain algorithm...
0%   10   20   30   40   50   60   70   80   90   100%
[----|----|----|----|----|----|----|----|----|----|
**************************************************|
Maximum modularity in 10 random starts: 0.9161
Number of communities: 465
Elapsed time: 251 seconds

There was no such issue when I only had 100,000 cells