An session will have a minimum and maximum time associated with it. The minimum time will define 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 session to be scheduled. Note that the DSS will, of course, attempt to make a much longer TP for the project and session, but due to the difficulty in scheduling the telescope it is conceivable that an session will be scheduled for only its minimum time. The default minimum time will be set to 2 hours.

A session will have a minimum and maximum time associated with it. The minimum time will define 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 session to be scheduled. Note that the DSS will, of course, attempt to make a much longer TP for the project and session, but due to the difficulty in scheduling the telescope it is conceivable that an session will be scheduled for only its minimum time. The default minimum time will be set to 2 hours.

An session will have a minimum and maximum time associated with it. The maximum time for that session will define the longest period of time in the LST 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 segments. Unlike fixed time and fixed window projects, the maximum time parameter does not offer any information as to when the next session session 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

A session will have a minimum and maximum time associated with it. The maximum time for that session will define the longest period of time in the LST 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 segments. Unlike fixed time and fixed window projects, the maximum time parameter does not offer any information as to when the next session 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

A priority ranking given to project sessions by the GBT staff which would override all other priorities in the SelectionCriteria? listing (Criteria IV). This is intended to be used on in the extremely rare case where the telescope scheduler or another qualified individual decides that a given session(s) needs priority over all other sessions, overriding the normal priority listing. 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.

A priority ranking given to project sessions by the GBT staff which would override all other priorities in the SelectionRules listing (Criteria IV). This is intended to be used on in the extremely rare case where the telescope scheduler or another qualified individual decides that a given session(s) needs priority over all other sessions, overriding the normal priority listing. 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.

Here, a Observing Block is just the script used to obtain the desired telescope data, and a limited amount of metadata.

Here, an Observing Block is just the script used to obtain the desired telescope data, and a limited amount of metadata.

This is a list of people to contact for observing. Initially the list will be the same as for the Proposal Contact, but can change once the project sessions are being prepared for observing. As this is a list of people to contact for observing in the GBT, people should not be on it whom are not qualified for GBT observations. This should be a prioritized list of contacts for specific date ranges - if contact A cant be reached at number X on this date, try contact B at number Y.

This is a list of people to contact for observing. Initially the list will be the same as for the Proposal Contact, but can change once the project sessions are being prepared for observing. As this is a list of people to contact for observing in the GBT, people should not be on it who are not qualified for GBT observations. This should be a prioritized list of contacts for specific date ranges - if contact A cant be reached at number X on this date, try contact B at number Y.

A segment is the part of a session observed within a Telescope Period. As an example, suppose a session has a minimum time of 1 hour, a maximum time of 6 hours, and a total time of 6 hours. Then, suppose the DSS schedules that secssion for only 3 hours. This, then, is a 3 hour segment of the session.

A segment is the part of a session observed within a Telescope Period. As an example, suppose a session has a minimum time of 1 hour, a maximum time of 6 hours, and a total time of 6 hours. Then, suppose the DSS schedules that session for only 3 hours. This, then, is a 3 hour segment of the session.

Weather Categroy

Weather Category

Proposal Submission Tool (PST)

A period of time which is the maximum time during which projects may not be changed. These exist to insure that an observer can have a guaranteed time for observing, even if the weather improves. Typically a Telescope Period will last for 4 hours, however there are numerous conditions under which this time could change:

A period of time which is the maximum time during which projects may not be changed by the DSS. These exist to insure that an observer can have a guaranteed time for observing, even if the weather improves. Typically a Telescope Period will last for 4 hours, however there are numerous conditions under which this time could change:

This is the internal ranking which can be given to an 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.

This is the internal ranking which can be given to an session by the investigators. It would be used by the DSS to distinguish between sessions for a given project. The higherthe number for the priority, the higher the session priority is ranked. Additionally, any session with a priority =0 will not be considered for observing.

Fixed Time (Session)

Fixed Window (Session)

• Monitor Project: a water maser observation where they must observe sometime during the first week of every month. So a fixed 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 fixed 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.

Fixed Session

Windowed Session

• Monitor Project: a water maser observation where they must observe sometime during the first week of every month. So a fixed 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 fixed 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.

All projects are broken into multiple sessions, where each session is defined by a given set of criteria (e.g. LST/UT, weather, hardware). All observations which an investigator wishes to pursue for the project must be contained within one or more sessions, and it is these individual sessions which the DSS will schedule.

