improve documentation

readme.md

@@ -190,19 +190,21 @@ in practice.
 
 ## TODO
 
-* Try invoking GC at end of workloads
-* Hold graph data in memory until another graph is read-in
+* Try invoking GC at end of workloads to reduce paging to disk
+* ~~Hold graph data in memory until another graph is read-in?~~
+  * No, this won't work, because BiGpairSEQ simulations alter the underlying graph based on filtering constraints. Changes would cascade with multiple experiments.
 * Enable GraphML output in addition to serialized object binaries, for data portability
   * Custom vertex type with attribute for sequence occupancy?
 * Re-implement CDR1 matching method
-* Re-implement command line arguments, to enable statistical simulation studies
+* Re-implement command line arguments, to enable scripting and statistical simulation studies
 * Implement Duan and Su's maximum weight matching algorithms
   * Add controllable algorithm-type parameter?
 * Test whether pairing heap (currently used) or Fibonacci heap is more efficient for current matching algorithm
   * in theory Fibonacci heap should be more efficient, but complexity overhead may eliminate theoretical advantage
   * Add controllable heap-type parameter?
 * Implement sample plates with random numbers of T cells per well
-  * BiGpairSEQ is resilient to variations in well populations; pairSEQ is not
+  * Possible BiGpairSEQ advantage: BiGpairSEQ is resilient to variations in well populations; pairSEQ is not.
+    * preliminary data suggests that BiGpairSEQ behaves roughly as though the whole plate had whatever the *average* well concentration is, but that's still speculative.
 * See if there's a reasonable way to reformat Sample Plate files so that wells are columns instead of rows
   * Problem is variable number of cells in a well
   * Apache Commons CSV library writes entries a row at a time