Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
coordinates
We trust the HDF5 peaks, even if we can't see a peak there. That means
we can't reliably take a centroid and "improve" the coordinates. In
some cases, the centroiding procedure seems to be making the peak
coordinates worse than they were originally.
Now, the only remaining checks are:
1. Is the peak in a bad region of the detector?
2. Is it saturated? (but --use-saturated is the default)
3. If --check-hdf5-snr, is it above the minimum SNR?
|
|
|
|
Previously, this was broken when not using a mask
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The main motivation for this was that argparse handles positional
arguments which start with minus signs, which is the behaviour we prefer
here.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Just to make it more consistent with fs/ss directions
|
|
This is a long-standing bug, which we got away with up to now because
top-level options with more than just a single number or location were
rare or possibly never used at all.
|
|
|
|
If the rail vector is +z (the default), then the value doesn't matter.
However, it still mustn't be NaN.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|