Scheduling Data

3. Scheduling Data

Table of Contents

Introduction

3.1. Introduction

Data Entered by Investigators

3.1. Data Entered by Investigators

Project Data

Thesis?

3.1.1. Project Data

3.1.1.1. Thesis?

Proposal Contact

3.1.1.1. Proposal Contact

Total Project Time

3.1.1.1. Total Project Time

General Session Data

Time Dependent Data

LST or UT Range

3.1.1. General Session Data

3.1.1.1. Time Dependent Data

3.1.1.1.1. LST or UT Range

Total Session Time

3.1.1.1.1. Total Session Time

Minimum Time

3.1.1.1.1. Minimum Time

Maximum Time

3.1.1.1.1. Maximum Time

Time Between

3.1.1.1.1. Time Between

Time of Day (Night, Work, or Any)

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

Weather Dependent Data

Canonical Frequency

3.1.1.1. Weather Dependent Data

3.1.1.1.1. Canonical Frequency

Canonical Declination

3.1.1.1.1. Canonical Declination

Maximum Wind Speed

3.1.1.1.1. Maximum Wind Speed

Minimum Atmospheric Efficiency

3.1.1.1.1. Minimum Atmospheric Efficiency

Fixed/Windowed Session Data

3.1.1. Fixed/Windowed Session Data

Fixed Sessions

3.1.1.1. Fixed Sessions

Start Date

3.1.1.1.1. Start Date

Windowed Sessions

3.1.1.1. Windowed Sessions

Start Date

3.1.1.1.1. Start Date

Window Length

3.1.1.1.1. Window Length

Other Data

Session Priority

3.1.1.1. Other Data

3.1.1.1.1. Session Priority

Solar Avoidance

3.1.1.1.1. Solar Avoidance

Ancillary Data Entered by Investigators

3.1. Ancillary Data Entered by Investigators

Project Data (Contact and Availability Information)

3.1.1. Project Data (Contact and Availability Information)

Observing Contact(s)

3.1.1.1. Observing Contact(s)

Observer on site date

3.1.1.1. Observer on site date

Observer unavailable dates

3.1.1.1. Observer unavailable dates

Observer contact information

3.1.1.1. Observer contact information

Session Data (Hardware configurations)

3.1.1. 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 ). Do we want defaults for any of these?

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 ).

Observing Mode

3.1.1.1. Observing Mode

Backend(s)

3.1.1.1. Backend(s)

Polarizations

3.1.1.1. Polarizations

Number of beams

3.1.1.1. Number of beams

Number of independent spectral windows

3.1.1.1. Number of independent spectral windows

Bandwidth

3.1.1.1. Bandwidth

Receiver

3.1.1.1. Receiver

Assigned Data

3.1. Assigned Data

Project Data

3.1.1. Project Data

Semester

3.1.1.1. Semester

Used Time

3.1.1.1. Used Time

Science Grade

3.1.1.1. Science Grade

Session Data

3.1.1. Session Data

Used Time

3.1.1.1. Used Time

Maximum Time for Semester

3.1.1.1. Maximum Time for Semester

Success of Session Segment

3.1.1.1. Success of Session Segment

Start of Session Segment

3.1.1.1. Start of Session Segment

Stop of Session Segment

3.1.1.1. Stop of Session Segment

NRAO Priority

3.1.1.1. NRAO Priority

Notes

3.1. Notes

Complete Listing of All Data

3.1. Complete Listing of All Data

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.

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.

here we need an equation or something for determining the hour angle limits

is the latitude of the GBT, is the canonical declination of the session (see above). is the hour angle of the source at right ascension , and is set to 0 at transit (for calculating and ). need to add in how tau is calculated

is the latitude of the GBT, is the canonical declination of the session (see above). is the hour angle of the source at right ascension , and is set to 0 at transit (for calculating and ). need to add in how tau is calculated

This is the date and time at which the session must start. The format for this is TBD.

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

Start Date - Talk to Carl about this

Start Date

This is the length of time for which a window will run. For example, if someone wished to run a project anytime between 15 and 20 May, 2007, the window length would be 5 days. Note that this can be an integer or fractional number.

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.

