GitLab

For more informations see #3268

The FineSegmenter constructor handles the filtering of the germline. By default
the value is "NO_LIMIT_VALUE", which means the filtering isn't active.

For more informations about it #3268.

See #920 and #3190.

(squashed from earlier commits)

This can be useful to align against a collection without the bandwidth
optimisation (see #2767).

core/segment.{h,cpp}, core/windowExtractor.cpp, core/windows.cpp: renames, 'isJunctionChanged', SEG_CHANGED_WINDOW

Completes a76116be.

Windows can be either shortened or shifted.

Warn when we have one.

This requires to add a new segmentation status. The problem is that
Segment::getSegmentationStatus() returns just an integer which doesn't make
possible to have several statuses at once (which could be convenient). A
solution would be to use masks for the statuses (ie. if s is the status we
would store 1 << s).  Since this would require quite some code modification to
achieve that, I added some extra tests (that's bad) to deal with the case
where the segmentation is achieved with a shorter or shifted window. In such a
case we warn the user in the JSON (warning on the CLI should be done too).

See #2913, #2916.

It is good to know so that we can warn the user.

See #2913

It was hard to make some tests (eg. unsegmentation-causes.should-get) have a
too short window. Modifying a constant just so that the test passes is bad
practice, but this is not the case here (at least I believe so).  Having
difficulties to have a too short w also meant that in practice we would almost
never see a “too short w” again. This could be nice. But we know that the
position of the window is not accurate (it is not designed to be). Therefore
20nt, if they are perfectly centered may be ok. But we know that it may not be
well centered (and we even allow some shifts). Therefore 30nt seems to be a
safer limit.

See #2913

See #2913

We now have an abstract class to deal with biological sequence files. This
will allow to more easily manage different file types.

This commit only reorganizes the code so that we will be able to add a BAM
reader easily. Functionnally the code should be equivalent to its previous
version.

Some functions that were not used have been removed.

The operator>> has been removed as it was only used in unit testing. This
operator is not convenient as having the filename may be useful to reopen the
file or to know its extension, to guess the filetype.

See #2016

See #1580.

Following f78c6fc3, name these constants in a positive way,
as we report these unsegmentation cases.

There were previously two places where the segmentation could fail with UNSEG_ONLY_V/J.
The first one, when there is no 'good' segmentation point, was improved by 5298c86f, requiring at least 5 k-mers.
It turned out that it was not sufficient, as reported by @flothoni in #2107.

Contrarily to what what thought in 5298c86f, the segmentation point returned by kaa->getMaximum()
is actually meaningful to compute some e-values, even when kaa->getMaximum().max_found is false.

We thus now remove completely some ancient code where the thresholds were based on the number of k-mers,
and rely solely on checkLeftRightEvaluesThreshold() to discriminate between these unsegmentation causes.

Streamlines the code, and will fix #2107.

A @rchikhi set with ~150M reads tested with all locus gave an e-value multiplier >2^31,
leading to integer overflow and many spurious clones.

Moreover, the previous multiplier was only an 'int', depending on the actual implementation.
The multiplier is now a float (double) value.

Preliminary implementation, for vdj_assign

Clean stdout. We just report here the JUNCTION, including Cys104 and Phe118/Trp118.

This was realized after prototyping and tests by @flothoni.
As in IMGT/JunctionAnalysis, the detection relies on the positions of Cys104 and Phe118/Trp118.
The detection is here in O(n), taking advantage of the already aligned V and J segments.

The current implementation will not give a precise positions when there are insertions or deletions
between Cys104 and the end of the V segment  (or between the start of J segment and Phe118/Trp118).
This could be improved by backtracking the DP matrix.

This further cleans the code and allows to output D1/D2 boxes as well.

One day, we may change '5del' and '3del' fields, their naming is not so consistent.

Bug detected thanks to a full Valgrind.

We do not want to detect twice the same D gene.
Note that we do not currently forbid alleles of a same gene.

Discussion between @flothoni, @mikael-s, and @magiraud.

When a D has already been detected, we do not want to detect anything inside this D.
Before this commit, spurious D detections could happen in the EXTEND_D_ZONE.

Discussion between @flothoni, @mikael-s, and @magiraud.

We need to store sequence_or_rc in the Segmenter.