Science Concept for Additional Functionality in the Mosaic Planning Tool

1. Science Concept for Additional Functionality in the Mosaic Planning Tool Jeff Valenti

2. Current Mosaic Tool in APT

3. Mosaic Pattern Definition in APT • Initial mosaic definition • Specify tiles per row, row overlap, row shift • Specify tiles per column, column overlap, column shift • Specify orientation • Customize a mosaic • Shift tiles • Rotate tiles (may imply different scheduling window) • Delete tiles • Aladin provides a visual interface • [ Initially delivered in APT 20.4, Oct 2012 ]

4. Two Motivations for Additional Functionality • Usability • Users typically want to map a specific region of the sky, regardless of orient. Existing implementation changes sky coverage as orient changes. [Jen Lotz] • Assessing guide star availability at different orients is tedious with current design • Scheduling flexibility • Mosaics are specified at a fixed orient, which implies a narrow scheduling window as one approaches the pole. • The SOC would like to be able to schedule or reschedule mosaics without additional input from the observer. Existing plan is to assign users a new orient and wait for them to submit a revised mosaic specification. That is fine if relatively few mosaics need to be updated.

5. Mosaic Usage in the SODRM 2012 • SODRM 2012 analysis • Caveat: May not be fully representative of actual mission • Over a third of observatory time allocated to mosaics • 53% of NIRCam time is mosaics • 71% of MIRI time is mosaics • Imaging and IFU mosaics • May be difficult to initially schedule (and in some cases reschedule) a large number of mosaics with fixed orients

6. Proposed Mosaic Tool Features • Automatically place tiles for an assumed orient • Enable user to define a region of interest on the sky • Enable user to define points that must not be imaged • Proof of concept algorithm does a good job placing tiles • Explore feasibility as a function of orient • Assess guide star availability for all tiles at all orients • Determine fixed number of tiles for any orient • Enable change of orient without new observer input • Simplifies operations, perhaps significantly • See JWST-STScI-003431 by Soderblom et al. (2013) • “Recommendations for user tools to support mosaics with JWST”

7. Proof of Concept Code • [ show movie ] • A region is a bounding polygon with optional holes • Simple algorithm • Try to cover region with {rows, columns} of tiles • Each {row, column} can have a different number of tiles • Each {row, column} can have a different offset • For each orient, choose whichever uses fewest tiles • Two passes in the proposal phase • Pass 1 – find number of tiles to cover entire region • Pass 2 – fixed number of tiles, measure coverage • User indicates orients when automatic tiling is acceptable

8. Next Steps • Explore exception handling • Handle tiles with inadequate guide star availability • Avoid any user-specified sky points • Develop engineering concept • Challenging for long range plan (LRP) to handle targets (tiles) with RA and Dec that change with time and jump when tile configuration changes. • Send comments to Valenti, Blair, Soderblom, ...