corrupted psf reconstruction about piff

[esheldon]

fixed a typo in the above comment

[esheldon]

Here is the information for this fit in the summary file

size: 1  nfields: 33  type: records

  key               |S12  'D00362921-60'
  expnum             >i4  362921
  ccdnum             >i2  60
  band               |S1  'r'
  path             |S107  'OPS/finalcut/Y2A1/Y2-2331'...
  magzp              >f4  31.705748
  root              |S24  'D00362921_r_c60_r2331p02'
  image_file        |S70  '/data/mjarvis/y3_piff/362'...
  bkg_file          |S65  '/data/mjarvis/y3_piff/362'...
  cat_file          |S62  '/data/mjarvis/y3_piff/362'...
  star_file         |S64  '/data/mjarvis/y3_piff/362'...
  piff_file         |S80  '/astro/u/mjarvis/work/y3_'...
  zone               >i8  37
  flag               >i8  0
  sat                >f8  177700.753806585
  fits_fwhm          >f8  4.3839
  star_fwhm          >f8  1.1290369203501034
  obs_mean_e1        >f8  0.008415331005385778
  obs_mean_e2        >f8  -0.03537302280877288
  obs_mean_T         >f8  0.4409447419723463
  piff_mean_de1      >f8  -0.004284571844887268
  piff_mean_de2      >f8  -0.012916691123610153
  piff_mean_dT       >f8  -0.03646968557218077
  piff_std_de1       >f8  0.08610437680632192
  piff_std_de2       >f8  0.09957051704750827
  piff_std_dT        >f8  0.10126612278282134
  psfex_file        |S83  '/astro/u/mjarvis/work/y3_'...
  psfex_mean_de1     >f8  -0.0003491481502438127
  psfex_mean_de2     >f8  -0.0002522715844744627
  psfex_mean_dT      >f8  0.0029185538753443777
  psfex_std_de1      >f8  0.005132159358516579
  psfex_std_de2      >f8  0.0030328974195780846
  psfex_std_dT       >f8  0.005813012170433939

[rmjarvis]

To follow up, the current thought on this is that it happens when there are few (or even only one) stars in a portion of the field and that star happens to be centered very close to a pixel boundary. Then the model is (nearly) degenerate and the fitter can amplify noise in either a checkerboard pattern (as here) or sometimes just stripes in x or y.

The current "solution" is to use a model with pixels that are slightly larger than the data pixels. We use 0.30 arcsec for the model in DES now, whose image pixels are 0.263 arcsec. This seems to significantly help and these kinds of failures are at least very rare if not completely eliminated.

A longer term solution would be to improve the matrix solver to use SVD or something similar to reduce the noise amplification. This would be significantly slower than the current simple cholesky solver, so we'd want to find a way to detect when such a switch is necessary in order to not massively slow down the solver for most fields.

[rmjarvis]

I believe this is fixed in #88.