Summary

This document has shown that observing files generated as a collection of setups frees the observer to think of the observations themselves rather than the mechanics of observing. The few commands necessary to handle setups free up the observer to think of the observations needed for a source rather than the individual commands necessary to achieve them.

At the simplist level, the user plans their observing file in the following way:

  1. Define the characteristics of one observation of a source and put these qualities into a setup command.
  2. Define the setups for the other sources. The setup definitions should, in general, be the first commands in a user's script.
  3. Call the scan and loop commands with the defined setups as arguments. Perhaps, as needed, multiple setups can be logically combined.
  4. Add relative stop times, as needed, to the loop and scan commands to insure that all observations will finish properly by the project stopping time. Remember, no script will be allowed to continue beyond the project stop time. The best way to insure this is to specify the stop keywords of the loop and scan commands as a time relative to the project stop time.
  5. While in checker, run the project command with this observing file as its argument to insure that the script runs as expected.

Another point to consider is that all observers plan their observations based on a desired time range. Invariably, the actual time range assigned by the observing schedule will be different. The observing script that the user writes should be flexible enough to handle this situation. The use of relative times provides the user with a powerful and easy way to control the flow of their script without necessarily knowing the absolute stopping time of their project. Where the user should take additional care in preparing their scripts is to insure that observations do not begin too early. This is done both by specifying (in the comment section at the top of the script) the acceptable LST time ranges of the project and by specifying an absolute start time (the start keyword) to the first scan or loop commands. This is illustrated in each of the examples that follow.

The only drawback to using the start keyword is that the script will just wait around for the start time to be reached if the command is executed too early. Perhaps a better approach might be to observe calibrator setups until the specified start time is reached. For example, if the user did not want to begin the main loop until at least 15:00 LST and had a single calibrator with the setup name 3c273, the command 

loop calsetup=3c273 stop=1500
placed before the main loop would insure that the main loop would not be started until at least 15:00 LST and would observe (repetitively) the calibrator until that time. If this example command was called and the time was beyond 15:00 LST, it would be ignored.
(up to Document Overview, back to Questions About Constructing Observing Files, on to Example Scripts)
James Morgan
 [an error occurred while processing this directive]
Page last modified: Thursday, 17-Mar-2016 13:48:30 EDT.