All projects are broken into multiple sessions, where each session is uniquely defined by a given set of criteria (e.g. LST/UT, weather, hardware). All observations which an investigator wishes to pursue for the project must be contained within one or more sessions, and it is these individual sessions which the DSS will schedule.

Incomplete or ambiguous terms

I (RichardPrestage) Have concerns with Allocation, Observing Script and Session

An event whose allocation must be scheduled (as a session) but which does not use the PST and therefore has no project associated with it. Examples of this include maintenance activities and commissioning runs.

Allocation

A project or activity allocation is defined by its associated data (e.g. LST range, weather, hardware needed). The allocation metadata will be the basis for the dynamic scheduling system's decision for the schedule.

Allocation - defined by its data. Allocation Data - data associated with a given allocation. Seems pretty circular to me.

Allocation MetaData

The metadata associated with a given allocation. A list of allocation metadata can be found at SchedulingData. In the PST, allocation is used only twice, referring to the total amount of time requested by a project. E.g. Regular Project: A project which requires small allocations of telescope time (less than 200 hours).

Allocation Priority

Allocation Scheduling Criteria

An event whose session must be scheduled (as a segment) but which does not use the PST and therefore has no project associated with it. Examples of this include maintenance activities and commissioning runs.

The suite of tools which will be provided by the dynamic scheduling project. This includes the software which on demand provides a list of candidate allocations and sessions listed by priority for any specified telescope time range according to the GBT selection rules. It also includes the interfaces into this software, including the interface which allows for entries/changes into the dynamic scheduling system, and anything else listed under the DSS in the final SoftwareSuite.

The suite of tools which will be provided by the dynamic scheduling project. This includes the software which on demand provides a list of candidate sessions and sessions listed by priority for any specified telescope time range according to the GBT selection rules. It also includes the interfaces into this software, including the interface which allows for entries/changes into the dynamic scheduling system, and anything else listed under the DSS in the final SoftwareSuite.

Fixed Time (Allocation)

Fixed Time (Session)

Fixed Window (Allocation)

Fixed Window (Session)

Minimum Time (Allocation)

Minimum Time (Session)

• 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 within that allocation 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 allocation'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.

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

Maximum Time (Allocation)

Maximum Time (Session)

• 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 sessions 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 session associated with this allocation, the TP for this allocation would be set to 2 hours each time it was observed.
• 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 sessions 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).

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

A priority ranking given to project allocations by the GBT staff which would override all other priorities in the SelectionCriteria? listing (Criteria IV). This is intended to be used on in the extremely rare case where the telescope scheduler or another qualified individual decides that a given allocation(s) needs priority over all other allocations, overriding the normal priority listing. The smaller the number for the priority, the higher the allocation priority is ranked. Additionally, any allocation with a priority > 900 will not be considered for observing.

A priority ranking given to project sessions by the GBT staff which would override all other priorities in the SelectionCriteria? listing (Criteria IV). This is intended to be used on in the extremely rare case where the telescope scheduler or another qualified individual decides that a given session(s) needs priority over all other sessions, overriding the normal priority listing. 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.

Here, a Observing Block is just the observing script used to obtain the desired telescope data, and a limited amount of metadata.

• The Observing Script is the text to be found in the Observation Management's Edit Tab's Editor text area. Examples of these can be found at ObservingAPIExamples
• The metadata is quite sparse: it is the info found in the Observation Management's Run Tab's upper line - proposal id, session, observer, operator. What else in the turtle database could be considered metadata?

Here, a Observing Block is just the script used to obtain the desired telescope data, and a limited amount of metadata.

• The script is the text to be found in the Observation Management's Edit Tab's Editor text area. Examples of these can be found at ObservingAPIExamples
• The metadata is quite sparse and consists of only the proposal ID, session number, observer’s name and operator’s name.

Operator

This is a list of people to contact for observing. Initially the list will be the same as for the Proposal Contact, but can change once the project allocations are being prepared for observing. As this is a list of people to contact for observing in the GBT, people should not be on it whom are not qualified for GBT observations. This should be a prioritized list of contacts for specific date ranges - if contact A cant be reached at number X on this date, try contact B at number Y.

