Bad PSFs for skycells with PS1_V1: PAR_7 low

[Paul Price]

I discovered pmModel.flags and have been employing them in pmPSFEnvelope() and pmReadoutFake(), since some source realisations for skycells on (or beyond) the edge of a GPC1 footprint were bad (e.g., SXX or SYY were outside the limit, low, producing very skinny, unrealistic sources). These can be recognised by using the PM_MODEL_STATUS_LIMITS flag. However more often the PSF includes a bad measurement for PAR_7 (PS1_V1 PSF model) --- for inputs to stack_id = 10067, these are 0.1 for all inputs, which is outside the limit, low, triggering PM_MODEL_STATUS_LIMITS, meaning the model cannot be trusted. This seems to be the case even for skycells not near the edge of the FoV.

I've tried reducing PSF.TREND.N[XY], but same result.

Either:

1. PSF fitting must be more robust, producing PAR_7 not equal to the lower limit; or
2. We declare that PAR_7 outside limits isn't as critical as more important parameters (e.g., SXX, SYY, SXY) and use a separate flag to indicate it's bad; or
3. ???

Some data to demonstrate, from gpc1 database:

Edge of FoV:
warp_id = 1525 (or any warp for stack_id = 10067)
skycell_id = skycell.04774.19

Not edge of FoV:
stack_id = 10128
skycell_id = skycell.04779.22

[Paul Price]

The PSF is fairly nasty for this data --- trailed with multiple clumps.

Relaxing the limits on PAR_7 makes PAR_7 go negative (~ -0.5) when fitting the PSF for a warp (which means the PSF is cuspy, or donut-like). Since the PSF is really so bad, maybe that means that we want to relax the limit of PAR_7 so that it can be (slightly) negative.

The alternative is to abandon these images because of their bad PSF.

[eugene]

sounds like we should relax the limits

[Paul Price]

Set the minimum limit to -1.0 on trunk, r23962.