efischer/BiGpairSEQ
1
0
Fork 0
Code Issues Pull Requests Projects Releases 13 Wiki Activity

improve documentation

Browse Source
This commit is contained in:
efischer
2022-02-20 15:48:11 -06:00
parent 10d0b711bf
commit 2afd01eeef
1 changed files with 7 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
readme.md
View File

@@ -71,7 +71,7 @@ Options when making a Sample Plate file:
* Standard deviation size
* Exponential
* Lambda value
* Based on the slope of the graph in Figure 4C of the pairSEQ paper, the distribution of the original experiment was exponential with a lambda of approximately 0.6. (Howie et al. 2015)
* Based on the slope of the graph in Figure 4C of the pairSEQ paper, the distribution of the original experiment was exponential with a lambda of approximately 0.6. (Howie et al. 2015)
* Total number of wells on the plate
* Number of sections on plate
* Number of T cells per well
@@ -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