This is a list of people to contact for observing. Initially the list will be the same as for the Proposal Contact, but can change once the project sessions are being prepared for observing. As this is a list of people to contact for observing in the GBT, people should not be on it whom are not qualified for GBT observations. This should be a prioritized list of contacts for specific date ranges - if contact A cant be reached at number X on this date, try contact B at number Y.

From ObservingTools: "The Observing API is used to build an Observing Script, which is one component of a Observing Block."

The observing script is the text to be found in the Observation Management's Edit Tab's Editor text area. Examples of these can be found at ObservingAPIExamples

Again, "Observing Blocks consists of Observing Scripts, and Observing Scripts are components of Observing Blocks". Both need to be defined independently.

Operator

The scientific proposal, with its metadata, which is submitted through the PST and which then may eventually get scheduled on the telescope. There is no distinction made between projects which receive high rankings from the referees/PSC and those which are

given rankings too low to be observed with the GBT, as that is simply a "scientific ranking" criteria for the DSS. The Common NRAO Models page describes a project model in the following way:

The scientific proposal, with its metadata, which is submitted through the PST and which then may eventually get scheduled on the telescope. There is no distinction made between projects which receive high rankings from the referees/PSC and those which are given rankings too low to be observed with the GBT, as that is simply a "scientific ranking" criteria for the DSS. The Common NRAO Models page describes a project model in the following way:

A web page, or group of web pages, which provides, or provides links to, all pertinent information for a given project and its allocations.

A web page, or group of web pages, which provides, or provides links to, all pertinent information for a given project and its sessions.

Segment

A segment is the part of a session observed within a Telescope Period. As an example, suppose a session has a minimum time of 1 hour, a maximum time of 6 hours, and a total time of 6 hours. Then, suppose the DSS schedules that secssion for only 3 hours. This, then, is a 3 hour segment of the session.

A session is part of an Allocation observed within a Telescope Period. The DSS looks at Allocation Metadata to create a potential session.

All projects are broken into multiple sessions, where each session is defined by a given set of criteria (e.g. LST/UT, weather, hardware). All observations which an investigator wishes to pursue for the project must be contained within one or more sessions, and it is these individual sessions which the DSS will schedule.

As an example, suppose a project has just two sources, separated by 5 hours of LST but which otherwise use the same hardware, weather conditions, etc. In this case, the project would naturally be broken into two sessions - one for each source.

I (RichardPrestage) do not understand the above definition.

As a difference example, assume that the project has only one source, but the investigator wishes to observe the source with two different front ends. Again this project would be naturally broken into two sessions, one for each front end.

Session is defined by the PST in a manner that is a cross between the DSS definition of session and that of allocation:

As a difference example, assume that the project has only one source, but the investigator wishes to observe the source with two different front ends. Again this project would be naturally broken into two sessions, one for each front end.

For a final example, assume a project has sources across the sky in LST, but the weather and hardware requirements for each source is the same. Here, the investigator may wish to break the project into as many as 24 sessions, one for each hour of LST.

Session is defined by the PST in a manner that is a cross between the DSS definition of session and that of session:

Session MetaData

The metadata associated with a given session. A list of session metadata can be found at SchedulingData.

Session Priority

Session Scheduling Criteria

An observation is deemed successful if the observer is able to carry out his/her Observing Block without problems accountable to the GBT (e.g. hardware or software problems). If the observer requests the wrong source or otherwise makes a mistake in his/her session but otherwise the session is run successfully, that sessions still considered successful and the time is logged against the project/activity and allocation.

An observation is deemed successful if the observer is able to carry out his/her Observing Block without problems accountable to the GBT (e.g. hardware or software problems). If the observer requests the wrong source or otherwise makes a mistake in his/her session segment but otherwise the session is run successfully, that segments still considered successful and the time is logged against the project/activity and session.

A period of time which is the maximum time during which projects may not be changed. These exist to insure that an observer can have a guaranteed time for observing, even if the weather improves to the next higher weather category. Typically a Telescope Period will last for 4 hours, however there are numerous conditions under which this time could change:

• The minimum session time for the project or activity allocation is more than four hours

A period of time which is the maximum time during which projects may not be changed. These exist to insure that an observer can have a guaranteed time for observing, even if the weather improves. Typically a Telescope Period will last for 4 hours, however there are numerous conditions under which this time could change:

• The minimum segment time for the project or activity session is more than four hours

A telescope period may contain more than one session from more than one allocation within a given project.

A telescope period may contain more than one segment from more than one session within a given project.

