1. 23 Mar, 2016 1 commit
  2. 19 Mar, 2016 4 commits
    • thomas.forbriger's avatar
      Merge branch 'master' into noiser · d4190892
      thomas.forbriger authored
    • thomas.forbriger's avatar
      [FIX] (libtsxx): fix random number sequence · 699c7722
      thomas.forbriger authored
      Multiple calls to ts::rnd::dugauss() resulted in identical sequences of random
      Issue regarding random number generator in libtsxx
      Location: src/libs/libtsxx/random.cc
      The function ts::rnd::dugauss() allocates a GSL random number generator and
      immediately seeds it. The seeding operation is required, since the default
      seed is a constant, which would result in identical sequences. Function
      ts::rnd::dugauss() uses the current system time as returned by function time()
      as a seed value. Unfortunately, if ts::rnd::dugauss() is called several times
      during the same second, this also will result in identical sequences.
      Currently ts::rnd::dugauss() is only used by src/ts/wf/noisymize.cc and by the
      filter GaussianNoise in libtsxx.
      The appropriate solution appears to be:
      - encapsulate the GSL randon number generator in a class object, just like is
        provided in tfxx::numeric::RNGgaussian
      - use a static variable of this class type in ts::rnd::dugauss()
        this variable will be initialized only once upon the first call to the
      - the destructor is guaranteed to be called after termination of the program,
        such that the destructor is able to properly call gsl_rng_free
    • thomas.forbriger's avatar
      [FEATURE] (libtfsxx): implement new filter GaussianNoise · 5241d409
      thomas.forbriger authored
      The filter GaussianNoise is provided in tidofi through keyword noi.
      It adds white Gaussian Noise of a given rms amplitude (specified through
      filter parameter) to each time series.
      The filter is implemented in libtsxx. tidofi is additionally linked against
      libgsl to provide random number generator.
    • thomas.forbriger's avatar
  3. 08 Mar, 2016 1 commit
  4. 04 Mar, 2016 4 commits
  5. 25 Feb, 2016 3 commits
  6. 08 Feb, 2016 8 commits
    • thomas.forbriger's avatar
    • thomas.forbriger's avatar
      [MERGE] (master|issue7_refract): solve zero-offset scaling issues in refract · 33d32e44
      thomas.forbriger authored
      Merge branch 'issue7_refract'
      Advance refract version number to 4.14
      This merge commit solves issues when scaling traces with an offset-dependent
      scaling factor. The modifications are prepared on branch issue7_refract.
      The issue observed with the previous version of refract was:
      Refract offers a power-law amplitude scaling. This must fail in cases where
      one of the traces is located at zero offset. In such cases the entire plot
      fails, which can confuse users not aware of this side-effect.
      This problem actually was caused by three problems in the code:
      1 When using the zero offset (least offset) trace as a reference for offset
        dependent scaling (as is the default), a division by zero happens in
        subroutine mpcfactors.
      2 Zero offset traces may come with an mpc-scaling factor equal to zero. This
        means, the trace should be down-scaled to a straight line in any case.
        The current concept of trace scaling does this by leaving the sample values
        of the trace as they are, by using a viewport for the trace according to
        current clipping (derived in function settracevp) and by setting the world
        coordinates for the trace's viewport appropriately (i.e. to infinity). In
        the latter step there happens the nasty division by zero (division by mpc
        factor). This problem is present, even if the zero offset trace is not used
        as a reference.
      3 For a negative exponent the mpc factor of the zero offset trace would become
        infinite even for a finite reference value.
      These problems are addressed in the following way be this merge commit:
      1 Problem is solved by referring amplitude scaling factors to the average
        scaled amplitude in a given offset range in scaling mode 2 and 3 (as was
        provided only in mode 3 so far), which now is the default way, the scaling
        reference is defined.
      2 Problem is solved by setting an upper limit to the world coordinate range
        (in counts) in the trace's viewport, such that the trace is displayed as a
        straight line without causing numerical overflow. This is achieved by
        applying a lower limit ti mpc factors in subroutine refract_settracevp
      3 Problem is solved by enforcing non-negative exponent value.
    • thomas.forbriger's avatar
      [FEATURE] (issue7_refract): robust display of zero offset trace · 5f44aa20
      thomas.forbriger authored
      By introducing an upper limit for the world coordinate range (in counts) in
      the display rectangle (viewport) of the trace, the program now is reobust in
      cases where zero-offset traces shall be displayed with offset dependend
      amplitude scaling.
      This is the final commit to resolve issue7.
    • thomas.forbriger's avatar
    • thomas.forbriger's avatar
    • thomas.forbriger's avatar
    • thomas.forbriger's avatar
      [WP][DOC] (issue7_refract): add introductory comment · b0b3bac7
      thomas.forbriger authored
      Explain the different rectangle definitions used with in settracevp.
    • thomas.forbriger's avatar
      [TASK] (issue7_refract): remove obsolete file · 8805bcdb
      thomas.forbriger authored
      was kept for historical reasons to provide a reference to an obsolete way to
      set the trace view port. This file is from pre-CVS times. Source code history
      now is recorded in the repository. The file is obsolete.
  7. 01 Feb, 2016 1 commit
  8. 07 Jan, 2016 1 commit
  9. 08 Dec, 2015 1 commit
    • thomas.forbriger's avatar
      [FEATURE] (issue7_refract): make offset dependent scaling more robust · 0fabb93e
      thomas.forbriger authored
      - With the previous commits the average scaled amplitude in a given offset
        range is made the standard reference for amplitude scaling in modes 2 and 3.
      - This commit makes sure that the scaling exponent will never become negative.
      A negative scaling exponent would result in a singularity of scaled amplitudes
      at zero offset. Since amplitudes always are expected to decay with offset,
      negative exponents are not required for amplitude scaling.
  10. 07 Dec, 2015 16 commits