what is the definition of solar avoidance? By how far (degrees) to we wish to avoid the sun?

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.

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, the GBT operator will may? also contact the on-duty telescope support scientist to help the observer. how will this be arranged? Another flag to be set? *Need to describe observer qualifications better!*

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.

Having incorrect availability dates will lead to considerable frustration by the GBT telescope operator as he or she repeatedly fails in reaching the observer. maybe we can claim that even worse consequences could occur then just a grumpy operator?

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.

This should be expanded to include general contact info (address, emails, telephone, etc) and observing contact info (prioritized list with lots of numbers?)

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 (or anyone else?) 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.

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.

INCLUDE conceptual diagram (Pauls UML)

%META:FILEATTACHMENT{name="Figure8.jpg" attr="h" comment="Absolute hour angle limits" date="1178048357" path="Figure8.jpg" size="84348" user="KarenONeil" version="1.1"}%

Introduction

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, Table~\ref{tab:schedulingdata provides a complete list of all data used by the DSS for scheduling the various project sessions.

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.

Data Entered by Investigators

Data Entered by Investigators

Project Data

Thesis?

Project Data

Thesis?

Proposal Contact

Proposal Contact

Total Time

Total Project Time

Session Data

General Session Data

Time Dependent Data

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 inefficient. 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

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

Fixed/Windowed/Any

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 this Chapter).

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 VLBI and radar runs.

A windowed session must occur between certain times and dates. These are sessions often need to be repeated. 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 observered 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 as the comet passes through the sky, but may not need to be on any specific day or time during that transit.

Total Time

Total Session 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 much 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.

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.

• An investigator wishes to make multiple (10) maps of an astronomical object, where the map is made in azimuth and elevation and takes 2 hours to run (including overhead). To add complication, though, they would like to randomize 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). In practical terms, then, and assuming this is the only segment associated with this session, the TP for this session would be set to 2 hours each time it was observed.

• 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).

A session will 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.

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.

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.

For windowed sessions, the time between is measured from the start of the session's time within a Telescope Period, and will be considered in force from when the session's time ends within that TP. This would 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.

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.

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).

As a second example, again assume a windowed 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, but cannot be run for 8 consecutive hours. 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.

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.

For a windowed session the time between parameter runs from the beginning of the window to the beginning of the next window.

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

Weather Dependent Data

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 efficients (see Project note 2 and below for more information).

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).

Time of Day (Night, Work, or Any)

This parameter sets the time at which a session can be scheduled. For consistency, the session must be complete before its defined time of day ends.

Fixed/Windowed Session Data

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 are important. The current recommendations are that, for best work, observing above 40 GHz should only be done at night, from 3 hours after sunset to 2 hours after sunrise. 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. See http://wiki.gb.nrao.edu/bin/view/PTCS/WebHome for the most up-to-date information on the surface accuracy. To remain consistent with the PTCS definition, night is defined in the DSS as (sunset + 3 hours) to (sunrise - 2 hours).

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).

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.

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.

Solar Avoidance

Observing Mode

Fixed Time Sessions

Fixed Sessions

A windowed session is a session which must be run within a given period of time, but not necessarily on an exact date. Examples of this include monitoring projects which must be run at some point within a given week of every month, GBT maintenance days which must occur at any time during the work week, or observations of a comet which is overhead only for a given period of time (but which does not need to be observed every day for which it is visible).

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 (he 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.

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.

This is the length of time for which a window will run. For example, if someone wished to run a project anytime between 15-20 May, 2007, the window length would be 5 days. Note that this can be an integer or fractional number.

This is the length of time for which a window will run. For example, if someone wished to run a project anytime between 15 and 20 May, 2007, the window length would be 5 days. Note that this can be an integer or fractional number.

Other Data

Session Priority

Ancillary Data Entered by Investigators

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.

Solar Avoidance

Ancillary Data Entered by Investigators

Project Data

Observing Contact(s)

Project Data (Contact and Availability Information)

Observer on site date

Observing Contact(s)

Observer on site date

Observer unavailable dates

Observer unavailable dates

Observer contact information

Observer contact information

Session Data

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 ). Do we want defaults for any of these?