Time Between (Allocation)

Time Between (Session)

An allocation 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 allocation can be rescheduled on the telescope. The time between is measured from the start of the allocation's time within a Telescope Period, and will be considered in force from when the allocation'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 time between parameter for a fixed window allocation runs from the beginning of the fixed window to the beginning of the next fixed window.

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. 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 time between parameter for a fixed window session runs from the beginning of the fixed window to the beginning of the next fixed window.

The default time between will be zero. This means that even if an allocation has a maximum time associated with it, if the time between is left at 0, the next TP with an allocation could begin as soon as the last TP of that allocation ends. E.g. if an allocation 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, its feasible that the project run for 8 hours and then immediately start a new TP of 4 (or even 8) hours without any break.

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 an session could begin as soon as the last TP of that session ends. E.g. if an 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, its 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 an allocation 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 lets assume the project runs for 4 hours within a TP, but cannot be run for 8 consecutive hours. In this case, 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 an 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 lets assume the project runs for 4 hours within a TP, but cannot be run for 8 consecutive hours. In this case, 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.

Weather Classification

Weather Categroy

Project Web Page

A web page, or group of web pages, which provides, or provides links to, all pertinent information for a given project and its allocations. A prototype page can be seen at ProjectsPage

Dynamic Scheduling Software (DSS)

Dynamic Scheduling System (DSS)

The software tool or suite of tools which will be provided by the dynamic scheduling project. This includes the software which on demand provides a list of candidate allocations and sessions listed by priority for any specified telescope time range according to the GBT selection rules. It also includes the interfaces into this software, including the interface which allows for entries/changes into the dynamic scheduling system, and anything else listed under the DSS in the final SoftwareSuite.

The suite of tools which will be provided by the dynamic scheduling project. This includes the software which on demand provides a list of candidate allocations and sessions listed by priority for any specified telescope time range according to the GBT selection rules. It also includes the interfaces into this software, including the interface which allows for entries/changes into the dynamic scheduling system, and anything else listed under the DSS in the final SoftwareSuite.

An allocation 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 allocation can be rescheduled on the telescope. The time between is measured from the start of the allocation's time within a Telescope Period, and will be considered in force from when the allocation'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.

An allocation 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 allocation can be rescheduled on the telescope. The time between is measured from the start of the allocation's time within a Telescope Period, and will be considered in force from when the allocation'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 time between parameter for a fixed window allocation runs from the beginning of the fixed window to the beginning of the next fixed window.

A project or activity allocation is defined by its associated metadata (e.g. LST range, weather category, hardware needed). The allocation metadata will be the basis for the dynamic scheduling system's decision for the schedule.

A project or activity allocation is defined by its associated data (e.g. LST range, weather, hardware needed). The allocation metadata will be the basis for the dynamic scheduling system's decision for the schedule.

Allocation - defined by its metadata. Allocation MetaData - metadata associated with a given allocation. Seems pretty circular to me.

Allocation - defined by its data. Allocation Data - data associated with a given allocation. Seems pretty circular to me.

A fixed window allocation must occur between certain times/dates. Examples of fixed window allocations include monitoring projects and maintenance activites:

A fixed window allocation must occur between certain times/dates. Examples of fixed window allocations include monitoring projects and maintenance activities:

• Maintanence Day: an 8 hour maintance 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.

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

None at the moment

I (RichardPrestage) Have concerns with Allocation, Observing Script and Session

Allocation - defined by its metadata. Allocation MetaData - metadata associated with a given allocation. Seems pretty circular to me.

The software tool or suite of tools which will be provided by the dynamic scheduling project or activity. This includes the software which on demand provides a list of candidate allocations and sessions listed by priority for any specified telescope time range according to the GBT selection rules. It also includes the interfaces into this software, including the interface which allows for entries/changes into the dynamic scheduling system, and anything else listed under the DSS in the final SoftwareSuite.

The software tool or suite of tools which will be provided by the dynamic scheduling project. This includes the software which on demand provides a list of candidate allocations and sessions listed by priority for any specified telescope time range according to the GBT selection rules. It also includes the interfaces into this software, including the interface which allows for entries/changes into the dynamic scheduling system, and anything else listed under the DSS in the final SoftwareSuite.

• 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 sessions 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 session associated with this allocation, the TP for this allocation would be set to 2 hours each time it was observer.

