GitLab

For more informations see #3250.

Since these two K-mers need to be printed with a different char, this char
is defined as a new macro used exclusively to represent the K-mer in a string.

For more informations see #3250.

For more informations see #3250.

Since the methods returns the same thing, the getLabel instructions can simply
return the toStringValues function result.

For more informations see #3250.

the toStringValues for those two K-mers must be '_' and '?' respectively.
Even though their char macro is 1 and 0 (non printable characters).

For more informations see #3250.

To fit issue #3250 the macros values were changed.
Char n°0 for ambiguous and char n°1 for unknown K-mer.

Fix #3015

should@0ac73002

Resolve heuristic bug with overlapping k-mers

Closes #3296

See merge request !215

vidjil.cpp: refactor option handling using CLI11

Closes #2732, #2749, #2741, and #2738

See merge request !105

No process before its preprocess

Closes #3289

See merge request !209

Feature c/1943 correlate clones

See merge request !198

Mathieu Giraud authored Jun 04, 2018 and Mikaël Salson committed Jun 18, 2018

- as 'id' is defined and is not nucleic sequence, it is removed from highliting fields
- sortBySize changed due to change of read numbers

Mathieu Giraud authored Jun 04, 2018 and Mikaël Salson committed Jun 18, 2018

See #1943. Find perhaps a more relevant place.

Mathieu Giraud authored Jun 01, 2018 and Mikaël Salson committed Jun 18, 2018

See #1943.

Mathieu Giraud authored Jun 01, 2018 and Mikaël Salson committed Jun 18, 2018

See #1943.

See #3296

The test was classified as ambigious but it probably should not have been. The
fact of having not enough Vs should have classified the read as UNSEG_ONLY_J.

Now the overlapping k-mers where we maximize the score (with the 'before'
affects at the left and the 'after' affects at the right) are ignored. This
therefore gives us the UNSEG_ONLY_J.

The previous UNSEG_AMBIGUOUS was due to the fact that some 'after' affects
(the Js overlapping the end of Vs) were counted left affects and that there
was too many left Js.

Thus we now have 4 UNSEG_ONLY_J sequences and 1 UNSEG_AMBIGUOUS.  As the
sequence whose unsegmentation cause changes is 33nt long, the average length
changes accordingly.

See #3296

When they were counted this biased the counter of before affects on the left part thus
leading to unjustified UNSEG_AMBIGUOUS.

When we are on a plateau and when affectations[i] is defined this means we have overlapping k-mers
thus we don't count those k-mers as left affects (are they left or right? we are actually **on**
the maximum, it is hard to tell).

However if we happen to encounter a higher maximum those ignored values are then reaffected to the left
counters.

Fix #3296

This causes the heuristic not to be symmetric because and having
an undesired behaviour.
In such a case we have a plateau with the maximal value. This plateau
is reached when we have the overlapping V/J. But in this case the J
affects are counted « left » which then prevents the heuristic from
segmenting the sequence as the number of after affects (the Js)
on the left part is too high.

Therefore this has to be changed to that the overlapping affects
are not counted anymore as left or right.

See #3296

See #2732.

add_flag_function() is called only once.
Bug found thanks to CI.