OPTMODE sets the optimization mode. The valid modes are:
The usual way to use this mode is to specify a loop containing all the desired sources (and frequencies etc.) and lasting longer than the desired total time. Then the optimization will pick the scans that make sense and will quit after OPDUR. This mode is especially useful for scheduling pointing observations.
There is a trick available, triggered by OPSKIP, that is an attempt to emphasize scans in desirable elevation ranges (set by OPELPRIO. If a loop is used, this will cause scans to be skipped OPSKIP times before they are used again unless they are in the desired elevation ranges.
There is another trick to give low priority to some scans using OPMISS. The current scan will only be accepted if at least OPMISS preceeding scans in a row have been missed. If, for example, you have a loop of scans, as is typical in pointing schedules, and you have one that you only want to have used if all others are unacceptable (eg too low), then set OPMISS to the length of the loop.
This mode is an attempt to provide a mechanism for scheduling geodetic type observations. Parameters OPMINANT, OPMINEL, OPDUR, and OPNOSUB have the same meanings for CELLS mode as for SCANS. The CSUB mode is able to do almost the same thing as this mode plus it handles subarraying. It may eventually completely replace the CELLS mode.
Like the CELLS mode, this mode is for geodetic type observations. Various parameters have the same meaning here as for the other modes except that OPNOSUB is not allowed since it doesn't make sense. Also, OPMINANT is a goal. The third subarray can have less as can one of the other two under certain very special circumstances.
OPTMODE=HAS should not be used to schedule projects longer than 24 hours. In that case, hour angles can be ambiguous. Note that for normal schedules the 4 minute difference between the sidereal and solar days will not be important partly because only scan start times are considered. However there is just a chance of weird behavior for an observation of 24 hours UT duration and short scans.
There are a number of input parameters to help guide the HAS mode in it's selection of scans. Important parameter include OPDUR, which sets the total length of the observations, OPMINANT, which sets the minimum number of stations that must be up for a scan to be chosen and OPMINEL, which sets the minimum elevation a station must be above to be considered to be up. Note that to be considered to be up, a station must also be above the local horizon as specified in the station catalog.
OPHASTA sets the reference station for this mode. This is the station at which the hour angles will be measured. Either the full name or the station code, if unique, can be used. OPHA sets the desired hour angle (at the reference station) for this scan. OPHAWID sets a normalization time interval relative to the desired hour angle over which the scan weight increases. OPHAWT is a normalization factor for weights related to time offset from the desired hour angle. This and other weight normalization factors mentioned below help adjust the relative importance of the different factors such as offset from the desired time, slew time, and proximity to other scans on the same source. OPHASTA is used to set the station for which the desired hour angles apply. OPMINSEP sets the minimum separation of scans on a source as a fraction of the spacing of scans that would be used if they were spread evenly across the available time for that source. OPSLEWTI and OPSLEWWT set the reference time and the normalization factor for the weights related to slew time. The slew weight is OPSLEWWT * ( 1 - (slew time))/OPSLEWTI). OPHLIMTI and OPHLIMWT set a similar normalization and weight for the proximity to the extreme times at which a source can be observed. This latter is used to encourage a scan on the source, for example, before it sets. OPHMAXDT sets the maximum deviation from the desired hour angle at which a scan will be considered. This prevents using very inappropriate scans when no other scans are available. Most of the above parameter can have different values for different scans.
The equations for the various weights are given in the descriptions for the parameters OPHA, OPSLEWTI, and OPHLIMTI. For the most accurate information on how weights are set, look at the code in $SCHED/src/Sched/opthas.f.
When the HAS mode is used, a lot of information from the guts of the algorithm can appear in the sched.runlog depending on the setting of the parameter OPPRTLEV. For each output scan, some details of the weights etc for each possible choice from among the input scans are given (OPPRTLEV=3) or just a summary for the scan can be given (OPPRTLEV=2 or higher). At the end, for OPPRTLEV=1 or higher, the properties (like available observing time) and fate of each input scan are given in a table. Also a number of summary parameters are given for any OPPRTLEV. All this information, while bulky, should help a user figure out how to drive the program -- how to set set the related input parameters. But beware that, for OPPRTLEV=3, the sched.runlog can be very large.
While constructing a schedule using this mode, it is very useful to use the plotting capability of SCHED. The UPTIME and UV Plot capabilities are especially useful in understanding what you have. Also note that when SCHED runs, it creates an output file with the extension .sch that could be used as the scan input section for another run of SCHED. So if the optimization mode comes close, but you wish to make a small change, it is possible. This is an old but little used capability and has not actually received any maintenance for a long time as of late 2005.
In its early form, the HAS mode is meant to be useful particularly for scheduling surveys. But at the moment, there is no way to associate scans so it would be difficult to use it for phase referencing. Also it would be awkward to use to schedule blocks of scans around the sky for atmospheric solutions (for aips task DELZN). These limitations should be removed in future versions.
In some optimizing modes, SCHED will not schedule a scan that crosses 0 hr UT. This is also used to be true for dwell time scheduling, but it no longer seems to be useful -- downstream processing doesn't trip over such scans.
Note that the optimization modes are somewhat experimental. If they are used, the output schedule should be checked carefully.