Define a revised DDF region for Run3.0i

[jchiang87]

The nominal DDF region, as defined in the DC2 Run 2 Specifications document, isn't aligned with the peak of the visit depth maps for the Run2.2i y01-y03 data. Here are the depth maps with the DDF region plotted in the upper right corner:

The displacement from the depth map plateau is clear in the profile plots of the depth in declination. Here are the RA and Dec profiles with the nominal DDF boundaries shown as dotted vertical lines: The dashed lines in the declination profile shows a proposed shift of the DDF boundaries by -0.567 degrees.

Here's a zoom in on the i-band depth map showing the nominal (dotted boundary) and shifted (dashed) DDF regions overlaid: The maps for the other bands look the same.

The DDF region table in the DC2 Run 2 specifications document would then be updated to be

Position	RA (degrees)	Dec (degrees)
Center	53.125	-27.483
North-East Corner	53.764	-26.766
North-West Corner	52.486	-26.766
South-East Corner	53.771	-28.100
South-West Corner	52.479	-28.100

[egawiser]

This seems sensible to me as long as there isn't any type of sources we care about for the DDF whose positions are only within the original DC2 footprint in the instance catalogs. If the DDF pointings had only utilized small dithers, as originally intended, the region of maximum depth would have included the full dotted square, but given how this has been implemented, the shift seems intelligent. We need to keep the plot above ready to show Rubin Observatory every time somebody from DM says that DDFs need "large" dithers for calibration purposes, as it proves that 10 square degree DDFs make no sense with large dithers (it turns out that DM only needs medium i.e., raft-sized dithers, which would perform much better than what's shown there, thankfully).

[jchiang87]

This seems sensible to me as long as there isn't any type of sources we care about for the DDF whose positions are only within the original DC2 footprint in the instance catalogs.

When we make the instance catalogs for Run3.0i, we can place the sprinkled objects to lie within the revised boundary.

[jchiang87]

One small side benefit of the proposed shift: The revised DDF region looks like it will lie entirely within a single tract instead of straddling three different tracts. So we should avoid problems in the DIA pipeline associated with having too small an overlap (1 arcmin) between neighboring tracts.

[jchiang87]

While investigating #390, I realized that there is a bug in the code that generates the visit-depth maps. The issue is that the depth mapping code used the camera object defined in the obs_lsst package, while the imSim/sims_GalSimInterface code uses the camera object in the obs_lsstSim package. The difference is that for a given location on the sky, the x-y coordinates in the focal plane are transposed between these two packages, e.g., for a given pointing, a CCD in slot R21_S01 using obs_lsstSim would be at the same sky location as the CCD in slot R12_S10 using obs_lsst. The net effect is that for each visit, the depth map code was flipping the projection of the focal plane on the sky through one of the diagonal axes. For the depth calculations, this transposition would have no impact for visits for which imaging is simulated for all of the CCDs in the focal plane. However, as I realized recently, for the y01-y03 image simulations that were run at NERSC, we omitted CCDs that lie outside of the DC2 300 sq deg boundary. In this case, regions near the boundary will have very different depth calculations.

Here are the revised y01-y03 maps where one can see that the omission of CCDs outside of the DC2 boundaries is clearly being applied:

and here are the revised depth profiles in RA and Dec:

The original DDF region lies well within the flat plateaus of the revised depth profiles, so we should continue to use the original DDF boundary definition.

[egawiser]

Aha - great bug catch, @jchiang87 !!! And reassuring that we achieved a DDF where we intended to put one... Does this mean that we really did use small dithers?

[jchiang87]

Does this mean that we really did use small dithers?

I think so. We're using the descDitheredRA, descDitheredDec, and descDitheredRotTelPos columns from our version of the minion_1016 opsim db table, so those must have the small dithers implemented for the DDF visits.

[jchiang87]

Given the revised depth maps, I think it's clear that the original DDF boundaries should be used, so I'm closing this issue.