Use Case: Observing Preparation: Set Up to Observe a Solar System object: quiet Sun observations using OTF mapping

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, OTF mapping observations of the quiet Sun. The program can be time critical.

Contact Authors:   D. Shepherd, T. Bastian

Role(s)/Actor(s):
Primary:   The observer (follows the basic course for this UseCase)
Secondaries:  
  Observing Preparation Tool
  Real time solar images (ground and space based)
  Online solar ephemeris

Priority: Critical

Performance: Response to user inputs in near real time.

Frequency of Use: If VLA solar use is any guide, roughly 2-3% of the observing time will be devoted to the Sun. Unlike the VLA case, proposal pressure will not be as strongly modulated by the 11 yr solar cycle. It will likely strongly favor the compact ALMA configurations, however. Therefore, the frequency of use could be a factor of 2-3 higher in the compact configurations than the nominal 2-3%.  

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 the most extended configuration 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 the solar chromosphere in one or more continuum bands using OTF mapping. While user motivations and goals will vary, it is likely that most will want to map an area on a cadence that resolves the 3 min chromospheric oscillations. My understanding of antenna slew rates suggests that one cannot map an angular area larger than about 3' x 4' at 345 GHz. This assumes that the rastering samples the beam 3 times (therefore somewhat oversampled relative to Nyquist) and that the slew rate is 0.5 deg/sec. I also assume a maximum sampling rate of 48 msec/sample. I have not allowed much for turning the antenna at the end of each raster but the acceleration specification is fast: 12 deg/sec/sec. I have not allowed for calibration overhead. These numbers therefore yield 1 min/map. The maximum map area scales inversely with frequency. The maximum map size also scales inversely with map cadence. Certain experiments will want to map on the limb of the Sun.
     
   • Primary Science Constraints :
     - Spatial Resolution: > 0.2"
     - OTF mapping regions: see above
     - Spectral Resolution: continuum
     - Range of Spatial Scales: ang resolution to entire map size
     - Continuum RMS: depends on  program; a single OTF map obtained as above would have an rms of roughly 240 K/beam at 345 MHz
     

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; continuum
   
   • 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 
   • 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 on-line option.
2. Specify solar target name
3. Specify time constraints in terms of range over which this observation can be made.
   • If time editor constraints are incompatible with hardware (array not available, array in wrong config, receiver not available etc..) then issue an error.
4. Define Area to be mapped:
   • Specify size and shape of the OTF map
   • Specify offset position of OTF map relative to disk center Note: raster points will need to be corrected for solar rotation on the fly or post facto
   • Specify required mapping cadence
   • Specify required map RMS
   • Note: map size, cadence, and RMS are coupled and must be optimized to meet user requirements
     
5. View the OTF mapping field displayed on user-selected real time images (e.g., SOLIS H-alpha and magnetogram). 
6. Enter Spatial Resolution and Range of Scales: quiet Sun observing will usually require Total Power and ACA observations.
7. The OT compares time constraints with available configurations.
8. Maximum continuum bandwidth assumed.
9. Enter Required RMS desired in Line or Continuum: see above
10. 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. Calibration is TBD at this point.
11. 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.

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.

Issues to be Determined or Resolved:

1. Interaction of OTF mapping and calibration 
2. Use of subarrays desirable (both ALMA and ACA!)

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: 14 Oct 03