summaryrefslogtreecommitdiff
path: root/issues/gemma
diff options
context:
space:
mode:
authorjgart2022-03-03 17:06:33 -0500
committerjgart2022-03-03 17:06:33 -0500
commit53db1da5ea2184287d5eefd8198d27de52bb31a9 (patch)
treed30c35c90d6972b5b7086c598acf9df551f0eced /issues/gemma
parent138868c046dcf9ffe76f811d0256e35b2ccc81b7 (diff)
downloadgn-gemtext-53db1da5ea2184287d5eefd8198d27de52bb31a9.tar.gz
issue: databases getting out of wack a bit
Diffstat (limited to 'issues/gemma')
-rw-r--r--issues/gemma/databases-getting-out-of-wack.gmi25
1 files changed, 25 insertions, 0 deletions
diff --git a/issues/gemma/databases-getting-out-of-wack.gmi b/issues/gemma/databases-getting-out-of-wack.gmi
new file mode 100644
index 0000000..7c3f7ca
--- /dev/null
+++ b/issues/gemma/databases-getting-out-of-wack.gmi
@@ -0,0 +1,25 @@
+# Databases Getting Out of Wack
+
+## Let's use Gemma instead of Reaper
+
+* assigned: Bonface, Zach, jgart
+* priority: high
+* bug
+
+Zachary:
+> Yeah, I think you'd want to get the mean (which is simple) + run qtlreaper
+> (which I think would need to be run in the background) after a change.
+
+Pjotr:
+> Current qtlreaper runs in one of Arthur's scripts globally.
+
+Rob:
+> Yes, that and more. These values are displayed in search results and used
+> to sort by expression mean and peak LRS (using pathetically old code and
+> genotypes). Now if GEMMA were wicked fast we could recompute the 60 million
+> BXD vector results and store that as a big juicy TRANSFORMATIVE blob of
+> data. A big paper in doing just that. Reaper is just wrong at this
+> point. We have LMM: We should use it.
+
+
+