Commit summary from repository starlink
------------------------------------
(David Berry) ndg: Fix problem with provenance hash codes used to identify NDFs
100.0% libraries/ndg/
(Ed Chapin) smurf: fix CALCNOISE problem by updating dimmconfig_calcnoise.lis
100.0% applications/smurf/examples/
(Ed Chapin) smurf: CALCNOISE can optionally write-out cleaned time-series
81.1% applications/smurf/libsmurf/
18.8% applications/smurf/
(Ed Chapin) smurf: add 1/noise^2 weighting to AVPSPEC functionality of SC2FFT
82.1% applications/smurf/libsmf/
15.4% applications/smurf/libsmurf/
2.3% applications/smurf/
(Ed Chapin) smurf: trap NULL data pointer
100.0% applications/smurf/libsmf/
(Ed Chapin) smurf: update sc2fft defaults for avpspec slightly
52.2% applications/smurf/libsmurf/
47.7% applications/smurf/
Commits from repository starlink
-----------------------------
commit 959161ebc1d19f5ba61c4cccdff21fe378f89372
Author: David Berry <[log in to unmask]>
Date: Mon Jun 13 21:49:17 2011 +0100
ndg: Fix problem with provenance hash codes used to identify NDFs
kappa:paste was crashing with a seg fault because the provenance system
had produced a situation where an NDF was its own ancestor, thus causing
an infinite recursion loop. This turned out to be due to two different
NDFs being assigned the same hash code. Changign the hash code algorithm
from 32 bit to 64 bit did not fix this. There seems to be some
deterministic reason why these two NDFs end up with the same hash code,
but I can't work out what it is. A work-around seems to be to add an
extra shift of one bit to the hash code when combining the hash code of a
parent with all the hash codes of its children.
libraries/ndg/ndg_provenance.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
commit 57edd9050d3795c5498d796a71aeb61bc3b3b926
Author: Ed Chapin <[log in to unmask]>
Date: Mon Jun 13 13:47:32 2011 -0700
smurf: fix CALCNOISE problem by updating dimmconfig_calcnoise.lis
We were getting strange results, particularly for short data files,
from CALCNOISE measurements using dimmconfig_calcnoise.lis. I traced
the issue to smf_get_padding erroneously deciding to pad the data
because some flt.* parameters were set (the padding amounted to
a huge portion of the time-series and seriously mucked with the
power spectra). I now set a bunch of defaults to explicitly turn
off any filtering parameters that might throw-off smf_get_padding,
although really smg_get_padding should be modified. See
ticket #703.
.../smurf/examples/dimmconfig_calcnoise.lis | 41 ++++++++++++++++++
1 files changed, 41 insertions(+), 0 deletions(-)
commit fd91693c341ae2ba6bfa880bad05be4372d62b4b
Author: Ed Chapin <[log in to unmask]>
Date: Mon Jun 13 13:46:54 2011 -0700
smurf: CALCNOISE can optionally write-out cleaned time-series
applications/smurf/libsmurf/smurf_calcnoise.c | 28 ++++++++++++++++++++++-
applications/smurf/smurf.ifd.in | 10 ++++++++
2 files changed, 37 insertions(+), 1 deletions(-)
commit 5ebad6f88494cd4af2ef234eeb3372f12f9c365b
Author: Ed Chapin <[log in to unmask]>
Date: Mon Jun 13 11:34:15 2011 -0700
smurf: add 1/noise^2 weighting to AVPSPEC functionality of SC2FFT
applications/smurf/libsmf/Makefile.am | 2 +-
applications/smurf/libsmf/smf.h.source | 3 +-
applications/smurf/libsmf/smf_fft_avpspec.c | 21 ++-
.../{smf_stats1.cgen => smf_weightstats1.cgen} | 141 +++++++++++-------
applications/smurf/libsmurf/smurf_sc2fft.c | 37 ++++-
applications/smurf/smurf.ifd.in | 9 +
6 files changed, 142 insertions(+), 71 deletions(-)
commit 14a22b149d85e4ea00aaa61ca48a849208439d8c
Author: Ed Chapin <[log in to unmask]>
Date: Mon Jun 13 11:31:26 2011 -0700
smurf: trap NULL data pointer
applications/smurf/libsmf/smf_stats1.cgen | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
commit 8e6c08ba67ec1c5c0f53479604cf534899fb60eb
Author: Ed Chapin <[log in to unmask]>
Date: Mon Jun 13 09:51:48 2011 -0700
smurf: update sc2fft defaults for avpspec slightly
applications/smurf/libsmurf/smurf_sc2fft.c | 4 +++-
applications/smurf/smurf.ifd.in | 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
|
