3. Scheduling Data

3. Scheduling Data

3.1. Introduction

Before your project can be run on the GBT, the Dynamic Scheduling System (DSS) needs a certain amount of information to determine if your project’s sessions can be run. Below is a complete list of information, broken into multiple sections, depending upon whether the information is consistent throughout the entire project (and needs only be entered once) or if it is specific to each session (and must be entered individually for the sessions). Here is also listed the information needed for fixed and windowed sessions, as well as any data which will filled in and used by the DSS without need for the investigator’s input. Finally, the Table provides a complete list of all data used by the DSS for scheduling the various project sessions.

Note that at this point no information as to how to enter this data is being provided, as those mechanisms are still being developed.

3.2. Data Entered by Investigators

All of the items in this section should be entered by the project investigators before the project is submitted for refereeing. This information cannot be changed by the project investigators without consent from the GBT scheduler. This information is broken into two distinct parts - information which is relevant to the entire project and information which is relevant to individual sessions.

3.2.1. Project Data

3.2.1.1. Thesis?

Is this project part of a doctoral thesis for one or more of the project investigators?

3.2.1.2. Proposal Contact

Who is the primary contact for the proposal? By default this is the project principal investigator.

3.2.1.3. Total Project Time

The total time allocated to the project. Often this is equal to the total time proposed for the project, though it may be amended by the proposal selection committee or the GBT telescope scheduler.

3.2.2. General Session Data

3.2.2.1. Time Dependent Data

3.2.2.1.1. LST or UT Range

What is the LST or UT range for the session? UT range should be given only in the cases where the session is not dependant on celestial coordinates, or if it is fixed in time due to other constraints (e.g. a maintenance session or a collaboration with another telescope).

The LST range should be determined based off the celestial coordinates of the source, the atmospheric opacity at the desired frequency, and the elevation at which the observations become efficient. Practical observations are not confined to source transit. As the absolute hour angle |HA| increases away from transit, atmospheric efficiency falls, first slowly and then rapidly to unacceptably low values. The hour-angle limits of an observation can be defined in terms of the efficiency relative to the efficiency at transit. A reasonable hour-angle limit could be defined as the hour angle at which the efficiency is half the transit efficiency.

Figure: Absolute hour-angle limits at which the observing efficiency is half the transit observing efficiency for good weather conditions (solid curves). These limits do not increase much even under the best weather conditions (dotted curves). Likewise, relaxing the atmospheric efficiency criterion (from 0.5 to 0.25 for example) does not significantly widen these hour-angle limits. Abscissa: Frequency (GHz). Ordinate: Absolute hour angle (h). Parameter: Source declination (delta - deg). Figure is from Dynamic Scheduling Project Note 2.