• 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 sessions 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 session associated with this allocation, the TP for this allocation would be set to 2 hours each time it was observed.

NRAO Priority

Again, "Observing Blocks consists of Observing Scripts, and Observing Scripts are components of Observing Blocks". Both need to be defined independently.

The scientific proposal which is submitted through the PST. Once submitted, the term "project" applies _The PST uses proposal in a similar manner, but also uses the term "project". The distinction between the two is unclear._

The scientific proposal which is submitted through the PST. Once submitted, the term "project" applies The PST uses proposal in a similar manner, but also uses the term "project". The distinction between the two is unclear.

I (RichardPrestage) do not understand the above definition.

The default time between will be zero. This means that even if an allocation has a maximum time associated with it, if the time between is left at 0, the next TP with an allocation could begin as soon as the last TP of that allocation ends. E.g. if an allocation 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, its feasible that the project run for 8 hours and then immeadiately start a new TP of 4 (or even 8) hours without any break.

The default time between will be zero. This means that even if an allocation has a maximum time associated with it, if the time between is left at 0, the next TP with an allocation could begin as soon as the last TP of that allocation ends. E.g. if an allocation 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, its feasible that the project run for 8 hours and then immediately start a new TP of 4 (or even 8) hours without any break.

The person carrying out observations, normally by adding SBs to the queue. This may be one of:

The person carrying out observations, normally by adding OBs to the queue. This may be one of:

Observing Block

• The Observing Script is the text to be found in the Observation Management's Edit Tab's Editor text area. Examples of these can be found at ObservingAPIExamples
• The metadata is quite sparse: it is the info found in the Observation Management's Run Tab's upper line - proposal id, session, observer, operator. What else in the turtle database could be considered metadata?
• Observing Blocks will not be used by the DSS for determining what should or should not be run.

From ObservingTools: "The Observing API is used to build an Observing Script, which is one component of a Scheduling Block."

From ObservingTools: "The Observing API is used to build an Observing Script, which is one component of a Observing Block."

Scheduling Block

• The Observing Script is the text to be found in the Observation Management's Edit Tab's Editor text area. Examples of these can be found at ObservingAPIExamples
• The metadata is quite sparse: it is the info found in the Observation Management's Run Tab's upper line - proposal id, session, observer, operator. What else in the turtle database could be considered metadata?
• Scheduling blocks will not be used by the DSS for determining what should or should not be run.

Richard - what is the use of a Scheduling Block now we have sessions? Why not just have sessions and observing scripts? "Scheduling Block" sounds very official, and sounds like it would have something to do with defining schedules. I think we should transfer this label to something more useful, and change the name of this thingy - if we still need it - to something more appropriate, e.g. Observing Block = Observing Script + metadata

An observation is deemed successful if the observer is able to carry out his/her scheduling block without problems accountable to the GBT (e.g. hardware or software problems). If the observer requests the wrong source or otherwise makes a mistake in his/her session but otherwise the session is run successfully, that sessions still considered successful and the time is logged against the project/activity and allocation.

An observation is deemed successful if the observer is able to carry out his/her Observing Block without problems accountable to the GBT (e.g. hardware or software problems). If the observer requests the wrong source or otherwise makes a mistake in his/her session but otherwise the session is run successfully, that sessions still considered successful and the time is logged against the project/activity and allocation.

Requirement to immediately stow the antenna, usually due to high winds or accumulating snow. This will result in the need to abort or pause a Scheduling Block being executed, or to delay submitting a new Scheduling Block to the telescope.

Requirement to immediately stow the antenna, usually due to high winds or accumulating snow. This will result in the need to abort or pause a Observing Block being executed, or to delay submitting a new Observing Block to the telescope.

An allocation will have a minimum and maximum time associated with it. The minimum time will define 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 session for the allocation to be scheduled. Note that the DSS will, of course, attempt to make a much longer TP for the project and allocation, but due to the difficulty in scheduling the telescope it is conceivable that an allocation will be scheduled for only its minimum time.

An allocation will have a minimum and maximum time associated with it. The minimum time will define 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 session for the allocation to be scheduled. Note that the DSS will, of course, attempt to make a much longer TP for the project and allocation, but due to the difficulty in scheduling the telescope it is conceivable that an allocation will be scheduled for only its minimum time. The default minimum time will be set to 2 hours.

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

An allocation will have a minimum and maximum time associated with it. The maximum time for that allocation will define the longest period of time in the LST range for which a session will be scheduled (that is, it will define the longest session allowed). The purpose of this definition is to allow for observers to readily break their (non-fixed or windowed time) project into multiple sessions. Unlike fixed time and fixed window projects, the maximum time parameter does not offer any information as to when the next allocation session will be scheduled, except that it will not be scheduled until the LST range for the allocation begins again. The default maximum time will be set to the maximum time of the allocation

An allocation 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 allocation can be rescheduled on the telescope. 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.

An allocation 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 allocation can be rescheduled on the telescope. The time between is measured from the start of the allocation's time within a Telescope Period, and will be considered in force from when the allocation'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 an allocation has a maximum time associated with it, if the time between is left at 0, the next TP with an allocation could begin as soon as the last TP of that allocation ends. E.g. if an allocation 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, its feasible that the project run for 8 hours and then immeadiately start a new TP of 4 (or even 8) hours without any break.

As a second example, again assume an allocation 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 lets assume the project runs for 4 hours within a TP, but cannot be run for 8 consecutive hours. In this case, 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.

The metadata associated with a given allocation. A list of allocation metadata can be found at SchedulingMetadata?. In the PST, allocation is used only twice, referring to the total amount of time requested by a project. E.g. Regular Project: A project which requires small allocations of telescope time (less than 200 hours).

The metadata associated with a given allocation. A list of allocation metadata can be found at SchedulingData. In the PST, allocation is used only twice, referring to the total amount of time requested by a project. E.g. Regular Project: A project which requires small allocations of telescope time (less than 200 hours).

A fixed window allocation must occur between certain times/dates. Examples of fixed window allocations include monitoring projects and maintenance days.

A fixed window allocation must occur between certain times/dates. Examples of fixed window allocations include monitoring projects and maintenance activites:

• Monitor Project: a water maser observation where they must observe sometime during the first week of every month. So a fixed 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 fixed window converts to a fixed time for 7 Jan.

• Maintanence Day: an 8 hour maintance 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.

Quick Links:

Table of Contents

Glossary Issues

Dynamic Scheduling Glossary

This is the internal ranking which can be given to an allocation by the investigators. It would be used by the DSS to distinguish between allocations for a given project.

This is the internal ranking which can be given to an allocation by the investigators. It would be used by the DSS to distinguish between allocations for a given project. The smaller the number for the priority, the higher the allocation priority is ranked. Additionally, any allocation with a priority > 900 will not be considered for observing.

Co-Investigator (Co-I)

Observing Contact

Principal Investigator (PI)

Proposal Contact

Time Between (Allocation)

I have now included all places I could find where our terminology and that of the PST overlap, as defined in the PST documentation http://e2e.nrao.edu/pst/PSTMANUAL/PSTMANUAL.html. We need someone (Dana?) to go over the discrepencies with the E2E or PST group, whichever is appropriate, to ensure we are all on the same page with both our planning and our terminology . - KarenONeil

All places where our terminology and that of the PST overlap, as defined in the PST documentation http://e2e.nrao.edu/pst/PSTMANUAL/PSTMANUAL.html have now been given. We still need someone (Dana?) to go over the discrepancies with the E2E or PST group, whichever is appropriate, to ensure we are all on the same page with both our planning and our terminology.

There is a useful document somewhere in the NRAO wiki with definitions of "Project Model", "Observing Model", etc, at https://wiki.nrao.edu/bin/view/Software/CommonNRAOModels; The only overlap I see with the DSS definitions is that of "Project Model", where project not proposal is the preferred term for what we are calling the proposal.

There is a useful document somewhere in the NRAO wiki with definitions of "Project Model", "Observing Model", etc, at https://wiki.nrao.edu/bin/view/Software/CommonNRAOModel. The only overlap I see with the DSS definitions is that of "Project Model", which we have adopted.

Once the above ambiguities are worked out and we are confident of our usage, we need to go through the GB web pages to remove any discrepencies in usage of words.

Once the above ambiguities are worked out and we are confident of our usage, we need to go through the GB web pages to remove any discrepancies in usage of words.

An event which must be scheduled on the telescope but which does not ue the PST and therefore has no proposal associated with it. Examples of this include maintenance activities and commissioning runs.

An event whose allocation must be scheduled (as a session) but which does not use the PST and therefore has no project associated with it. Examples of this include maintenance activities and commissioning runs.

A proposal or activity allocation is defined by its associated metadata (e.g. LST range, weather category, hardware needed). The allocation metadata will be the basis for the dynamic scheduling system's decision for the schedule. In practice an allocation will consist of one or more session within a Telescope Period. The phrase "within a Telescope Period" sounds like all the sessions of an Allocation are contained in one Telescope Periods? - Mark

A project or activity allocation is defined by its associated metadata (e.g. LST range, weather category, hardware needed). The allocation metadata will be the basis for the dynamic scheduling system's decision for the schedule.

The metadata associated with a given allocation. A list of allocation metadata can be found at SchedulingMetadata?. In the PST, allocation is used only twice, refering to the total amount of time requested by a proposal. E.g. Regular Proposal: A proposal which requires small allocations of telescope time, less than 200 hours.

The metadata associated with a given allocation. A list of allocation metadata can be found at SchedulingMetadata?. In the PST, allocation is used only twice, referring to the total amount of time requested by a project. E.g. Regular Project: A project which requires small allocations of telescope time (less than 200 hours).

This is the internal ranking which can be given to an allocation by the investigators. It would be used by the DSS to distinguish between allocations for a given proposal.

This is the internal ranking which can be given to an allocation by the investigators. It would be used by the DSS to distinguish between allocations for a given project.

The subset of the Metadata for a allocation which is needed by the DSS to qualify it and rank it against other qualified allocations.

The subset of the Metadata for an allocation which is needed by the DSS to qualify it and rank it against other qualified allocations.

Completed Project

Completed Project/Activity

The software tool or suite of tools which will be provided by the dynamic scheduling proposal or activity. This includes the software which on demand provides a list of candidate allocations and sessions listed by priority for any specified telescope time range according to the GBT selection rules. It also includes the interfaces into this software, including the interface which allows for entries/changes into the dynamic scheduling system, and anything else listed under the DSS in the final SoftwareSuite.

The software tool or suite of tools which will be provided by the dynamic scheduling project or activity. This includes the software which on demand provides a list of candidate allocations and sessions listed by priority for any specified telescope time range according to the GBT selection rules. It also includes the interfaces into this software, including the interface which allows for entries/changes into the dynamic scheduling system, and anything else listed under the DSS in the final SoftwareSuite.

A fixed window allocation must occur between certain times/dates. Examples of fixed window allocations include monioring proposals and maintenance days.

A fixed window allocation must occur between certain times/dates. Examples of fixed window allocations include monitoring projects and maintenance days.

One of the named authors associated with the proposal at the time it was submitted

One of the named authors associated with the project at the time it was submitted through the PST, or the person(s) responsible for a GBT activity.

A allocation will have a minimum and maximum time associated with it. The minimum time will define 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 session for the allocation to be scheduled. Note that the DSS will, of course, attempt to make a much longer TP for the proposal and allocation, but due to the difficulty in scheduling the telescope it is conceivable that a allocation will be scheduled for only its minimum time.

An allocation will have a minimum and maximum time associated with it. The minimum time will define 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 session for the allocation to be scheduled. Note that the DSS will, of course, attempt to make a much longer TP for the project and allocation, but due to the difficulty in scheduling the telescope it is conceivable that an allocation will be scheduled for only its minimum time.

• If a pulsar investigator needs to observe a pulsar for 8 consecutive hours to correctly obtain the pulsar(s) orbit parameters, the minium time for a session wthin that allocation 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 proposal allocation's minimum time 10 minutes + overhead. In this case, though, even though the proposal'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 proposal's total time in overhead. Instead a sensible minimum time might be 30 minutes or 1 hour.

• 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 within that allocation 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 allocation'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.

An allocation will have a minimum and maximum time associated with it. The maximum time for that allocation will define the longest period of time in the LST range for which a session will be scheduled (that is, it will define the longest session allowed). The purpose of this definition is to allow for observers to readily break their (non-fixed or windowed time) proposal into multiple sessions. Unlike fixed time and fixed window proposals, the maximum time parameter does not offer any information as to when the next allocation session will be scheduled, except that it will not be scheduled until the LST range for the allocation begins again.

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

• 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 maps in a given 24 hour period. In this case, the sessions 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 session associated with this allocation, the TP for this allocation would be set to 2 hours each time it was observer.
• Another pulsar-pulsar pair is found. The investigators wish to determine the full oribital 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 sessions 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).

