From 89d448585589d9912ac974b6e4645b47e365bf1c Mon Sep 17 00:00:00 2001
From: Muriithi Frederick Muriuki
Date: Mon, 30 Aug 2021 11:42:33 +0300
Subject: Update with progress and notes

* Update issue with notes on traits file and strains in genotype file
* Add notes on required TODOs
---
 topics/gn1-migration-to-gn2/clustering.gmi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/topics/gn1-migration-to-gn2/clustering.gmi b/topics/gn1-migration-to-gn2/clustering.gmi
index a2a7eb1..363b4bc 100644
--- a/topics/gn1-migration-to-gn2/clustering.gmi
+++ b/topics/gn1-migration-to-gn2/clustering.gmi
@@ -285,3 +285,11 @@ it seems like the groups correspond to the ~riset~ field in GN3, since they shar
 I might need to figure out how the traits correspond to a species.
 
 For the time being, however, I make the assumption that the ~riset~ field for all the traits is the same value, and use that to get the genotype file for use in computation of the QTL values with /rust-qtlreaper/.
+
+### 11:37
+
+The traits files should only contain the strains that can be found in the corresponding genotype file used for computation of the QTLs. If the trait file contains strains not present in the genotype file, then /rust-qtlreaper/ panics and fails.
+
+I should also look into reworking ~gn3.computations.export_trait_data~ function, so that each value is linked to the strain that it corresponds to, so that we do not rely on numerical order. This should help reduce chances of bugs where the strains and the values are not in the same order.
+
+I also need to figure out how the strains in the genotype are passed around in GN1. I have mostly ignored that since in GN1, those details were passed around in a class object.
-- 
cgit v1.2.3