Bad astrometry not flagged in database

[Paul Price]

In running the Wainscoat MOPS survey through the IPP, I've found one image that produced two failed warpSkyfiles (exp_name = 905249p, exp_id = 109, chip_id = 110, cam_id = 108, warp_id = 108, skycell_id = skycell.026293[67]). The images are weird, like it's been stretched. Also, judging from the claimed overlap, I would expect to see more lit pixels.

It seems that the astrometric solution is bad. I attempted an independent psastro run, with the following result:

2007-11-17 00:06:26Z|mithrandir |I|psastro

astrometry solution: error: 891.982971 arcsec, Nstars: 74

2007-11-17 00:06:27Z|mithrandir |I|psastro

residual error is too large, failed to find a solution: 891.982971 > 0.500000

2007-11-17 00:06:27Z|mithrandir |I|psastro

failed to find a solution for 35,0,0

pmAstromFitDistortion (pmAstrometryDistortion.c:174) : Unallowable operation: psArray gradients or its data is NULL.
psastroMosaicGradients (psastroMosaicGradients.c:87) : failed to fit the distortion terms
psastroMosaicAstrom (psastroMosaicAstrom.c:74) : failed to measure mosaic gradients (2nd pass)
psastroAnalysis (psastroAnalysis.c:60) : failed to perform mosaic camera astrometry

failure in psastro analysis

-> pmAstromFitDistortion (pmAstrometryDistortion.c:174): parameter is null

Unallowable operation: psArray gradients or its data is NULL.

-> psastroMosaicGradients (psastroMosaicGradients.c:87): Unknown PM error code

failed to fit the distortion terms

-> psastroMosaicAstrom (psastroMosaicAstrom.c:74): Unknown PM error code

failed to measure mosaic gradients (2nd pass)

-> psastroAnalysis (psastroAnalysis.c:60): Unknown PM error code

failed to perform mosaic camera astrometry

I then noticed that there really isn't a lot of stars visible in this image. It turns out it's a 2 sec exposure.

Rerunning ppImage photometry and astrometry, I get "failed to find a solution" for the majority of the chips; from the log file:

[...]
2007-11-17 00:49:51Z|ipp002 |I|psastro

insufficient stars (1) or invalid order (0)

2007-11-17 00:49:51Z|ipp002 |I|psastro

failed to find a solution for 0,0,0

2007-11-17 00:49:51Z|ipp002 |4|psastro

mosaic fit chip order 0

2007-11-17 00:49:51Z|ipp002 |I|psastro

astrometry solution: error: 8.842741 arcsec, Nstars: 4

2007-11-17 00:49:51Z|ipp002 |I|psastro

residual error is too large, failed to find a solution: 8.842741 > 0.200000

2007-11-17 00:49:51Z|ipp002 |I|psastro

solution uses too few stars: 4 < 6

2007-11-17 00:49:51Z|ipp002 |I|psastro
[...]

Plotting the astrometry under dvo with 'imbox' produces shapes which aren't as square as I would expect.

Also, the residual error reported by psastro is different from that recorded in the .smf file:

price@ipp003:/data/ipp002.0/MOPS/run1/proc/905249p.109>echo 905249p.109.ch.110.smf | fields -n hdr NSTARS NASTRO CERROR
905249p.109.ch.110.smf[ccd00.hdr] 1066 9 0.2679958
[...]

So it looks like the astrometry is bad, but ppImage is succeeding, and the error status is not getting reported in the database.

[eugene]

There are/were two issues here:

1) detecting poor astrometry solutions

2) how the ippdb handles poor astrometry solutions

I believe (1) is now much better addressed, though tuning per camera may be required. The minimum number of stars for a given image solution was set too low relative to the number of degrees of freedom: I've bumped these up. There is a value specifying the max allowed error in the psastro recipe, and this needs to be set appropriately for a given camera.

The issue with (2) has been resolved: a poor astrometric solution is not a processing error, but a data error, and is treated by setting NASTRO to 0. the db does not / should not get a fault state in this case, however. But downstream programs need to recognize what is 'bad astrometry' (and now do, I believe).