You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thank you for this algorithm, the results look very promising. However, I have encountered the following point of confusion:
I have performed iterativeWGCNA based on 50 samples and 11668 genes with a finalCutHeight of 0.2, resulting in 14 modules by merging from 23 modules. Modules M1 - M4, M6 and M8 are the product of finalCutHeight-dependent module merging.
During the identification hub genes, I noticed that for merged modules, the kME I obtain from calculation with WGCNA::signedKME() differs from the kME as listed in the iterativeWGCNA 'membership.txt' output files. In particular, while most recalculated kME values remain within the rounding error of the membership output, some genes exhibit a difference beyond a rounding error, sometimes exceeding 0.2; Notably, a number of genes fall below the minKMEtoStay threshold of 0.8.
This is illustrated by the following plot, with the kME from membership.txt on the x axis and the recalculated kME on the y axis:
updatedKME is obtained from the following code, where datExpr is the input to the iterativeWGCNA algorithm, and eigengenes come from the iterativeWGCNA output.
Genes with highest kME from module M2, genes from the smaller pre-merge module are marked in yellow (high kME discrepancy). "membership" column shows the kME as reported in merged-0.2-membership.txt.
I also did a superficial comparison of the membership.txt from an otherwise identical run without a finalCutHeight merge. All of this leads me to believe that the kME values in merged-[finalCutHeight]-membership.txt are generated by merging the respective unmerged membership lists without any recalculation of the kME, leading to significant discrepancies particularly for genes from the smaller of the merged modules.
So my questions are:
Why is the kME not recalculated after the final module merge?
Should I expect the minKMEtoStay parameter to apply the to final merge, or is an increased kME spread beyond the minKMEtoStay threshold intentional?
Would recalculating kME, ME, and gene pruning until merged modules are stabilized be methodologically sound?
Best regards,
Wilmont
Python 3.12.0
iterativeWGCNA 1.1.6 / 2018-03-19
###
R version 4.4.2 (2024-10-31)
Platform: aarch64-apple-darwin20
Running under: macOS Sonoma 14.6.1
Matrix products: default
BLAS: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/lib/libRlapack.dylib; LAPACK version 3.12.0
### iterativeWGCNA log with module name annotations
INFO: Saving blocks for each iteration? TRUE
INFO: Merging final modules if cutHeight <= 0.2
INFO: Allowing WGCNA Threads? FALSE
INFO: Running WGCNA with the following params:
INFO: {'power': 11, 'corType': 'bicor', 'maxPoutliers': 0.05, 'TOMType': 'signed', 'maxBlockSize': 25000, 'networkType': 'signed', 'minModuleSize': 30, 'reassignThreshold': 0.05, 'detectCutHeight': 0.995, 'mergeCutHeight': 0.2, 'deepSplit': 1, 'minKMEtoStay': 0.8, 'pamStage': True, 'saveTOMs': True, 'pamRespectsDendro': True, 'verbose': 3, 'numericLabels': True, 'minCoreKME': 0.8}
INFO: Loaded file: [INPUTPATH]
INFO: 50 Samples
INFO: 11668 Genes
INFO: Pass 1 converged on iteration 7.
INFO: FIT: 1728; RESIDUAL: 9940
INFO: Pass 2 converged on iteration 5.
INFO: FIT: 777; RESIDUAL: 9163
INFO: Pass 3 converged on iteration 7.
INFO: FIT: 243; RESIDUAL: 8920
INFO: No modules detected for iteration P4_I1. Classification complete.
INFO: Pass 4 converged on iteration 2.
INFO: FIT: 0; RESIDUAL: 8920
INFO: FIT: 2748; RESIDUAL: 8920
INFO: Found 23 modules.
INFO: ['P1_I7_M4', 'P2_I5_M10', 'P1_I7_M2', 'P1_I7_M5', 'P3_I7_M4', 'P3_I7_M3', 'P3_I7_M1', 'P2_I5_M9', 'P1_I7_M6', 'P1_I7_M3', 'P3_I7_M5', 'P3_I7_M2', 'P2_I5_M5', 'P2_I5_M2', 'P2_I5_M3', 'P3_I7_M6', 'P2_I5_M6', 'P2_I5_M4', 'P2_I5_M7', 'P2_I5_M1', 'P1_I7_M7', 'P2_I5_M8', 'P1_I7_M1']
INFO: Merging P3_I7_M2 into P1_I7_M2 (D = 0.07113649146368917) # merged into M2
INFO: Merging P3_I7_M6 into P1_I7_M1 (D = 0.07468538781353606) # merged into M1
INFO: Merging P2_I5_M2 into P1_I7_M6 (D = 0.07743151939466264) # merged into M4
INFO: Merging P3_I7_M3 into P2_I5_M3 (D = 0.07929802886182524) # merged into M8
INFO: Merging P3_I7_M5 into P1_I7_M4 (D = 0.08953658316214042) # merged into M6
INFO: Merging P3_I7_M1 into P1_I7_M2 (D = 0.11000272648495346) # merged into M2
INFO: Merging P2_I5_M10 into P1_I7_M3 (D = 0.13695642093801474) # merged into M3
INFO: Merging P2_I5_M4 into P1_I7_M6 (D = 0.15932103504959938) # merged into M4
INFO: Merging P2_I5_M5 into P1_I7_M2 (D = 0.17633328863023157) # merged into M2
INFO: Done merging close modules: 9 modules merged.
INFO: Retained 14 modules after merge.
INFO: Reassigned 536 genes in final kME review.
INFO: FIT: 3145; RESIDUAL: 8523
INFO: iterativeWGCNA: SUCCESS
INFO: Sun Nov 24 17:34:17 2024
DEBUG: Ending embedded R process.
DEBUG: R_do_Last()
DEBUG: R_RunExitFinalizers()
DEBUG: Rf_KillAllDevices()
DEBUG: R_CleanTempDir()
DEBUG: R_gc
DEBUG: Rf_endEmbeddedR(fatal)
INFO: Embedded R ended.
DEBUG: Ending embedded R process.
INFO: Embedded R already ended.
The text was updated successfully, but these errors were encountered:
Greetings,
Thank you for this algorithm, the results look very promising. However, I have encountered the following point of confusion:
I have performed iterativeWGCNA based on 50 samples and 11668 genes with a finalCutHeight of 0.2, resulting in 14 modules by merging from 23 modules. Modules M1 - M4, M6 and M8 are the product of finalCutHeight-dependent module merging.
During the identification hub genes, I noticed that for merged modules, the kME I obtain from calculation with WGCNA::signedKME() differs from the kME as listed in the iterativeWGCNA 'membership.txt' output files. In particular, while most recalculated kME values remain within the rounding error of the membership output, some genes exhibit a difference beyond a rounding error, sometimes exceeding 0.2; Notably, a number of genes fall below the minKMEtoStay threshold of 0.8.
This is illustrated by the following plot, with the kME from membership.txt on the x axis and the recalculated kME on the y axis:
updatedKME is obtained from the following code, where datExpr is the input to the iterativeWGCNA algorithm, and eigengenes come from the iterativeWGCNA output.
Genes with highest kME from module M2, genes from the smaller pre-merge module are marked in yellow (high kME discrepancy). "membership" column shows the kME as reported in merged-0.2-membership.txt.
I also did a superficial comparison of the membership.txt from an otherwise identical run without a finalCutHeight merge. All of this leads me to believe that the kME values in merged-[finalCutHeight]-membership.txt are generated by merging the respective unmerged membership lists without any recalculation of the kME, leading to significant discrepancies particularly for genes from the smaller of the merged modules.
So my questions are:
Best regards,
Wilmont
The text was updated successfully, but these errors were encountered: