I'm still thinking about two possibilities regarding where we store the output from `shuffle`, and it's a bit difficult to explain in this comment, but...

option 1. we make `pfs_design_agc` for (guide and acquisition) objects in AG camera like `pfs_design_fiber` for science objects in fibers.

----------------------

pfs_design_agc

----------------------

pfs_design_id (FK; not null)  ---> referring to `pfs_design`

agc_camera_id (not null)

guide_star_id (not null)  ---> Gaia ID?

agc_target_x_mm

agc_target_y_mm

...

----------------------

In this design, I'm assuming both `ets_shuffle` and `ets_fiberalloc` run integrally and save all information to `pfs_design`, `pfs_design_agc` & `pfs_design_fiber` in the end of the process.

 option 2. we make `shuffle` and `shuffle_agc`

----------------------

tile

----------------------

tile_id (serial not null; auto-incremented)

program_id (FK)

ra_center_initial

dec_center_initial

pa_initial

...

----------------------

----------------------

shuffle

----------------------

shuffle_id (serial not null; auto-incremented)

tile_id (FK)  ---> referring to `tile`

ra_center_designed_shuffle

dec_center_designed_shuffle

pa_designed_shuffle

...

----------------------

----------------------

shuffle_agc

----------------------

shuffle_id (FK; not null)  ---> referring to `shuffle`

agc_camera_id (not null)

guide_star_id (not null)  ---> Gaia ID?

agc_target_x_mm

agc_target_y_mm

...

 ----------------------

----------------------

pfs_design

----------------------

pfs_design_id (not null)

shuffle_id (FK; not null)  ---> referring `shuffle`

ra_center_designed

dec_center_designed

...

----------------------

In this design, we need to run `ets_shuffle` first and decide the pointing center and save info to the database, and then we run `ets_fiberalloc` based on the decided pointing center. I do not think about how to deal with multiple visits using netflow mechanism yet.

I think the current agreement is that "shuffle" will not actually do any shuffling; it will simply output suitable acquisition/guide star candidates for the provided telescope pointing and orientation. If this is correct, then your option 1 feels more natural to me.

One open question from my side: are "agc_target_[xy]_mm" given in PFI coordinates or in a coordinate system specific to every AG camera? If the latter, I'd need a way to transform from PFI to these coordinates (I don't think this is integrated in pfs_utils yet).

Thank you for your comments. I'll push option 1 forward taking into consideration other discussion points. For the open question, I think we should coordinate with the AG camera table (e.g., `agc_data`). I guess currently they are coordinates on AG image in pix, so agc_target_[xy]_pix would be probably what we need.

I found this was still floating, but now it's a time to fix.

Here is a new proposal based on the current datamodel GUIDESTARS HDU in pfsDesign file.

Yoshida, Hiroshige?

----------------------

pfs_design_agc

----------------------

pfs_design_id (FK; not null)  ---> referring to `pfs_design`

guide_star_id (not null)  ---> joinable with GaiaDB

epoch

guide_star_ra

guide_star_dec

guide_star_pm_ra

guide_star_pm_dec

guide_star_parallax

guide_star_magnitude

passband

guide_star_color

agc_camera_id

agc_target_x_pix

agc_target_y_pix

comments

----------------------

I'll implement the design above for now and close this ticket. We file a new ticket if we need a further fix.