do we need posflux tables generated in triplicate?

[srodney]

@koconnor4 and @AdkPete - I think you may have been involved in this issue during Sprint1

Currently, several functions in fakeplanting.py are using a 'posflux' table to pass around the x,y coordinate locations and fluxes of fakes that are being planted in each image. For a triplet of images (template, search, diff) these x,y locations should be identical (right?).

Some functions seem to be generating a list of three posflux tables like this:

            posfluxlist[0] is the diff image posflux table
            posfluxlist[1] is the search image posflux table
            posfluxlist[2] is the template image posflux table

Could we reduce this to just a single posflux table?

If not, then should we define a Class for this triplet of tables?
If so, we could more clearly indicate which table is which, and include other properties (like the WCS of the images) and other functions (like, in the future we might have each transient defined as an evolving SN, so we'd include a method to evolve each fake to a new observation date).

Should we be using absolute astrometric coordinates (RA, Dec) instead of x,y as the primary way of tracking positions of fakes?

[koconnor4]

Could/should we reduce this to a single posflux table by using astrometric coords?...

• I think cleanest/simplest solution is to make sure pristine of A,B,C ~ diff,search,template are all registered/trimmed together so we'd only need one with pixels...The examples we have at the moment in test_data have the difference and templates trimmed by pydia however the search is larger (reduced from LCO). We want to plant to the search and difference (not the template)

• From what I can tell the posflux for planting we are using photutils_subtract_psf (changed to work like an add_psf) requires pixels. If we had it as astrometric could we feed our version a self.wcs to turn it into pixel for given A,B,C?

• posflux : Array-like of shape (3, N) or ~astropy.table.Table

  Positions and fluxes for the objects to subtract.  If an array,
  it is interpreted as ``(x, y, flux)``  If a table, the columns
  'x_fit', 'y_fit', and 'flux_fit' must be present.

[srodney]

Agreed on the use of registered/trimmed data at the top of the pipeline. We could hack the current LCO pydia products to make them fit that requirement. Maybe that could be a new task for the second half of the sprint (not essential if we can work around it for now, but good to do before we get to 'production' mode)

I think it's reasonable to keep the actual planting function working in pixel space (as it currently is). But in the future it would be helpful to have a wrapper function around it, maybe plant_fakes_sky(skyposflux, wcs) that takes in a skyposflux table and a wcs object:

skyposflux : Array-like of shape (5, N) or ~astropy.table.Table

Positions and fluxes for the objects to subtract. If an array, it is interpreted as (RA, Dec, flux) If a table, the columns 'ra', 'dec', and 'flux_fit' must be present.

Internally that function would check if each RA,Dec position is on the image, then convert RA, Dec to x,y and make the xyposflux table, then call the current planting function.

Making that is not high priority, but in the future we may want to work with a fake SN with multiple epochs, so it is fixed in RA,Dec coordinates, but changes x,y (and flux) from epoch to epoch (b/c the images are shifted and rotated). In that scenario we maybe would want to have an external fake database (as originally envisioned for sprint1), and we would track the fake SN in RA,Dec in that db. Then we'd call the plant_fakes_sky function all at once on a whole series of images.