Backend(s)

Observing Mode

Polarizations

Backend(s)

Polarizations

Number of beams

Number of beams

Number of independent spectral windows

Number of independent spectral windows

Bandwidth

Bandwidth

Receiver

Receiver

Data Assigned to Project

Assigned Data

Project Data

Project Data

Semester

Semester

Used Time

Used Time

Science Grade

Science Grade

Session Data

Session Data

Used Time

Used Time

Maximum Time for Semester

Maximum Time for Semester

Success of Telescope Period

Success of Session Segment

Start of TP

Start of Session Segment

Stop of TP

Stop of Session Segment

NRAO Priority

NRAO Priority

Notes

Notes

Complete Listing of All Data

INCLUDE conceptual diagram (Pauls UML)

Complete Listing of All Data

Scheduling Data

Scheduling Data

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 both whether the information is consistent throughout the entire project (and needs only be entered once) or is 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 projects, as well as any data which will filled in and used by the DSS without need for the investigator’s input. Finally, Table~\ref{tab:schedulingdata provides a complete list of all data used by the DSS for scheduling the various project sessions.

Table of Contents

• Introduction

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, Table~\ref{tab:schedulingdata provides a complete list of all data used by the DSS for scheduling the various project sessions.

There are three different types of sessions which can be scheduled: Fixed Time Sessions, Windowed Sessions, and Sessions which can be run at any time (subject to the other constraints listed in this Chapter).

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 this Chapter).

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 time sessions include VLBI and radar runs.

A windowed session must occur between certain times and dates. These are sessions often need to be repeated. Examples of windowed sessions include monitoring projects and maintenance activities:

• Monitor Project: a water maser observation where they must observe sometime during the first week of every month. So a window is assigned for 1-7 Jan 2007. They can observe 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 7 Jan.
• Maintenance Day: an 8 hour maintenance day, 8 AM to 4 PM, must occur between Monday and Wed. for a given week. If this activity has not been scheduled by Tuesday, then it becomes a Fixed Time for Wed.
• 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 for 4 - 6 PM.
• Cometary observations: These would need to be scheduled as the comet passes through the sky, but may

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 VLBI and radar runs.

A windowed session must occur between certain times and dates. These are sessions often need to be repeated. 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 observered 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 as the comet passes through the sky, but may not need to be on any specific day or time during that transit.

This is the total time for a given session. A session cannot run for longer than this time.

This is the total time for a given session. A session cannot run be scheduled for more than this 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 projects, 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. The default maximum time will be set to the maximum time of the session or the end of the LST/UT range, whichever some first.

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.

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

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

As a second example, again assume a windowed 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, but cannot be run for 8 consecutive hours. Here, even though the maximum time is 8 hours, after completing its 4 hours TP the project will not be run until 24 hours have passed.

As a second example, again assume a windowed 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, but cannot be run for 8 consecutive hours. 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.

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 ( is this true? Is frequency needed for this? ) and also what the optimum LST range for the session is. if this is only needed for the latter case, then this isn’t really part of the database but instead should be part of the “tool” to determine the optimum LST range. Or have I forgotten the full reasons for the 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 efficients (see Project note 2 and below for more information).

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\over{e^{-\tau_{min\right]^2 \left({{T_{sys,min\over{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$ 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

This is the minimum transit observing efficiency which the session can tolerate. A session is run if . is defined as

Typically $\eta_{min$ is set to 0.5 to insure reasonable observing efficiency. See {\it Dynamic Scheduling Project Note 2 (http://wiki.gb.nrao.edu/pub/Dynamic/DynamicProjectNotes/dspn2.pdf) for further information on these parameters.

Typically is set to 0.5 to insure reasonable observing efficiency. See Dynamic Scheduling Project Note 2 for further information on these parameters.

Night here is defined according to the GBT Precision Telescope Control System (PTCS) Project. Differential heating and

Night here is defined according to the GBT Precision Telescope Control System (PTCS) Project. Differential heating and

negative impact on baseline shapes. As the PTCS project improves the telescope’s ability to compensate for these changes, the recommendation as to shat frequencies should be observed only at nighttime will increase. See http://wiki.gb.nrao.edu/bin/view/PTCS/WebHome for the most up-to-date information on the surface accuracy.

To remain consistent with the PTCS definition, night is defined in the DSS as (sunset + 3 hours) to (sunrise - 2 hours).

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. See http://wiki.gb.nrao.edu/bin/view/PTCS/WebHome for the most up-to-date information on the surface accuracy. 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.

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.

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

This is the internal ranking which can be given to a session by the investigators. It would be used by the DSS to distinguish between sessions for a given project. The smaller the number for the priority, the higher the session priority is ranked. Additionally, any session with a priority >900 will not be considered for observing, allowing the investigator an easy means for preventing a given session(s) from being scheduled.

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.

Solar Avoidance/Location

Solar Avoidance

A fixed time session is one which must be run at a given time (Date and UTC/LST). Examples of fixed time sessions are radar runs and non-dynamically scheduled VLBI runs.

A fixed time session is one which must be run at a given time (Date and UTC/LST). Examples of fixed time sessions are 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.

Repeat Time

Windowed Sessions

If a project is running fixed time sessions and wishes to be scheduled in irregular intervals, the best means for doing this is to make multiple fixed sessions, one for each date on which the project is to be run.

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 (he 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.

Windowed Sessions

Repeat Time

If a project is running windowed sessions and wishes them to be scheduled in irregular intervals, the best means for doing this is to change the “repeat time” parameter after each telescope period.

These are the dates on which an observer will be present in Green Bank. NOTE: the system must be smart enough to recognize when the observer will be here and ready to observe, as opposed to in transit or sleeping or waiting to talk to their project friend. 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 (See some memo TBD). 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 we need room info here as well, somehow.

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.

This is a complete listing of all backends being used by the session. This is a list only of the {\it required backends, and not the {\it 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.

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.

Polarizations

This is the total number of spectral windows needed for the observations. This is {\it 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.

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.

Polarizations

Spigot Mode (if applicable)

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. *I think this should be maximum time and not max percentage? *

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.

On rare occasions NRAO may wish to override the weighting scheme for session selection. In those cases the NRAO priority will dominate. It will be used by the DSS to distinguish between all possible sessions. As with the session priority, the smaller the number for the priority, the higher the session priority is ranked. Additionally, any session with a priority $>$ 900 will not be considered for observing. By default, all sessions will be given an NRAO priority of 100.

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.

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.

The primary purpose of this data is for testing the DSS.

Complete Listing of All Data

Using the data (the scheduling algorithm)

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.

%META:TOPICINFO{author="KarenONeil" date="1177959276" format="1.0" version="1.1"}% %META:TOPICPARENT{name="WebHome"}%

Scheduling Data

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 both whether the information is consistent throughout the entire project (and needs only be entered once) or is 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 projects, as well as any data which will filled in and used by the DSS without need for the investigator’s input. Finally, Table~\ref{tab:schedulingdata 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.

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.

Project Data

Thesis?

Proposal Contact

Total Time

Session Data

LST or UT Range

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 inefficient. 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.

here we need an equation or something for determining the hour angle limits

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

Fixed/Windowed/Any

There are three different types of sessions which can be scheduled: Fixed Time Sessions, Windowed Sessions, and Sessions which can be run at any time (subject to the other constraints listed in this Chapter).

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 time sessions include VLBI and radar runs.

A windowed session must occur between certain times and dates. These are sessions often need to be repeated. Examples of windowed sessions include monitoring projects and maintenance activities:

• Monitor Project: a water maser observation where they must observe sometime during the first week of every month. So a window is assigned for 1-7 Jan 2007. They can observe 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 7 Jan.
• Maintenance Day: an 8 hour maintenance day, 8 AM to 4 PM, must occur between Monday and Wed. for a given week. If this activity has not been scheduled by Tuesday, then it becomes a Fixed Time for Wed.