GitLab

Seems to go back in terms of J affectations. May be due to vdj#692.

See #3315. This is unrelated to #3008.

Sequences are short (or very short): offer several alternatives

See #3315.

TRGJ1*01 has one mutation while TRGJ2*01 hasn't. It's the only difference.
TRGJ1*02 is even slightly better as it has no mutation too but fewer deletions
at the 5' end.

This was detected because of #3148

The start of TRGJ2*01 is identical (seen as a consequence of #3148)

We find a TRGJ2*01 gene with 3 deletions at the start and an exact alignment
while the TRGJ1*02 has 0 deletion and no differences. However for us the
alignment with TRGJ2*01 is longer because we were unable to correctly retrieve
the downstream sequence for the allele TRGJ1*02 (see #3009).

See #3008.

See !148 (comment 83304)
for more information on this change.

IGKJ4*02 has more mutations but aligns on the whole length of the sequence.

At the time this test was made, we didn't launch Vidjil for looking unexpected recombinations.
This is the case for quite some time now and this sequence should have been found as unexpected
but a bug (see #3296) prevented it to be found.

This is now corrected.

With the previous format the BUG keyword was ignored.
We also specify that the bug occurs at the locus level.

See #3296 for the bug.

This is unrelated to this issue.

See #3145 and #3146.

That random sequence was supposed to have too few v/j information (because
it's random!). However, because of bad luck there was some tiny similarities
with IGH but the sequence was not segmented due to inconsistencies with the
strand.
This is still cool because the random sequence is not segmented. However here
we just want to test that a sequence with too few v/j is reported as such. As
the strand consistency is tested first in our algorithm, we didn't report the
too few v/j information. Therefore I modified a single nucleotide in the
sequence to get rid of this strand inconsistency.

I think I always feel guilty when modifying a test example. That's probably
why I needed to make such a long comment.

See !148

It appears in TRBJ2-5*01 which leads to false positives.
The purpose of our dimer was only to have some rubbish sequence.
Thus I have no qualms about changing it.

Désolé pour le côté scatologique du dimer.

See MR !148

- ambiguous kmers: 6% more
- IGHV kmers: 0.3% less, acceptable

See #3008.

When the J gene is too deleted we may not have enough signal.
This should help recognizing more J recombinations. See #3008.

(edited by @magiraud following 928c7390)

The junction is given neither by IgBlast nor by IMGT (the latter correctly
finds the V/J genes though).

Update germlines

See merge request !247

Requires the environment variable COMPILERS to be defined

Test unit+should+valgrind: unit+should+shouldvdj took almost 3h.

Fix #3310 see vdj#450 for compiler installations on the slave.

Feature a/3004 : doc : convert in markdown and update

Closes #3348

See merge request !202

This is less readable but this avoids changing multiple tests
for the same reason (changing IGHV gene number)

See #3362

Thanks to #3364. See also #3349.

See #3364.

See #3364.

Thanks to @mikael-s.
See also #3349.

Therefore this sequence is not a bug anymore

Sequences are identical (on the region where the read is). Therefore we have
to offer alternatives.

It is not clear why the bugs are new.

Consequence of #3009

Changes in IMGT:
- Addition of 8 IGHV genes and alleles (8 F):IGHV1-8*03, IGHV1-69*15, IGHV1-69*16, IGHV2-26*02, IGHV2-26*03, IGHV2-70*15, IGHV2-70*16, IGHV2-70*17.
- Update of reference sequences of IGHV1-45*03 and IGHV2-70*04 (partial sequences were replaced with complete V-REGION).
- TRAJ13*02 reference sequence is AB258131.

See http://www.imgt.org/IMGTgenedbdoc/dataupdates.html

Other changes in MD5 should be due to changes in headers but this is not always true.
- IGKV2D-26*02 has gained 2 nucleotides at its end
- TRGV2*03 has appeared

We note that the new IGHV genes allow to diminish the number of ambiguous k-mers on S22 dataset