GitLab

see #3914

It will depend on the order in which reads are coming when computing
the representative but this order is random. What is important is that
we find a representative of the correct length with the correct sequence
whatever the read name and read positions are.

It is hard to predict the result is not totally deterministic
(as is the case with the RandomScorer, which is now by default,
whose results depend on the pseudo-random generator that may
differ depending on the OSes)

See #3866

see #3866

see #3866

Computing them for each read is time consuming.
But many of the are common (there are few different
index loads and the read length is small)

This prevents from recomputing it each time

This is needed now that we use an unordered_map with a KmerAffect (see
previous commit) as explained here:
https://stackoverflow.com/questions/17016175/c-unordered-map-using-a-custom-class-type-as-the-key

max12() actually didn't require a CountKmerAffectAnalyser.
The CountKmerAffectAnalyser builds a data structure to improve
KmerAffect counting at any position. But this was not needed for the max12() function

We absolutely don't need to call getDistinctAffectations to destroy the objects

Closes #3762.

see #3762

see #3762

See #3762. We have --extra

see #3206

see #3206

Fix #3414

IGHJ5*01 and IGHJ5*02 are equally good. Without #3414
we can have either sequences.

Alignment:
read             gactactggggccagggaaccctggtcaccgtctcctcag
IGHJ4*01   8     ..............A.........................
IGHJ4*02   8     ........................................
IGHJ4*02   8     ..............A..G......................
IGHJ5*01  11     ....C.........A.........................
IGHJ5*02  11     ...CC...................................

See #3414 and 68b6ebcb.

Closes #3837, #3839.

See #3839.

See #3839

Opens #3839.

See #3837.

see #3837.

There is now some hack to get a json, it could be improved.
See #3837.