[DAMD-101] Save the outputs of shuffle Created: 11/Dec/20 Updated: 07/May/21 Resolved: 21/Apr/21 |
|
| Status: | Done |
| Project: | Data Model |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Story | Priority: | Normal |
| Reporter: | rhl | Assignee: | hassan |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Story Points: | 3 | ||||||||
| Sprint: | 2DDRP-2021 A 2, 2DDRP-2021 A3, 2DDRP-2021 A 4 | ||||||||
| Reviewers: | price | ||||||||
| Description |
|
Martin Reinecke points out that the outputs of shuffle need to be saved somewhere, and this should be added to the datamodel. We'd want to know at least the position (ra, dec), proper motion/parallax, magnitude, colour, which AG, and AG (x, y). The metadata will need to know the design epoch and telescope elevation (maybe 2020 and zenith). One option would be to add an extra HDU to the pfsDesign file. We also need to worry about refraction, so we'll need to update the (x, y) at the time that we generate the pfsConfig file; this suggests that the pfsDesign proposal is a good way to go. |
| Comments |
| Comment by Kiyoto Yabe [ 16/Mar/21 ] |
|
Hi hassan Reading the current draft, do we need a guide star identifier (e.g. Gaia source ID?) in GUIDESTARS table so that we go back to the original catalogue easily? This may perhaps be an identifier in our database to pool target and guide star candidates to be observed. I also noticed that the HDU number for "PHOTOMETRY" was probably wrong in both `pfsDesign` and `pfsConfig`. HDU #0 PDU HDU #1 FITS binary table named "DESIGN" HDU #1 FITS binary table named "PHOTOMETRY" HDU #0 PDU HDU #1 FITS binary table named "CONFIG" HDU #1 FITS binary table named "PHOTOMETRY"
|
| Comment by Martin Reinecke [ 17/Mar/21 ] |
|
{{shuffle }}executes coordinate transforms in the "sky_pfi" mode. For this to work, accurate time information is necessary, at least with the currently available interface. It may be possible to get away with the elevation angle alone, but I'm not really sure about that. Or is the idea to run shuffle in two different modes: once for rough planning, where the exact observation time doesn't matter because we don't care about differential refraction, and then again once the observation time is known, so it produces exact position data for the guide star candidates? |
| Comment by hassan [ 19/Mar/21 ] |
|
Kiyoto Yabe and Martin Reinecke: I've made updates to the proposed GUIDESTARS HDU based on your recent comments. Have a look and tell me if there are additional changes needed. |
| Comment by hassan [ 19/Mar/21 ] |
| Comment by Martin Reinecke [ 19/Mar/21 ] |
|
Looks good to me, provided we find a way to compute the coordinate transforms given only an elevation angle. |
| Comment by Kiyoto Yabe [ 19/Mar/21 ] |
|
Looks good to me, too. I'm still thinking about how to deal with this in opDB but it should be discussed in FIBERALLOC-34. |
| Comment by price [ 07/Apr/21 ] |
|
We need tests of the GuideStars class (I/O in particular, but would also be good to check that incorrect lengths get caught), and I don't think it's a good idea to allow guideStars=None in the ctor (the user should be forced to think about what he wants). |
| Comment by hassan [ 21/Apr/21 ] |
|
If there are any additional changes needed, new tickets should be filed. |