Mikaël Salson authored Jun 18, 2015 and Vidjil Team committed Jun 18, 2015

This prevents encoding issues between the different strings when they are concatenated

Instead of testing whether rep_4 is empty, we define
two different segmentation methods.

Selecting the segmentation method is now cleaner, and does
not require any string comparison. This allows to have (pseudo-)germlines with
the same locus but with different segmentation methods, as here
"xxx" for both MAX12 and MAX1U.

This experimental option tries to segment reads while detecting
translocations involving, for one part, the V(D)J region.

It works - but the probabilistic model is far too stringent here,
giving a p-value of about 0.1-0.2 for 40 unknown kmers.
Somehow, if one half of the read is in V(D)J, then having
unknown kmers in the other half is unexpected !

Now the e-value test is very stringent: we need a '-e 10'.

tests: tests .getIndexLoad() and .getProbability() with both AFFECT_UNKNOWN and AFFECT_NOT_UNKNOWN kmers

The e-value computation could be more precise by taking into account the actual kmer.

The very special germline PSEUDO_GERMLINE_MAX1U is similar to the PSEUDO_GERMLINE_MAX12 germline.

It uses the usual KmerSegmenter, but launches computeSegmentation()
on the most frequent KmerAffect of the read and on the unknown kmer, detecting
translocations involving, for one part, the V(D)J region.

-10 is when there is no rep4. Fix 928a98e6.

Since cb9d3fea, shouldvdj errors were not taken into account.
This is fixed.

core/kmerstore.h, core/germline.cpp: delete only once the index when it is shared between several germlines

This is more generic than was what done by ac3ea649.

Mikaël Salson authored Jun 12, 2015 and Vidjil Team committed Jun 12, 2015

That avoids to duplicate the creation code in several functions

Mikaël Salson authored Jun 12, 2015 and Vidjil Team committed Jun 12, 2015

The functions may be useful elsewhere in the project and they could
be easily reused if they are in the models, not in the scripts

The address is not very meaningful, we just want here to know wheter the germlines
use a same index. The stdout is now more reproducible.

The distance matrix is computed again since 95341e1a, but it
should be done only with the detailed computation of clones (-z).

We now use germlines.data

Now germlines.data should exactly reflect the hard-coded
build_{default,incomplete}_set functions.

core/germline.{h,cpp}, vidjil.cpp: build_from_json() can consider only regular or incomplete germlines