Hello All,
Our lab is getting some interesting results whereby we have modules that have both positive and negative kme values in a signed network. If a higher power is used this goes away but the lower power already surpasses the R2 and k.means thresholds. Any insight would be helpful.
Best,
Duc
•
written
by
ductylerlv •
Thanks Kevin and all who have looked at this issue-- Peter Langfelder suggested bypassing use of TOM for the dissimilarity metric used to cluster, which can disagree sometimes substantially with expected module membership based on kME table (based on the experience with this and similar large multi-batch, batch-corrected, data). The batch variance removal prior to WGCNA blockwiseModules() may/may not play a role, which begame the focus of the above post. Regardless, adding the parameter to bypass TOM and use the adjacency matrix instead, TOMType="none" seems to have handled all abnormal assignments in a kME table of a similar network, and I suspect it will work for these data. Cf. interactions on the bioconductor forum for more of Peter's response.
Practical solution found -- I recommend Duc close this thread!
Thank you for posting this. Indeed, it was better to hear the developer's (Peter's) thoughts on this, which seems to be a very obscure problem. I have toggled your answer to Accepted, as it may help others arriving here in the future.
I can say that running WGCNA_1.64-1 on R v3.5.1 today with the same input data but passed through a more robust normalization by median polish does not have any module member (non-grey) with a kME below +0.29, and signed aspect of the network (networkType="signed" parameter for blockwiseModules() ) appears to be working on the slightly different input protein abundance matrix. I checked the kME table and found NO non-grey module with any members having negative correlation or kME<0.29 . Thus, the prior 2-step batch normalization procedure may have caused something in the correlation structure to trip up WGCNA enforcement of signed modules, though I am not sure why. Perhapsfocusing on data normality and variance correlation could bring some clarity for others, so I thought I would post this experience.
Great. So, you are implying that the issue was the distribution of the input data? If you feel that this answers your own question, then, perhaps, you can accept your own answer so that this thread will no longer be 'bumped' to the main page listing.
Great for this dataset after many months of head scratching. However, the WGCNA package blockwiseModules() function should not leave unsigned, negative kME, proteins in modules of a signed network, regardless of normalization subtleties of the input data. There seems a possibility that something assumed by the algorithm isn't correct for this particular input dataset. Getting a result that contradicts the algorithm settings for output suggests both the algorithm and the input are interacting in an unpredictable way, and it would be good to get to the bottom of this. I can't say the issue is resolved, as until now we have never needed median polish normalization of proteomics data going into WGCNA. However at 11,200 proteins x 243 brain case-samples, this is the largest proteomics dataset I have tried WGCNA with. The bigger the sample size, the more robust the correlation structure should be, and the easier to pick out signed co-expression modules. But not in this case.
Please contact the WGCNA developer. Your concerns and questions are no longer for me to answer.
Log in to answer this question.
can you post the code ?what you had done?
I was the one who encountered negative and non-correlated kME values for specific network nodes in WGCNA with the following input and code. The soft threshold criterion for scale free topology was met at power, beta, 7.6. We chose 8.5 to reduce noise further.
And the resulting protein network has module(s) like the below violet module, where we never usually see kMEintramodule<0.20, but here we do:
Clearly some of the lower violet module members should go to orangered4 with kMEorangered4>0.7.
Interestingly, some orangered non-hub members suffer from anticorrelation to their own ME, precisely what should not be seen in signed network modules:
Full code to reproduce the problem follows:
Formatted ModuleAssignments (kME table) can be found here: Excel Binary kME Table for above network output
Input for cleanDat log2(abundance) matrix loaded in above code is here: ZIP with log2(abundance) matrix text tab-separated file
...explicit use of minKMEtoStay=0.30 has never been necessary before.
I should add that minKMEtoStay=0.30 is a default parameter/setting: blockwiseModules in WGCNA v1.64 default parameters
Rerunning the above blockwiseModules() function with this parameter added to the others gives identical modules.
My sessionInfo follows:
Did I provide too much information? Hoping to get some feedback.
Perhaps this answer from the WGCNA developer helps? - https://support.bioconductor.org/p/101579/