Hello,

I am running WGCNA on an expression matrix. I have recently transitioned from running the scripts on my work computer to a computing cluster, and with that transition have moved from testing the code on smaller datasets to the full data set. I have version controlled the package versions on both systems.

I have successfully completed the tutorials here: tutorials for WGCNA, main website with smaller data (I included almost half of the rows of my expression matrix ~40K out of ~100K rows). However when I try to scale to the full dataset, ~100K rows I get a non-critical error (the code doesn't crash, but I get a message) when calculating the Topological Overlap Matrix (TOM) with the command: TOMsimilarity(adjacency), where adjacency is the adjacency matrix from the adjacency() function.

The code does not crash, but it prints to the console "problem: *arbitrary number here* TOM entries are larger than 1", the number of entries that are larger than 1 only increases as I add more rows to the input expression matrix. I am quite confused because I am of the understanding that the values in the TOM matrix should be bounded between 0 and 1. Additionally, the script does not crash when I get the error. I also have been unable to find any other occurrences of people having this problem on the web, so I am very much at a loss as what to do.

Does anyone have any suggestions or advice on what I ought to do? I don't feel like I should continue with the analysis given the nature of the TOM definition, and I haven't been able to find any clues in the documentation for the function...

Thank you for your help!

I would check the resulting TOM. Theoretically TOM is indeed bounded between 0 and 1 but numerical errors can sometimes cause it to be slightly larger than 1. Calculate max(TOM-1); if this is less than say 1e-10, don't worry about it and continue as usual. However, if max(TOM-1) is of order say 1e-3 or larger, it likely means a problem with the underlying code. If you use a fast BLAS implementation, these have been known to "occasionally" (in some versions and on some architectures) produce errors or erroneous results.

Thank you Dr. Langfedler for your help with this. Your suggestion to try a BLAS implementation other than OpenBLAS worked for me. For others with this problem who may be reading this, I found that the libr implementation as well as the MKL implementation of BLAS worked and gave me correct values. The MKL implementation was slightly faster. Finally, at least for me, my personal computer's installation of R was using libr by default, that is why once I transitioned to using the computing cluster's implementation of R (which by default used OpenBLAS) I noticed an issue. Even if you version control all of your packages when moving from your personal computer to a cluster, it is worth checking the BLAS algorithm as well.

Once again thank you so much! I would have never thought to check something like the BLAS algorithm. You saved me a lot of time and headache!