GitLab

Conflicts:
	src/green/gremlin1/Makefile

copy literally from TFtexte/pjt/distel/abb/synt/2lay

Use proper libtsioxx output operators.

soutifuamp.gpt was accidentally deleted by target simulclean

HERE documents are cannot be defined within make rules. A work-around are
multi-line make variables exported to the environment and printed to file
within the shell. This way explanatory texts are easier to maintain and are
even easier to read within the Makefile

- provide detailed documentation
- add noise to synthetic test data
- provide control plots

Multiple calls to ts::rnd::dugauss() resulted in identical sequences of random
numbers.

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
  function
- the destructor is guaranteed to be called after termination of the program,
  such that the destructor is able to properly call gsl_rng_free

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.

Contents still referred to trac/SVN repository TFSoftware

Fix some sentences and expressions in the online description. These were not
wrong previously but could be expressed in a more appropriate or consistent
way.

The offset dependent scaling factor was wrong incorrectly specified in the
online documentation.

Thanks to Florian for pointing this out.

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.

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.