• 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 sessions 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 session associated with this allocation, the TP for this allocation would be set to 2 hours each time it was observer.
• 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 sessions 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).

A generic term used to indicate that the telescope is being used to perform observing, without being more specific. Observation is used in a similar sense in the PST. E.g. Here the proposer indicates whether an observer will be present at the telescope for the proposed observations.

A generic term used to indicate that the telescope is being used to perform observing, without being more specific. Observation is used in a similar sense in the PST. E.g. here the investigator indicates whether an observer will be present at the telescope for the proposed observations.

• Project Observer - someone already associated with the proposal; i.e. P.I. or Co-I.

• Project Observer - someone already associated with the project; i.e. P.I. or Co-I.

who has volunteered to perform other observations should the weather not be good enough for theirs).

Who has volunteered to perform other observations should the weather not be good enough for theirs).

• Operator - cannot be used at this time, except in predfeined curcumstances (e.g. VLBI runs)

• Operator - cannot be used at this time, except in predefined circumstances (e.g. VLBI runs)

Proposal

Project

telescope. There is no distinction made between proposals which receive high rankings from the referees/PSC and those which are given rankings too low to be observed with the GBT, as that is simply a "scientific ranking" criteria for the DSS. _The PST uses proposal in a similar manner, but also uses the term "project". The distinction between the two is unclear._

telescope. There is no distinction made between projects which receive high rankings from the referees/PSC and those which are given rankings too low to be observed with the GBT, as that is simply a "scientific ranking" criteria for the DSS. The Common NRAO Models page describes a project model in the following way:

• The Project model defines an information model for an observing project. The Project model includes everything needed to describe an observing project and to process and track the project through the system, from proposal submission through to data products in the archive and subsequent publications. The Project model is required to drive the automated observing process and all post-processing. The Project model includes definitions of all concepts and terminology required to statically describe the state of an observing project, e.g., proposal, program, program block, target list, resource requirements, and so forth.

Proposal Friend

The GBT staff member who is assigned to help the investigators in preparing their proposal for observations with the GBT. This person is typically a GBT support scientist, but is not necessarily the on-duty support scientist at the time the proposal is observed. In the PST, this classification is used to determine the amount of help needed by a project - if you need a "friend" then "You do not have much observing experience and will need extensive help from the NRAO staff."

Project Friend

The GBT staff member who is assigned to help the investigators in preparing their project for observations with the GBT. This person is typically a GBT support scientist, but is not necessarily the on-duty support scientist at the time the project is observed. In the PST, this classification is used to determine the amount of help needed by a project - if you need a "friend" then "You do not have much observing experience and will need extensive help from the NRAO staff."

Proposal

The final reviewing committee for GBT proposals. The PSC generally accept the referees proposed time allowance, and view themselves largely as applying agreed policy and the referees rankings to select the top ranked proposals until the total available telescope time is used. The PSC does certainly make scientific judgments, but prefers not to over-rule the referees rankings without good reason.

The final reviewing committee for GBT projects. The PSC generally accept the referees proposed time allowance, and view themselves largely as applying agreed policy and the referee’s rankings to select the top ranked projects until the total available telescope time is used. The PSC does certainly make scientific judgments, but prefers not to over-rule the referees’ rankings without good reason.

The person who currently schedules the GBT and whom still has ultimate responisbility for the GBT telescope schedule. Currently, the scheduler is Carl Bignell.

The person who currently schedules the GBT and whom still has ultimate responsibility for the GBT telescope schedule. Currently, the scheduler is Carl Bignell.

• The metadata is quite sparse: it is the info found in the Observation Management's Run Tab's upper line - propoal id, session, observer, operator. What else in the turtle database could be considered metadata?

• The metadata is quite sparse: it is the info found in the Observation Management's Run Tab's upper line - proposal id, session, observer, operator. What else in the turtle database could be considered metadata?

The grade given to a proposal by the GBT PSC

The grade given to a project by the GBT PSC. Our working definition of science grades is given at SelectionRules#ScienceGrades

Currently, a four month block of observing time for which proposals are called for, refereed and awarded a science grade, and allocated time. Semester boundaries are:

Currently, a four month block of observing time for which projects are called for, refereed and awarded a science grade, and allocated time. Semester boundaries are: