Use Case: Observing Preparation: Set Up to Observe a Solar System object: close comet which requires mosaic observations with multiple spectral lines.

This ObsPrep usage scenario is based on the SSR Use Case 4.7.2 (Setup Multi-Field) from the SSR memo 11 (ALMA-SW-0011). It should not be considered as a replacement of the UCs in the SSR Memo 11. It has been developed to aid in testing the ability of the design of the OT to support the specific case of the described observation setup.

Goal:   Define a program using the ALMA observing tool to set up observations of a solar system object, specifically, a close comet that requires multi-field mosaic, multiple spectral lines. The program is time critical.

Contact Authors:   D. Shepherd, P. Palmer, & L. Testi

Role(s)/Actor(s):
Primary:   The observer (follows the basic course for this UseCase)
Secondaries:  
  Observing Preparation Tool
  Spectral Line Catalogs
  Source Catalogues and Databases
  DSS/2MASS Image Library
  Local User Resources (2-body Ephemeris on local disk)

Priority:Critical

Performance:   Response to user inputs in near real time.

Frequency of Use:   Comets are expected to to come close to the Earth (within 0.1 AU) about 5 times/century these require large field mosaics with time-critical observations.

Note: Other large Solar system objects that are not as time-critical include planets, moons, & main belt asteroids (Solar observation setup will be covered in a different set of Use Cases). Thus, one can expect Solar system observations to be scheduled routinely with occasional time-critical setups for comet and near-Earth asteroid observations.

Preconditions:

1. Proposal written by PI and submitted to ALMA TAC.
• Note: the PI may need to be able to verify and insert in the program time critical (configuration hardware availability) information for their own information and TAC review (e.g. if the array is in Y+ when the observations should be done in the compact array. The tool should return an error if the time critical observations are not compatible with the observatory characteristics for that particular call for proposal).
2. Project approved by the TAC for ALMA observations and ready for phase 2.
3. Project goals and constraints are:
   
   • Primary Science Goals:
     Image outflowing gas (as many molecular lines as possible, e.g. HCO+, H2CO, HCN, CO) in a comet coma and continuum emission from the comet nucleus. The mosaic should cover the coma region and must be sensitive to size scales between 1" and 140" in the outflowing gas (e.g., total power and short spacings are critical). The molecular lines require the same velocity resolution (since the line widths are determined by the outflow speed). It is critical to get as many spectral lines as possible since there may only be a 1 day window of opportunity when the comet will be available. Continuum emission is considered of secondary importance. It should be possible to achieve a S/N of 10 with ~ 2 GHz bandwidth. The nucleus will likely be unresolved (<= 15 mas diameter) and will be used to detect the comet core (provides astrometry information) and a faint warm dust halo surrounding the core. Known comet distances from Earth range from 0.015 to 6 AU, the most likely close approach distance will range from 0.5 to 2 AU. Here, assume a comet like Hykutake that came to within about 0.1 AU of the Earth because this produces the most stringent requirements for ALMA.
   • Primary Science Constraints :
     - Spatial Resolution <= 1 arcsec (727 km @ 1 AU). The nucleus will have a radius of about 1 km (14 mas), the coma about 10^4 km (138").
     - Mosaic region needs to be about 5'x5', ACA and equally sensitive Total Power observations should be done simultaneously (coma structure may change rapidly).
     - Spectral Resolution <= 0.1 km/s (to resolve the velocity pattern).
     - Range of Spatial Scales = 1 to 140 arcsec.
     - Line RMS <= 1 mJy/beam/channel (to find faint coma features).
     - Continuum RMS <= 0.01 mJy/beam
     

Basic Course:   Set up for Observations (User steps and OT responses)

NOTE: All steps in the Basic Course should be able to be saved in the micro-archive or as stand-alone disk file these can be saved & reloaded for later processing and/or share between different Co-I (e.g. via e-mail exchange).

1. Select Project Type:
   Choose Solar System Imaging; Spectroscopy:
   
   • Near-field corrections will (should) be made on line, this step specifies that this project will require them.
   • General relativity corrections for the actual 3D path will (should) be made on-line (If distance is beyond the Solar system, then 2D assumption is OK, but, in the Solar System the maximum light deflection ~1" at the limb of the sun).
   • The OT responds with a query: "Do you want to use the on-line major body ephemerides (planets), or up-load your own?"
   • The user will select the up-load option.
   • The OT waits for the input of a 2-body ephemeris (6 orbital elements) to calculate position and velocity as a function of time. Line velocities should be tracked in the 'cometocentric' velocity frame (e.g. correct for comet motion using ephemeris and diurnal rotation of the Earth).
     • Currently, most PIs obtain small ephemeris files (consisting of 6 orbital elements) from JPL's on-line Horizon System. Some PIs make their own ephemeris, choosing what data goes into the orbital element calculation. Either way, the format of the file should be the same.
     • ALMA should define a standard up-load format, either the format currently obtain from the Horizon System or some other simple text format.
2. Specify target name
3. Specify time constraints in terms of range over which this observation can be made.
   Note: time constraint input should be flexible since one can sometimes observe a comet before and after perihelion. Another example (although not directly applicable to this Use Case): suppose that you want to observe the satellite of Neptune at maximum elongation, this is possible every few days, which can be determined. Then your time constraints will be to observe one of these days, without specifying the exact one, the scheduler will choose one assuming that the program has high enough priority at any given allowed time window.
   • If time editor constraints are incompatible with hardware (array not available, array in wrong config, receiver not available etc..) then issue an error.
4. Upload 2-body ephemeris:
• OT reads ephemeris elements.
• OT calculates position and velocity predicted for the time of the observation and displays these values to the PI.
5. Select the Lines. Use one or more selection methods:
   
   • Name
   • Catalog
   • Pull-down-menu
   • Frequency/Wavelength specifications
   If more than one frequency tuning is required, specify time constraints for second frequency band (e.g. observations must be done in consecutive order or the next day over the same time range to match RA range and uv-coverage). 
6. Define Area to be mapped:
   • Specify size of the mosaic. Since coordinates will change when a new ephemeris is uploaded at the last minute, the mosaic should be specified in terms of total size centered on the position calculated from the ephemeris:
7. Select shape (circle, ellipse, rectangle, polygon) & size (5' x 5').
• Specify optimal sampling of fields (just less than Nyquist sampling) or user-supplied sample spacing. OT should provide a warning if user-supplied sample spacing is less than optimal and an estimation of image degradation due to sampling.
8. View the mosaic field displayed on a DSS/2MASS if available. Also view the mosaic against a 6cm continuum image supplied from the user's local directory (supplied image will be in fits format with compatible header).
   OT provides proposed layout of fields overlayed on images (DSS/2MASS/VLA) and shows primary beam on the images.
• N.B. It may not be easy to do this if the thing moves and the time window is complex.
9. Enter Spatial Resolution and Range of Scales:
   The OT should give feedback that the ACA and total power observations are required. The user should be able to change the parameters and have immediate feedback. Multi-field/ACA/TP should be needed for this mosaic.
10. The OT compares time constraints with available configurations. If the configuration does not meet resolution specifications (e.g., it is too extended), the OT reports that the PI has 3 choices:
    • Observations can be done with the full ALMA array and the ACA+TP separately. In this case, the OT will notify the PI that the ALMA interferometer data cannot be combined with the ACA/TP data in post-processing. This will probably always be the choice because detecting the nucleus position (which will be unresolved in any ALMA configuration) is so important. Accurate positions of the nucleus will track the effects of non-gravitational forces which are important for ephemeris updates and as inputs to models.
    • Observations can be done with a subset of the shortest baseline elements to improve sensitivity even though the resolution will be too high (after all, the data can be tapered in post-processing even though overlap in uv-coverage between ACA and ALMA array will not be optimal). Note: if the probability of photodissociation by Solar UV radiation is high for a given molecular species, then the corresponding size-scale for that molecule will be small. Thus, having increased (but not full) resolution from an intermediate-size array configuration may be advantageous.
    • Observations can be done with ACA and Total Power antennas only. OT provides the PI with corresponding limitations in spatial resolution and any hits on sensitivity that will occur. OT requests that PI verifies this down-scoping of the project constraints.
    N.B. This can, and should, be done at Phase I!
11. Enter Spectral Resolution/Bandwidth:
    
    • All lines should be at the same resolution and bandwidth (FWHM of all lines is determined by outflow speed). User should be able to select a single resolution/bandwidth and apply this to all lines chosen.
    • The OT should provide a warning if more than one correlator setup is required to match the desired bandwidth at the requested resolution.
    The OT provides feedback: total bandwidth of the spectral window at the selected resolution.
    All other correlator bands are set to continuum observations with maximum bandwidth. OT reports on what the final continuum coverage will be (frequency range & total bandwidth). PI will have to option of changing line selections to achieve frequency coverage and bandwidth desired for the continuum.
12. Enter Required RMS desired in Line or Continuum:
    The OT provides feedback on the total on-source time required and displays the corresponding RMS in the other case (continuum if one specifies line and vice-versa), it should be possible to change which of the two the user sets, reset the value and get immediate feedback.
13. Set Up the Correlator with the following steps:
    • The OT shows a template spectrum around the selected lines. It should be possible to switch between the "Orion hot core" template and/or other astronomical templates, a schematic view based on a line list, and a user spectrum (ASCII file with nu and intensities, can be theoretical or observed).
    • The user zooms in on the line of interest with a click, adjusts the band center to cover all the line components that the user can/wish given the available bandwidth of the spectral window.
    • The user zooms out for other possible lines of interest.
    • The user adjusts LO freq in order to cover the lines of interest.
      Note: The primary line can slip out of the originally selected correlator window domain and into another correlator window. The OT should be sure that the line is covered and not allow the user to select an LO frequency that prevents the observation of the primary line. The OT should be able to switch between correlator bands to ensure that the line is always covered with the required bandwidth/resolution.
    • The user should be able to zoom in on lines of interest and modify correlator bands to set resolution and bandwidth for these. The OT should update the continuum sensitivity for the bands that are subtracted from continuum to observe lines and should show the expected sensitivity in the "new" spectral bands in the given amount of integration time.
    • Low Priority: The user may want to select as "bad" some ranges (channels) of the continuum bands in order to avoid strong lines in the pipeline processed continuum image.
14. The user reviews the default calibration choices:
    • The OT can be required to show the calibration choices (calibrator, calibration options, integration times, duration of observing cycles, etc...).
    • The advanced user can change the (allowed) parameters and receive warnings/feedback on the expected calibration accuracy.
15. Required Feedback (TDB on where and when this feedback should be provided to the user):
    • Beam information (expected beam ellipticity and axes)
    • Total duration relative to input time constraints.
    • Weather constraints - stringency and likelihood to achieve.
    • Configurations required - availability and timescales.
    • Warnings related to data quality (due to calibration scheme chosen).
    • Map sizes, data rate, total data volume.
    • Scheduling Block breakdown.
    • Notification of the latest possible time(s) for which a new ephemeris must be provided and new SBs submitted to the archive.

Postconditions:

1. User saves the observing setup on their local machine. It should be possible to save the project in the OT local micro-Archive or as an external file to share the work with other CoIs (via e-mail). The actual scheduling blocks (SBs) should also be saved to the local directory if desired by the user. Note: the 'saved file' for the OT and the SBs can be the same thing.
2. The user requests that the program and associated SBs are validated.
3. If validated, User submits the complete program and associated SBs from OT.
4. Just before observations are to begin, the user uploads a more recent ephemeris to the Archive. The Archive must be able to generate new SBs with corrected positions and velocities. The SB should contain the necessary information for the scheduler to figure out the coordinates (RA,Dec,vel) at any given time, through reference to the new Ephemerides file.

Issues to be Determined or Resolved:

1. Required feedback listed in point 15 of the Basic Course above.
2. If the array is in the A+ configuration and only ACA and total power is available, how will this be handled? Will the PI be allowed to specify all or part of the array anyway?
3. ALMA should define a standard up-load format for ephemeris files, either the format currently obtain from JPL's Horizon System or some other simple text format.
4. How will ephemeris upload just before observations be handled? (upload ephemeris and let Archive or OT generate new SBs or have the user retrieve the SBs, update them with new ephemeris, and re-submit to the Archive).

Notes:   The relevant UCs from SSR Memo 11 are: 4.1 (Observe with ALMA), 4.2.1 (Create Observing Program), 4.2.2 (Create Observing Proposal), 4.2.3 (Validate Observing Program), 4.2.6 (Create Scheduling Blocks), 4.2.8 (Submit Scheduling Blocks), and for the specific observing mode described above: 4.7.2 (Setup Multi-Field).

Last modified: 23sep03