The matched catalog is stored in a local disk in Mitaka. It is missing some regions in the original catalog. Ishigaki-san checked the md5 checksum and confirmed OK. It seems it was simply an issue during the DB insertion. This has been fixed. But, it does mean that there was this problem in the previous version.

The PS1-Gaia catalog has flags summarized at
https://gea.esac.esa.int/archive/documentation/GDR3/Gaia_archive/chap_datamodel/sec_dm_cross-matches/ssec_dm_panstarrs1_best_neighbour.html
We did not use any flag cuts before, but we exclude (1) Gaia objects matched to multiple PS1 objects, and (2) PS1 objects matched to multiple Gaia objects. Ishigaki-san told me that they account for 0.42% of the objects.

The engineering data from July suggested that there is something going on at the very bright mags; they are often rejected by bad temperature estimates from the broad-band photometry. I suspected that this was due to saturation (recall we did not apply any quality cuts).

Ishigaki-san looked into this futher. These bright objects have low S/N. That is odd because they are bright objects. Although we have not fully understood the problem, bright objects do have varying S/N as shown in this plot. There are also a bunch of fainter objects with low S/N for their magnitudes. They are extended sources in PS1. Because we matched with Gaia, we must be looking at point sources, but these sources are likely blended with nearby sources. We'd better remove them as well. These objects indeed are often off from the stellar sequence.

We choose to apply [grizy]FlagExtended==False. But, there remains a significant S/N scatter at the bright end. Ignore the colored points and lines in the figure. Photometry is PSF photometry. The figure is by Ishigaki-san.

The log(S/N) version of the figure is here (the previous one was linear in S/N). Again, Ishigaki-san made this figure. S/N is nearly constant at the bright magnitude. We do not know exactly how the PS1 photometry is made, but we do not dig into this further. There are objects with very high S/N for their brightness and we may add a noise floor to the photometric error when we run brutus. This is the subject of a separate ticket (PIPE2D-1340).

I think the catalog is now reasonably clean. ishigaki could you look at the comments above? If you think these are a reasonable summary of your work, please close this ticket.

We will apply the bright magnitude cut of g/r/i/z/y = 14mag to exclude low-S/N objects at the bright end.