This subdir has everything necessary for interpreting the raw results 
present in Results.Colony3/, by:
1. transforming them into "Signature files" accepted by ipoolDecoding;
2. decoding the signature files with ipoolDecoding, using the 
appropriate design file for each batch of each type of smart-pool.

In order to decode anything, you need to compile interpool in order
to obtain an appropriate ipoolDecoding program.
This is done in ../interpool-090303_GR/ , and as indicated in
README_GenomeResearch in that subdir, you MUST edit src/config.h
before compiling in order to produce an ipoolDecoding that is
adapted to the worm smart-pools.
The decodeWASP.pl script calls ipoolDecoding and expects it
to be in ../interpool-090303_GR/src/ipoolDecoding .


Again, for historical reasons STD-1536 is called WASP2 here, 
STD-384 is called WASP6, and STD-SL is called WASP2_384.

Sigs.* hold the signatures for each smart-pooling dataset.
Signature files are in a simple XML format, readable by (and 
documented in) the interpool software package.
The three Sigs.* dirs are created by calling allCol2Sig.pl,
colonyToSig.pl does the actual work.
If you rename the Sigs.* dirs and call allCol2Sig.pl, you will
obtain new Sigs.* subdirs filled with content essentially identical
to the current Sigs.* subdirs (except timestamps).

Decodings.* hold the decoded results for each dataset.
As for Sigs, the Deocdings.* subdirs are created by calling
the wrapper script allWASP.pl, and the work is mostly done
by decodeWASP.pl (+ some cosmetic work is done by
addNamesToDecodings.pl). decodeWASP.pl calls ipoolDecoding from
the interpool package (does the heavy lifting).
Again, you can rename the Decodings.* subdirs and then call
allWASP.pl to obtain essentially identical Decodings.* subdirs,
although in this case in addition to different timestamps you 
may have some differences in the order of solutions in cases 
where there are several nearest interpretations, for example:
Decodings.WASP2_384/T386/T386-s2-d16-3m.WASP2_384.Decoded/T386-s2-d16-3m.WASP2_384.batch23.sig.dist6412.Decoded
This is due to the fact that the stdlib quicksort is not stable,
so the order of these equidistant solutions in the output file
is implementation-dependant. Obviously this has no consequences,
other than eg problems when comparing files with "diff".

Finally, Mappings/ holds some auxiliary files that are used by
the scripts (as well as some scripts that generated these files).
For example there are files saying which ORF is represented by
each variable of each batch of smart-pools, and others saying
which pool number and batch number each actual spot on an array
corresponds to.
