Mise à jour terminée. Pour connaître les apports de la version 13.8.4 par rapport à notre ancienne version vous pouvez lire les "Release Notes" suivantes :

  1. 02 Feb, 2016 6 commits
  2. 01 Feb, 2016 6 commits
  3. 28 Jan, 2016 1 commit
  4. 26 Jan, 2016 3 commits
  5. 21 Jan, 2016 1 commit
    • Mathieu Giraud's avatar
      core/affectanalyser.cpp: safer p-value estimation, taking into account the central region · 2e23e720
      Mathieu Giraud authored
      As detected by @mikael-s in the parent commit, the region between V and J affectations
      was not taken into account in the p-values, yielding erroneous segmentations
      when this region was very large.
      Now this region is counted *both* for the computation of left and right p-values, solving
      the bug of the parent commit.
      This could be sometimes over-conservative : are we counting things twice ?
      In regular situations, the answer is no, as the p-values
      are eventually computed by getProbabilityAtLeastOrAbove in kmerstore.h,
      that takes into account the length of the seed.
      A more exact option could have been to use something like
      (first_pos_max + last_pos_max / 2) + getS()/2, but it would raise symmetry problems.
      The selected option should anyway improve the estimation in most of the cases.
  6. 22 Dec, 2015 2 commits
  7. 18 Dec, 2015 4 commits
  8. 17 Dec, 2015 1 commit
  9. 12 Dec, 2015 7 commits
    • Mathieu Giraud's avatar
      core/affectanalyser.cpp: better estimation of .max_found in .getMaximum(),... · 783d0b19
      Mathieu Giraud authored
      core/affectanalyser.cpp: better estimation of .max_found in .getMaximum(), more reads as UNSEG_AMBIGUOUS
      Since the new flexible heuristic, introduced more than one year ago (de008a24, version 2014-07),
      the idea behind the check of the segmentation point was:
        "Do we have enough affectations in good positions ('before' at the left and 'after' at the right) ?
         We tolerate some of them in bad positions, but there must be 'ratioMin' more in good positions."
      However, the actual implementation of this idea was rather partial.
      As a result, the 'ambiguous' sequence added in the previous commit was falsely segmented.
      The new code is more symmetrical, .max_found being set to true when there are both:
       - more V at the left than V at the right, and than J at the left
       - more J at the right than J at the left, and than V at the right
      "More" is defined by ratioMin and currently equals to 2.0.
      A few reads that were previously segmented will now appear as UNSEG_AMBIGUOUS.
    • Mathieu Giraud's avatar
    • Mathieu Giraud's avatar
      core/segment.h, core/windowExtractor.cpp, vidjil.cpp: option '-uu', do not... · 3b80f387
      Mathieu Giraud authored
      core/segment.h, core/windowExtractor.cpp, vidjil.cpp: option '-uu', do not create files for segmented sequences
      We start the file creation at STATS_FIRST_UNSEG.
    • Mathieu Giraud's avatar
      vidjil.cpp, core/windowExtractor.{h,cpp}: new option '-uu', split reads... · f37be391
      Mathieu Giraud authored
      vidjil.cpp, core/windowExtractor.{h,cpp}: new option '-uu', split reads according to their unsegmentation cause
    • Mathieu Giraud's avatar
    • Mathieu Giraud's avatar
      core/segment.cpp: UNSEG_ONLY_V/J only when there are enough V/J k-mers detected · 5298c86f
      Mathieu Giraud authored
      There are two places where the segmentation can fail with UNSEG_ONLY_V/J.
      The first one, when there is no segmentation point, previously returned UNSEG_ONLY_V/J
      even when there was only one (possibly noisy) V/J k-mer.
      This is now corrected, UNSEG_ONLY_V/J is triggered only when one has at least DETECT_THRESHOLD k-mers (now 5).
      Ideally, we should use here an e-value check, but the segmentation point returned by kaa->getMaximum()
      is not really meaningfull in these cases and my lead to false statistics computations.
    • Mathieu Giraud's avatar
      core/windowExtractor.cpp: do not halt when there is an error in a .fastq file · 0ce12ff5
      Mathieu Giraud authored
      The .fastq parser in OnlineFasta() is rigourous. When the file was truncated somewhere,
      there can be a non-valid sequence at the end of the file.
      Previously Vidjil was halting in this case, and this could be quite frustating
      when a large number of sequences were already processed. Now we just warn the user,
      stop the analysis at this point, and properly output the clones.
      Note that this does not affect the initial scan done on at most SAMPLE_APPROX_NB_SEQUENCES
      sequences (currently 200): Vidjil will still halt on any error in these first sequences.
  10. 09 Nov, 2015 3 commits
  11. 17 Oct, 2015 6 commits