See the DSS Note 2 (http://wiki.gb.nrao.edu/bin/view/Dynamic/DynamicProjectNotes) for further details on this constraint.

3.2.2.1.2. Total Session Time

This is the total time for a given session. A session cannot run be scheduled for more than this time. Note that this is the total time allocated for the project by the Proposal Selection Committee (PSC) and is not necessarily equal to the sum of the time the investigators give to their sessions. That is, if a project has 20 sessions and chooses to give each session a maximum time of 10 hours, yet the PSC has awarded the project only 100 hours total, the project will be run until the 100 hours has been used, resulting at least some of the various project sessions getting less than the desired 20 hours.

3.2.2.1.3. Minimum Time

A session has a minimum and maximum time associated with it. The minimum time defines the smallest amount of time the observer feels is useful for observing, and will be the smallest amount of time for which the DSS will allow a segment for the session to be scheduled. Note that the DSS will, of course, attempt to make a longer Telescope Period for the project and session, but due to the difficulty in scheduling the telescope it is conceivable that a session will be scheduled for only its minimum time. If left unstated, the minimum time will default to 2 hours.

Best use examples of minimum time include:

If a pulsar investigator needs to observe a pulsar for 8 consecutive hours to correctly obtain the pulsar(s) orbit parameters, the minimum time for a session segment will be 8 hours plus the time needed for overhead (e.g. 8.5 hours or so).
If a spectral line investigator wishes to make 100 repeated frequency switched observations of an object, where each frequency switched observation is only 10 minutes long, the investigator could make the project session's minimum time 10 minutes + overhead. In this case, though, even though the project's set-up time would likely only be 3-5 minutes, it probably would not make much sense for the investigator to ask for a 15 minutes minimum, as the investigator could (although hopefully would not) end up with numerous 15 minute slots on the telescope, thereby eating much of the project's total time in overhead. Instead a sensible minimum time might be 30 minutes or 1 hour.

3.2.2.1.4. Maximum Time

A session has a maximum time associated with it as well. The maximum time for that session defines the longest period of time in the LST/UT range for which a session segment will be scheduled (that is, it will define the longest session segment allowed). The purpose of this definition is to allow for observers to readily break their (non-fixed or windowed time) project into multiple session segments. Unlike fixed and windowed sessions, the maximum time parameter does not offer any information as to when the next session segment will be scheduled, except that it will not be scheduled until the LST range for the session begins again.

Best use examples of maximum time include:

An investigator wishes to make multiple (10) maps of an astronomical object, where each map is made in azimuth and elevation and takes 2 hours to run (including overhead). To add complication, though, they would like to randomly choose the azimuth and elevation range over which the maps are made. To accomplish this task, the investigator may wish to make no more than 1 map in a given 24 hour period. In this case, the session segments would have a minimum time of 2 hours (to insure a full map was made) and a maximum time of 2 hours (to insure no more than 1 map is made).
Another pulsar-pulsar pair is found. The investigators wish to determine the full orbital parameters of the system. The investigators knows (from preliminary observations) that no orbital or spin period is greater than 4 hours, nor less than 2 hours, but they do not know at what precise time the orbital period starts. Also, though, the investigators wish to observe this system on different days to see if the pulse signal is varying with time. In this case the session segments would be defined so that the minimum time is 2 hours and the maximum time is approximately 4 hours (with set-up time and some fudge factors included, the minimum time might be more like 2.5 hours and the maximum time might be more like 5 hours).

3.2.2.1.5. Time Between

A session can have both a minimum and maximum time associated with it, and a time between parameter which will set the length of time which must pass before the session can be rescheduled on the telescope. The time between is measured from the start of a session segment on the telescope to the start of the next session segment. That is, if a session segment runs for 4 hours, starts at 8hrs LST, and has a time between of 10 hours, then the earliest the next session segment can be scheduled is at 8hrs + 10 hrs or 18 hrs LST.

This can be useful in the case where, e.g. someone might wish to have at least a week between making maps on an object in order to properly process the maps, so that decisions can be made before the next observations regarding the map's parameters. (In this case the time between would be set to 7 days.)

The default time between will be zero. This means that even if a session has a maximum time associated with it, if the time between is left at 0, the next TP with a session could begin as soon as the last TP of that session ends, provided the LST/UT and other parameters allow for it. E.g. if a session has 16 total hours remaining to it, and has a minimum time of 4 hours, a maximum time of 8 hours, but a time between of 0 hours, it’s feasible that the project run for 8 hours and then immediately start a new TP of 4 (or even 8) hours without any break.

As a second example, again assume a session has 16 total hours remaining to it, and has a minimum time of 4 hours, a maximum time of 8 hours, but a time between of 24 hours. In this case, assume the project runs for 4 hours within a TP. Here, even though the maximum time is 8 hours, after completing its 4 hour TP the project will not be run until 24 hours have passed.

3.2.2.2. Time of Day (Night, Work, or Any)

This parameter sets the time at which a session can be scheduled. For consistency, the session should complete before its defined time of day ends. That is, if a session is assigned to day time, which may end at 4:30pm, that session must end by 4:30pm.

Night here is defined according to the GBT Precision Telescope Control System (PTCS) Project. Differential heating and cooling of the telescope alters the surface of the telescope, resulting in degradation of telescope efficiencies, and 'bends' the telescope, resulting in pointing changes. At high frequencies, these affects can be important - see http://wiki.gb.nrao.edu/bin/view/PTCS/WebHome for the most up-to-date information on the surface accuracy. Low frequency observers may want to consider night time observing for two reasons. RFI is usually lower at night; and, in some cases, the sun has a slight negative impact on baseline shapes. As the PTCS project improves the telescope’s ability to compensate for these changes, the recommendation as to what frequencies should be observed only at nighttime will increase. To remain consistent with the PTCS definition, night is defined in the DSS as (sunset + 3 hours) to (sunrise - 2 hours).

Work is defined as the Green Bank work day, which runs from 8:00am-4:30pm in the winter months and 7am-5:30pm in the summer months.

Any allows for sessions to be scheduled at any time during the day or night.

3.2.2.3. Weather Dependent Data

3.2.2.3.1. Canonical Frequency

This is a representative frequency for the session. It will not be used for configuring the telescope hardware. Instead, it will allow the DSS to determine both if the hardware is available to configure the telescope for the session and observing efficiency (see Project note 2 and below for more information).

3.2.2.3.2. Canonical Declination

This is a representative declination for the session. It is used solely for the purposes of determining the observing efficiency for the observations. (See below for further information.)

3.2.2.3.3. Maximum Wind Speed

This is the maximum wind speed which the observer can tolerate. This needs to be filled in better once Dana has completed determining what measure of wind speed to use. Again, it would be useful to have a readily available tool to allow the user to determine the wind speed he/she wants. Alternatively, we could have people enter numbers in terms of pointing errors and convert the numbers ourselves.

3.2.2.3.4. Minimum Atmospheric Efficiency

This is the minimum transit observing efficiency which the session can tolerate. A session is run if $\eta_{atm} \ge \eta_{min}$ . $\eta$ is defined as

$\eta_{atm}=\left[{{e^{-\tau}} / {e^{-\tau_{min}}}\right]^2 \left({{T_{sys,min}} / {T_{sys\right}}})$

Here, the “min” indicates the minimum possible value of each parameter. $\tau$ is the optical depth, approximated by the DSS to be $\tau = \tau_{z} \sec{z}$ where $\tau_{z}$ is the zenith optical depth and sec(z) is the “air mass” given by $z\;=\;\arccos\left({\sin{\phi}\sin{\delta} + \cos{\phi}\cos{\delta}\cos{H}}\right)$ . $\phi \approx \; +38^\circ\;28^\prime\;\sim+0.6681 rad$ is the latitude of the GBT, $\delta$ is the canonical declination of the session (see above). $H = (LST - \alpha)$ is the hour angle of the source at right ascension $\alpha$ , and is set to 0 at transit (for calculating $\tau_{min}$ and $T_{sys,min}$ ). need to add in how tau is calculated

Typically $\eta_{min}$ is set to 0.5 to insure reasonable observing efficiency. See Dynamic Scheduling Project Note 2 for further information on these parameters.

3.2.3. Fixed/Windowed Session Data

There are three different types of sessions which can be scheduled: fixed sessions, windowed sessions, and sessions which can be run at any time (subject to the other constraints listed in here).

3.2.3.1. Fixed Sessions

A fixed session must be executed at a certain time and date and cannot be dynamically scheduled. As a result, these sessions constitute the "classic" part of the GBT's scheduling system. Examples of fixed sessions include radar runs and non-dynamically scheduled VLBI runs. Fixed time sessions do not repeat. Any project which wishes to have more than one fixed time session must make a new session for each time/date the project is going to run. The only extra data associated with the fixed time sessions is the start date

3.2.3.1.1. Start Date

This is the date and time at which the session must start.

3.2.3.2. Windowed Sessions

A windowed session is a session which must be run within a given period of time, but not necessarily on an exact date. These are sessions often need to be repeated.

Note that for windowed sessions the number of repeats one has is dependent on the minimum/maximum time parameters and the total project time. That is, the total number of repeats for a windowed session is equal to (the total allocated project time)/(time for each session). If an investigator wishes to ensure a set number of repeats for his project, then he should set the minimum and maximum time parameters to be equal to the time needed to insure this number of repeats. As an example, if a monitoring project wished to run every month for one year and has a total allocated time for the project of 24 hours, then the minimum and maximum time for the sessions should both be set to two hours.

Examples of windowed sessions include:

Monitor Project: a water maser observation which must be observed sometime during the first week of every month. A window is assigned for 1-7 Jan, 1-7 Feb, 1-7 March, etc. The project can be observed on any of these days between the hours of 8-12 when their source is visible. If they are not scheduled on days 1-6 then the window converts to a fixed time for day 7.
Maintenance Day: An 8 hour maintenance day, running (in this case) from 8 AM to 4 PM, and which must occur between Monday and Wednesday for a given week. If this activity has not been scheduled by Tuesday, then it becomes a fixed time session for Wednesday.
PF Receiver Change: This activity must take place between 8 AM and 6 PM on a given day, and will take at least 2 hours to successfully complete. If this activity has not started by at least 4 PM, it becomes a fixed time session for 4 - 6 PM.
Cometary observations: These would need to be scheduled on the day(s) the comet passes through the sky, but may not need to be on any specific day or time during that transit.

The only additional information needed for windowed sessions is start date and window length.

3.2.3.2.1. Start Date

This is the date on which the window should start. The entry should be filled out only if the start date is important. That is, if the project is to observe a comet for 4 hours while it transits overhead between August 10-15, the start date should be August 10. However if the observer does not care when the project starts, provided the he obtains data on his pulsar every 30 days, the start date should be left blank.

3.2.3.2.2. Window Length

This is the length of time for which a window will run. In the previous example, the comet observations would have a window length of 5 days while the pulsar observation has a window length of 30 days. Note that this can be an integer or fractional number.

3.2.3.3. Other Data

3.2.3.3.1. Session Priority

This is a flag which can be set by the investigator to prevent a session from being considered by the DSS. It is useful in the cases where an observer may wish to run a given set of sessions before a different set is executed, e.g. in the case where observations of object X must be made before object Y is observed.

3.2.3.3.2. Solar Avoidance

The working definition of solar avoidance is to remain at least 30 degrees from the sun. While this is not a perfect definition – the actual shape of the solar avoidance cone is frequency (and receiver) dependant, this definition should suffice.

3.3. Ancillary Data Entered by Investigators

This information can be changed at any time and is not subject to review by the PSC and/or GBT telescope scheduler.

3.3.1. Project Data (Contact and Availability Information)

3.3.1.1. Observing Contact(s)

This is the name(s) of all persons whom will be running the projects observations and is the complete list of people whom the telescope operator can contact when a session is to be run. Note that if a person is on this list, he/she needs to either be an approved GBT remote observer or that person should be onsite. If the person is onsite and staff help was requested (in the proposal process) the GBT operator will also contact the on-duty telescope support scientist to help the observer.

3.3.1.2. Observer on site date

These are the dates on which an observer will be present in Green Bank. The DSS will use this information in two ways. First, the observer’s presence will be weighed into the selection criteria for determining which project should be run next. Second, it will provide the telescope operator with information regarding both which observer to contact (the person on site would always be the preferred observer) and where to contact the person.

3.3.1.3. Observer unavailable dates

These are the dates and times for which a person is unavailable for observing. As the probability for a project being observed increases, so does the importance of keeping this information completely up-to-date. In the broadest terms, this can simply be a list of when the observer knows she will not be able to observer (e.g. the observer might be on vacation from 14-21 July and so will mark those down). But if there is a high probability of a session for the observer’s project being run, the observer should include more detailed information (e.g. if the observer teaches class from 2-4pm every Tuesday and Thursday that fact should also be included here).

Having incorrect availability dates will lead to considerable frustration by the GBT telescope operator as he or she repeatedly fails in reaching the observer and could result in something more dire.

3.3.1.4. Observer contact information

This is a listing of all means possible to contact the project’s observer(s). It should include all possible means of communication (email(s), work phone, home phone, cell phone, etc) and should indicate the preferred communication method for notification of a session being scheduled as well as general communications regarding project status. Note that observers should also include any temporary phone numbers in the list, as well as when they are valid (e.g. I will be at phone 111-222-3333 from 9-11pm June 4), particularly in the case where there is a high probability of a project’s session(s) being run.

3.3.2. Session Data (Hardware configurations)

All of the information in this section relates to the hardware configuration for the session. It is used by the DSS to determine both if the needed hardware is healthy and if a signal can be properly routed for the session. An up-to-date and detailed listing of the options is given in the GBT User’s Manual (http://www.gb.nrao.edu/gbtprops/man/GBTpg ).

3.3.2.1. Observing Mode

The four choices here are: spectral line, continuum, pulsar, or other.

3.3.2.2. Backend(s)

This is a complete listing of all backends being used by the session. This is a list only of the required backends, and not the desired backends, as the DSS will not let a session run unless the listed backend(s) are in good health and a signal can be routed to them. This means that if an observer wishes to use, e.g. the spigot and the BCPM for observations, but only the spigot is needed, then only the spigot should be listed in this section. There is no default for this.

3.3.2.3. Polarizations

If the GBT spectrometer is the chosen backend, and the observer wishes to not have two polarizations recorded, then this parameter must be filled out. The number of polarizations desired can be : 1 (XX or LL), 2(XX \& YY or LL and RR – this is the default), or 4 (XX, XY, YY, YX or LL, LR, RR, RL).

3.3.2.4. Number of beams

This is the total number of beams needed for the observations. The default is equal to the number of available beams for a receiver system.

3.3.2.5. Number of independent spectral windows

This is the total number of spectral windows needed for the observations. This is not the total number of spectral lines to be observed. That is, if one wished to observe 1420, 1665 and 1667 MHz with a 12.5 MHz bandwidth, then only two spectral windows are likely needed as the 1665 and 1667 lines can probably be observed within one spectral window.

3.3.2.6. Bandwidth

This is the total bandwidth desired for each spectral window.

3.3.2.7. Receiver

This is the needed front-end of the system.

3.4. Assigned Data

This is information which is assigned to the project by the Proposal Selection Committee, the GBT telescope scheduler, and the DSS. The observer cannot change any of the information contained here. However, if the project principal investigator feels this information needs to be changed, he can request the GBT telescope scheduler to change it. The change will occur if the telescope scheduler feels it is merited.

3.4.1. Project Data

All the information in this section related to the project as a whole

3.4.1.1. Semester

This is the semester for which the project was proposed.

3.4.1.2. Used Time

This is the total amount of time used by the project for observing. It is entered by the DSS but (like all the data used by the DSS) it can be overridden by the telescope scheduler.

3.4.1.3. Science Grade

This is the science grade assigned to the project by the proposal selection committee.

Note that in some rare cases the proposal selection committee may give the project a certain number of hours at one science grade and a different number of hours at the second science grade. In this case the DSS will use the highest grade hours first. If they wish investigators can control which sessions are run first in this case through the Session Priority system.

3.4.2. Session Data

All the information in this section related to the individual sessions.

3.4.2.1. Used Time

This is the total amount of time used by the session for observing. It is entered by the DSS but (like all the data used by the DSS) it can be overridden by the telescope scheduler.

3.4.2.2. Maximum Time for Semester

In rare cases the proposal selection committee may decide to limit the total amount of time a session can run in a given semester. This could be done in cases where the project is a legacy project and the LST range requested is in high demand. The session would not be able to exceed this time during a semester, but this parameter will be reset once a new semester begins.

3.4.2.3. Success of Session Segment

At the end of a session segment, the telescope operator records if the session segment was successful. This decision would be made in conjunction with the observer. If the session segment was successful, the total time for the session segment would be charged to the project and session observed. If the session segment is listed as unsuccessful the telescope operator must state why and the GBT telescope scheduler will decide how much (if any) time from the telescope period to charge to the observed session(s)/project. As with all the parameters, this data can be overridden by the GBT telescope scheduler.

3.4.2.4. Start of Session Segment

This is the recorded time for the start of a given session segment.

3.4.2.5. Stop of Session Segment

This is the recorded time for the stop of a given session segment.

3.4.2.6. NRAO Priority

On rare occasions NRAO may wish to override the weighting scheme for session selection. In those cases the NRAO priority flag will be set, asserting that the flagged session will be run if the weather conditions are sufficient. The primary purpose of this data is for testing the DSS.

3.5. Notes

Because we do not yet have a DSS in place, I do not comment here about the mechanism for getting the data into the database. It is hoped that much of this information (all that is useful for the Proposal Selection Committee to make reasonable decisions) will come from the Proposal Submission Tool (PST) and so will only need to be entered once.

3.6. Complete Listing of All Data

Complete Listing of All Data for DSS
Project Data	Session Data
Data Entered by Investigators (entered at time of proposal submission and changeable afterward only by GBT scheduler)
Thesis?	LST or UT Range
Proposal Contact	Fixed/Windowed/Any
Total Time	Total Time
	Minimum Time
	Maximum Time
	Time Between
	Canonical Frequency
	Canonical Declination
	Maximum Wind Speed
	Minimum Atmospheric Efficiency
	Time of Day (Night, Work, or Any)
	Session Priority Not required
	Solar Avoidance/Location
	Fixed Time Sessions
	Start Date
	Windowed Sessions
	Start Date - Talk to Carl about this
	Window length
Ancillary Data Entered by Investigators (this information can be changed at any time)
Observing Contact(s)	Observing Mode
User on site date	Backend(s)
User unavailable dates	Polarization (if applicable)
User contact info	Number of beams
	Number of independent spectral windows
	Bandwidth
	Receiver
Data Assigned to Project (entered by DSS, changeable only by GBT scheduler)
Semester	Max Time for Semester
Used Time	Used Time
Science Grade	Success of TP
	Start of TP
	Stop of TP
	NRAO Priority

Topic DynScheduling . { Edit | Attach | Ref-By | Printable | Diffs | r1.5 | > | r1.4 | > | r1.3 | More }

Revision r1.5 - 01 May 2007 - 21:13 GMT - KarenONeil Parents: WebHome	Content copyright © 1999-2007 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.


NRAO Home > Green Bank \| Wiki Topic: GB > Dynamic > DynScheduling

Changes \| Index \| Search \| Go