Summary of GBT Dynamic Scheduling Project

1. Summary of GBT Dynamic Scheduling Project

To use the GBT's dynamic scheduling system(DSS), an investigator first must break his/her observations into discrete allocations, each of which is defined by a unique set of data, such as LST range, weather, needed hardware, etc. These data will be supplied by the project investigators and, while the DSS may recommend default values for that data (e.g. given the desired frequency range and right ascension/declination the DSS could recommend a certain LST or weather values), the data entered for each allocation will be set be the investigators, observers, and proposal selection committee, and not by the DSS itself. (Note that these allocations may be associated with specific observing blocks, but that association is known by the investigator(s) only and is not taken into account by the DSS in any form.) When called upon to do so, the DSS will analyze the data associated with all available allocations and attempt to select candidate allocations which are best suited to the current weather conditions and hardware configuration of the GBT. The DSS will then display these candidate allocations in an easily readable form to the GBT Operator, who ultimately chooses the next Project allocation. Once that project is chosen, the operator will contact one of the project's ObservingContacts and inform him or her that his/her project will be running next and request that the observer begin preparations to run his/her observations. Once that project's Telescope Period is nearing completion, the operator will again consult the DSS in order to choose the next project/allocation. Note that in addition to listing the allocations which can be run based on the current weather, the DSS needs to be able to provide a look ahead probability to allow observers to know the probability of their allocations being run within the next few days/week(s).

To use the GBT's dynamic scheduling system(DSS), an investigator first must break his/her observations into discrete sessions, each of which is defined by a unique set of data, such as LST range, weather, needed hardware, etc. These data will be supplied by the project investigators and, while the DSS may recommend default values for that data (e.g. given the desired frequency range and right ascension/declination the DSS could recommend a certain LST or weather values), the data entered for each session will be set be the investigators, observers, and proposal selection committee, and not by the DSS itself. (Note that these sessions may be associated with specific observing blocks, but that association is known by the investigator(s) only and is not taken into account by the DSS in any form.)

In addition to the policies, algorithms, and scheduling software needed to select candidate allocations for observing, the DSS also needs to provide a suite of support software which will ease the use of the DSS for both observers and Green Bank staff. This suite of software is primarily geared toward satisfying all of the support operations that go with dynamic scheduling. Most importantly, this suite of software should engage the observer in the dynamic scheduling process and ensure that he/she knows what is happening with his or her project at any given moment. This software suite includes, but is not limited to: a means for an investigator/observer to know the probability of his/her project being run in the near future, a means of ready communication between the observer, operator, scheduling software, and investigator regarding ongoing, future, and past observations, and easy means for observers to change their contact information and availability.

A number of weather queues (conceptually "excellent", "fair" and "poor") will be defined, and the potential sessions will be placed into the appropriate queue as defined by the requested weather criteria. Each session will be ranked in its specific queue on the basis of its associated data (e.g. is this session associated with a proposal that has already been started? what is its LST range?). At any time, the investigators will be able to see where their project sessions stand in the queue. Each project will have a web page associated with it, and any changes in the status of a session will be reflected in both the web page and via an email to the investigators. As an investigator's project sessions gets close to the top of the queue, the web page will be updated, and the investgators will be emailed to inform their project has a high probability of being run in the next few days. Note that one item which will strongly affect the project session's priority is whether an observer for the project is currently on-site, or has indicated that they will be available to observe remotely in the near future.

The Dynamic Scheduling System has the concept of a Telescope Period - a period of typically four hours during which the expectation is that a single observer will have control of the telescope. Telecope Period boundaries will be flexible, but generally chosen to match natural changes in observing capability - e.g. a Telescope Period might start at the end of a fixed maintenance day, and continue until late evening (when observing would typically switch to proposals which require benign night-time conditions). Approximately half an hour prior to the start of Telescope Period the Operator will run the DSS software. This will compare the short-term weather predictions, time, and hardware availability with the available sessions' data, and select subset of the highest-priority sessions in the relevant queue(s). The DSS will then display these candidate sessions in an easily readable form to the GBT Operator, who ultimately chooses the next Project session. Once that project is chosen, the operator will contact one of the project's ObservingContacts and inform him or her that his/her project will be running next and request that the observer begin preparations to run his/her observations. Once that project's Telescope Period is nearing completion, the operator will again consult the DSS in order to choose the next project/session. Note that in addition to listing the sessions which can be run based on the current weather, the DSS needs to be able to provide a look ahead probability to allow observers to know the probability of their sessions being run within the next few days/week(s).

In addition to the policies, algorithms, and scheduling software needed to select candidate sessions for observing, the DSS also needs to provide a suite of support software which will ease the use of the DSS for both observers and Green Bank staff. This suite of software is primarily geared toward satisfying all of the support operations that go with dynamic scheduling. Most importantly, this suite of software should engage the observer in the dynamic scheduling process and ensure that he/she knows what is happening with his or her project at any given moment. This software suite includes, but is not limited to: a means for an investigator/observer to know the probability of his/her project being run in the near future, a means of ready communication between the observer, operator, scheduling software, and investigator regarding ongoing, future, and past observations, and easy means for observers to change their contact information and availability.

To use the GBT's dynamic scheduling software (DSS) All - I would like to change DSS to be Dynamic Scheduling System to allow for it to include software, policies, and even recommendations, rather than being limited to just software. This would pave the way for a software release wherein the user is instructed to read a memo to determine what numbers to put into their data, with the memo being part of the DSS Sounds fine to me - AmyShelton , an investigator first must break his/her observations into discrete allocations, each of which is defined by a unique set of data, such as LST range, weather, needed hardware, etc. These data will be supplied by the project investigators and, while the DSS may recommend default values for that data (e.g. given the desired frequency range and right ascension/declination the DSS could recommend a certain LST or weather values), the data entered for each allocation will be set be the investigators, observers, and proposal selection committee, and not by the DSS itself. (Note that these allocations may be associated with specific observing blocks, but that association is known by the investigator(s) only and is not taken into account by the DSS in any form.) When called upon to do so, the DSS will analyze the data associated with all available allocations and attempt to select candidate allocations which are best suited to the current weather conditions and hardware configuration of the GBT. The DSS will then display these candidate allocations in an easily readable form to the GBT Operator, who ultimately chooses the next Project allocation. Once that project is chosen, the operator will contact one of the project's ObservingContacts and inform him or her that his/her project will be running next and request that the observer begin preparations to run his/her observations. Once that project's Telescope Period is nearing completion, the operator will again consult the DSS in order to choose the next project/allocation. I (RMP) Think there is something missing here. The above emaphasis on current weather conditions, with no mention of queues, implies that observers will be contacted with no advance warning. I think there is the concept that a small subset of all possible observers will already have been prepped that they might get selected, and this needs to be included in the overview description.

To use the GBT's dynamic scheduling system(DSS), an investigator first must break his/her observations into discrete allocations, each of which is defined by a unique set of data, such as LST range, weather, needed hardware, etc. These data will be supplied by the project investigators and, while the DSS may recommend default values for that data (e.g. given the desired frequency range and right ascension/declination the DSS could recommend a certain LST or weather values), the data entered for each allocation will be set be the investigators, observers, and proposal selection committee, and not by the DSS itself. (Note that these allocations may be associated with specific observing blocks, but that association is known by the investigator(s) only and is not taken into account by the DSS in any form.) When called upon to do so, the DSS will analyze the data associated with all available allocations and attempt to select candidate allocations which are best suited to the current weather conditions and hardware configuration of the GBT. The DSS will then display these candidate allocations in an easily readable form to the GBT Operator, who ultimately chooses the next Project allocation. Once that project is chosen, the operator will contact one of the project's ObservingContacts and inform him or her that his/her project will be running next and request that the observer begin preparations to run his/her observations. Once that project's Telescope Period is nearing completion, the operator will again consult the DSS in order to choose the next project/allocation. Note that in addition to listing the allocations which can be run based on the current weather, the DSS needs to be able to provide a look ahead probability to allow observers to know the probability of their allocations being run within the next few days/week(s).

To use the GBT's dynamic scheduling software (DSS) All - I would like to change DSS to be Dynamic Scheduling System to allow for it to include software, policies, and even recommendations, rather than being limited to just software. This would pave the way for a software release wherein the user is instructed to read a memo to determine what numbers to put into their data, with the memo being part of the DSS Sounds fine to me - AmyShelton , an investigator first must break his/her observations into discrete allocations, each of which is defined by a unique set of data, such as LST range, weather, needed hardware, etc. These data will be supplied by the project investigators and, while the DSS may recommend default values for that data (e.g. given the desired frequency range and right ascension/declination the DSS could recommend a certain LST or weather values), the data entered for each allocation will be set be the investigators, observers, and proposal selection committee, and not by the DSS itself. (Note that these allocations may be associated with specific observing blocks, but that association is known by the investigator(s) only and is not taken into account by the DSS in any form.) When called upon to do so, the DSS will analyze the data associated with all available allocations and attempt to select candidate allocations which are best suited to the current weather conditions and hardware configuration of the GBT. The DSS will then display these candidate allocations in an easily readable form to the GBT Operator, who ultimately chooses the next Project allocation. Once that project is chosen, the operator will contact one of the project's ObservingContacts and inform him or her that his/her project will be running next and request that the observer begin preparations to run his/her observations. Once that project's Telescope Period is nearing completion, the operator will again consult the DSS in order to choose the next project/allocation.

To use the GBT's dynamic scheduling software (DSS) All - I would like to change DSS to be Dynamic Scheduling System to allow for it to include software, policies, and even recommendations, rather than being limited to just software. This would pave the way for a software release wherein the user is instructed to read a memo to determine what numbers to put into their data, with the memo being part of the DSS Sounds fine to me - AmyShelton , an investigator first must break his/her observations into discrete allocations, each of which is defined by a unique set of data, such as LST range, weather, needed hardware, etc. These data will be supplied by the project investigators and, while the DSS may recommend default values for that data (e.g. given the desired frequency range and right ascension/declination the DSS could recommend a certain LST or weather values), the data entered for each allocation will be set be the investigators, observers, and proposal selection committee, and not by the DSS itself. (Note that these allocations may be associated with specific observing blocks, but that association is known by the investigator(s) only and is not taken into account by the DSS in any form.) When called upon to do so, the DSS will analyze the data associated with all available allocations and attempt to select candidate allocations which are best suited to the current weather conditions and hardware configuration of the GBT. The DSS will then display these candidate allocations in an easily readable form to the GBT Operator, who ultimately chooses the next Project allocation. Once that project is chosen, the operator will contact one of the project's ObservingContacts and inform him or her that his/her project will be running next and request that the observer begin preparations to run his/her observations. Once that project's Telescope Period is nearing completion, the operator will again consult the DSS in order to choose the next project/allocation. I (RMP) Think there is something missing here. The above emaphasis on current weather conditions, with no mention of queues, implies that observers will be contacted with no advance warning. I think there is the concept that a small subset of all possible observers will already have been prepped that they might get selected, and this needs to be included in the overview description.

It is critical that Observers retain control their observation in order to fully realize the scientific flexibility of the GBT. Therefore, the GBT's Dynamic Scheduling System will not run in a hands-off, queue observing mode but instead, once the telescope has been handed over to a given project, the Observer will have complete control over the GBT in the same manner as is currently done.

It is critical that Observers retain control of their observation in order to fully realize the scientific flexibility of the GBT. Therefore, the GBT's Dynamic Scheduling System will not run in a hands-off, queue observing mode but instead, once the telescope has been handed over to a given project, the Observer will have complete control over the GBT in the same manner as is currently done.

To use the GBT's dynamic scheduling software (DSS) All - I would like to change DSS to be Dynamic Scheduling System to allow for it to include software, policies, and even recommendations, rather than being limited to just software. This would pave the way for a software release wherein the user is instructed to read a memo to determine what numbers to put into their data, with the memo being part of the DSS Sounds fine to me - AmyShelton , an investigator first must break his/her observations into discrete allocations, each of which is defined by a unique set of data, such as LST range, weather, needed hardware, etc. This data will be supplied by the project investigators and, while the DSS may recommend default values for that data (e.g. given the desired frequency range and right ascension/declination the DSS could recommend a certain LST or weather values), the data entered for each allocation will be set be the investigators, observers, and proposal selection committee, and not by the DSS itself. (Note that these allocation may be associated with specific observing blocks, but that association is known by the investigator(s) only and is not taken into account by the DSS in any form.) When called upon to do so, the DSS will analyze the data associated with all available allocations and attempt to select candidate allocations which are best suited to the current weather conditions and hardware configuration of the GBT. The DSS will then display these candidate allocations in an easily readable form to the GBT Operator, who ultimately chooses the next Project allocation. Once that project is chosen, the operator will contact one of the project's ObservingContacts and inform him or her that his/her project will be running next and request that the observer begin preparations to run his/her observations. Once that project's Telescope Period is nearing completion, the operator will again consult the DSS in order to chose the next project/allocation.

To use the GBT's dynamic scheduling software (DSS) All - I would like to change DSS to be Dynamic Scheduling System to allow for it to include software, policies, and even recommendations, rather than being limited to just software. This would pave the way for a software release wherein the user is instructed to read a memo to determine what numbers to put into their data, with the memo being part of the DSS Sounds fine to me - AmyShelton , an investigator first must break his/her observations into discrete allocations, each of which is defined by a unique set of data, such as LST range, weather, needed hardware, etc. These data will be supplied by the project investigators and, while the DSS may recommend default values for that data (e.g. given the desired frequency range and right ascension/declination the DSS could recommend a certain LST or weather values), the data entered for each allocation will be set be the investigators, observers, and proposal selection committee, and not by the DSS itself. (Note that these allocations may be associated with specific observing blocks, but that association is known by the investigator(s) only and is not taken into account by the DSS in any form.) When called upon to do so, the DSS will analyze the data associated with all available allocations and attempt to select candidate allocations which are best suited to the current weather conditions and hardware configuration of the GBT. The DSS will then display these candidate allocations in an easily readable form to the GBT Operator, who ultimately chooses the next Project allocation. Once that project is chosen, the operator will contact one of the project's ObservingContacts and inform him or her that his/her project will be running next and request that the observer begin preparations to run his/her observations. Once that project's Telescope Period is nearing completion, the operator will again consult the DSS in order to choose the next project/allocation.

The goal of the Dynamic Scheduling Project is to increase the scheduling efficiency of the Green Bank Telescope (GBT) by allowing the telescope schedule to be optimally matched to both the current weather and the available instrumentation, while retaining observer control of each observation. In fact, it is critical that Observers retain control their observation in order to fully realize the scientific flexibility of the GBT. Therefore, the GBT's Dynamic Scheduling System will not run in a hands-off, queue observing mode but instead, once the telescope has been handed over to a given project, the Observer will have complete control over the GBT in the same manner as is currently done. The deliverables of the Dynamic Scheduling Project include all of the tools necessary to make dynamic scheduling the GBT possible. While developing these deliverables, we will strive to keep ease of use high for observers, investigators, and support staff.

The goal of the Dynamic Scheduling Project is to increase the scheduling efficiency of the Green Bank Telescope (GBT) by allowing the telescope schedule to be optimally matched to both the current weather and the available instrumentation, while retaining observer control of each observation.

To use the GBT's dynamic scheduling software (DSS) All - I would like to change DSS to be Dynamic Scheduling System to allow for it to include software, policies, and even recommendations, rather than being limited to just software. This would pave the way for a software release wherein the user is instructed to read a memo to determine what numbers to put into their data, with the memo being part of the DSS Sounds fine to me - AmyShelton , an investigator first must break his/her observations into discrete allocations, each of which is defined by a unique set of data, such as LST range, weather, needed hardware, etc. This data will be supplied by the project investigators and, while the DSS may recommend default values for that data (e.g. given the desired frequency range and right ascension/declination the DSS could recommend a certain LST or weather values), the data entered for each allocation will be set be the investigators, observers, and proposal selection committee, and not by the DSS itself. (These allocation may be associated with specific observing blocks, but that association is known by the investigator(s) only and is not taken into account by the DSS in any form.) When called upon to do so, the DSS will analyze the data associated with all available allocations and attempt to select candidate allocations which are best suited to the current weather conditions and hardware configuration of the GBT. The DSS will then display these candidate allocations in an easily readable form to the GBT Operator, who ultimately chooses the next Project allocation. Once that project is chosen, the operator will contact one of the project's ObservingContacts and inform him or her that his/her project will be running next and request that the observer begin preparations to run his/her observations. Once the current project's Telescope Period is nearing completion, the operator will again consult the DSS in order to chose the next project/allocation.

It is critical that Observers retain control their observation in order to fully realize the scientific flexibility of the GBT. Therefore, the GBT's Dynamic Scheduling System will not run in a hands-off, queue observing mode but instead, once the telescope has been handed over to a given project, the Observer will have complete control over the GBT in the same manner as is currently done.

In addition to the policies, algorithms, and scheduling software needed to select candidate allocations for observing, the DSS also needs to provide a suite of support software which will ease the use of the DSS for both observers and Green Bank staff. This suite of software is primarily geared toward satisfying all of the support operations that go with dynamic scheduling. Most importantly, this suite of software should engage the observer in the dynamic scheduling process and ensure that he/she knows what is happening with his or her project at any given moment. This software suite includes, but is not limited to: a means for an investigator/observer to know the probability of his/her project being run in the near future, a means of ready communication between the observer, operator, scheduling software, and investigator regarding ongoing, future, and past observations, and easy means for observers to change their contact information and availability, what else?

The deliverables of the Dynamic Scheduling Project include all of the tools necessary to make dynamic scheduling the GBT possible. While developing these deliverables, we will strive to keep ease of use high for observers, investigators, and support staff.

-- KarenONeil - 19 Mar 2007

To use the GBT's dynamic scheduling software (DSS) All - I would like to change DSS to be Dynamic Scheduling System to allow for it to include software, policies, and even recommendations, rather than being limited to just software. This would pave the way for a software release wherein the user is instructed to read a memo to determine what numbers to put into their data, with the memo being part of the DSS Sounds fine to me - AmyShelton , an investigator first must break his/her observations into discrete allocations, each of which is defined by a unique set of data, such as LST range, weather, needed hardware, etc. This data will be supplied by the project investigators and, while the DSS may recommend default values for that data (e.g. given the desired frequency range and right ascension/declination the DSS could recommend a certain LST or weather values), the data entered for each allocation will be set be the investigators, observers, and proposal selection committee, and not by the DSS itself. (Note that these allocation may be associated with specific observing blocks, but that association is known by the investigator(s) only and is not taken into account by the DSS in any form.) When called upon to do so, the DSS will analyze the data associated with all available allocations and attempt to select candidate allocations which are best suited to the current weather conditions and hardware configuration of the GBT. The DSS will then display these candidate allocations in an easily readable form to the GBT Operator, who ultimately chooses the next Project allocation. Once that project is chosen, the operator will contact one of the project's ObservingContacts and inform him or her that his/her project will be running next and request that the observer begin preparations to run his/her observations. Once that project's Telescope Period is nearing completion, the operator will again consult the DSS in order to chose the next project/allocation.

In addition to the policies, algorithms, and scheduling software needed to select candidate allocations for observing, the DSS also needs to provide a suite of support software which will ease the use of the DSS for both observers and Green Bank staff. This suite of software is primarily geared toward satisfying all of the support operations that go with dynamic scheduling. Most importantly, this suite of software should engage the observer in the dynamic scheduling process and ensure that he/she knows what is happening with his or her project at any given moment. This software suite includes, but is not limited to: a means for an investigator/observer to know the probability of his/her project being run in the near future, a means of ready communication between the observer, operator, scheduling software, and investigator regarding ongoing, future, and past observations, and easy means for observers to change their contact information and availability.

In addition to the policies, algorithms, and scheduling software needed to select candidate allocations for observing, the DSS also needs to provide a suite of support software which will ease the use of the DSS for both observers and Green Bank staff. This suite of software geared toward all of the support operations that go with dynamic scheduling. Most importantly, this suite of software is geared toward engaging the observer and ensuring that the observer knows what is happening with his or her project at any given moment. This software suite includes, but is not limited to: a means for an investigator/observer to know the probability of his/her project being run in the near future, a means of ready communication between the observer, operator, scheduling software, and investigator regarding ongoing, future, and past observations, and easy means for observers to change their contact information and availability, what else?

In addition to the policies, algorithms, and scheduling software needed to select candidate allocations for observing, the DSS also needs to provide a suite of support software which will ease the use of the DSS for both observers and Green Bank staff. This suite of software is primarily geared toward satisfying all of the support operations that go with dynamic scheduling. Most importantly, this suite of software should engage the observer in the dynamic scheduling process and ensure that he/she knows what is happening with his or her project at any given moment. This software suite includes, but is not limited to: a means for an investigator/observer to know the probability of his/her project being run in the near future, a means of ready communication between the observer, operator, scheduling software, and investigator regarding ongoing, future, and past observations, and easy means for observers to change their contact information and availability, what else?

The goal of the dynamic scheduling project is to increase the effiency of the Green Bank Telescope (GBT) through allowing telescope schedules to be optimally matched to the current weather and the available instrumentation, while still providing observer control over the ongoing observations. The dynamic scheduling project will provide all of the tools necessary to make dynamic scheduling the GBT possible and will make every attempt feasible to keep the ease of use high for observers, investigators, and support staff. To retain flexibility, the GBT's dynamic scheduling system will not run in a hands-off, queue observing mode but instead once the telescope has been handed over to a given project, the Observer will have complete control over the GBT in the same manner as is currently done.

The goal of the Dynamic Scheduling Project is to increase the scheduling efficiency of the Green Bank Telescope (GBT) by allowing the telescope schedule to be optimally matched to both the current weather and the available instrumentation, while retaining observer control of each observation. In fact, it is critical that Observers retain control their observation in order to fully realize the scientific flexibility of the GBT. Therefore, the GBT's Dynamic Scheduling System will not run in a hands-off, queue observing mode but instead, once the telescope has been handed over to a given project, the Observer will have complete control over the GBT in the same manner as is currently done. The deliverables of the Dynamic Scheduling Project include all of the tools necessary to make dynamic scheduling the GBT possible. While developing these deliverables, we will strive to keep ease of use high for observers, investigators, and support staff.

To use the GBT's dynamic scheduling software (DSS) All - I would like to change DSS to be Dynamic Scheduling System to allow for it to include software, policies, and even recommendations, rather than being limited to just software. This would pave the way for a software release wherein the user is instructed to read a memo to determine what numbers to put into their data, with the memo being part of the DSS, an investigator first must break his/her observations into discrete allocations, each of which is defined by a unique set of data, such as LST range, weather, needed hardware, etc. This data will be supplied by the project investigators and, while the DSS may recommende values for that data (e.g. given the desired frequency range and right ascension/declination the DSS could recomend a certain LST or weather values), the data entered for each allocation will be set be the investigators, observers, and proposal selection committee, and not by the DSS itself. (These allocation may be associated with specific observing blocks, but that association is known by the investigator(s) only and is not taken into account by the DSS in any form.) When called upon to do so, the DSS will analyze the data associated with all available allocation and attempt to chose the allocations which are best suited to the current weather conditions and hardware configuration of the GBT. The DSS will then display these allocations on an easily readable screen, and the GBT Operator will choose from the suggested allocations to decide which Project should be run next. Once that project is chosen, the operator will get in touch with one of the project's ObservingContacts to inform him or her that his/her project will be running next and to request the observer begin preparations to run his/her observations. Once the current project's Telescope Period is nearing completion, the operatpr will re-run the DSS to chose the next project/allocation.

To use the GBT's dynamic scheduling software (DSS) All - I would like to change DSS to be Dynamic Scheduling System to allow for it to include software, policies, and even recommendations, rather than being limited to just software. This would pave the way for a software release wherein the user is instructed to read a memo to determine what numbers to put into their data, with the memo being part of the DSS Sounds fine to me - AmyShelton , an investigator first must break his/her observations into discrete allocations, each of which is defined by a unique set of data, such as LST range, weather, needed hardware, etc. This data will be supplied by the project investigators and, while the DSS may recommend default values for that data (e.g. given the desired frequency range and right ascension/declination the DSS could recommend a certain LST or weather values), the data entered for each allocation will be set be the investigators, observers, and proposal selection committee, and not by the DSS itself. (These allocation may be associated with specific observing blocks, but that association is known by the investigator(s) only and is not taken into account by the DSS in any form.) When called upon to do so, the DSS will analyze the data associated with all available allocations and attempt to select candidate allocations which are best suited to the current weather conditions and hardware configuration of the GBT. The DSS will then display these candidate allocations in an easily readable form to the GBT Operator, who ultimately chooses the next Project allocation. Once that project is chosen, the operator will contact one of the project's ObservingContacts and inform him or her that his/her project will be running next and request that the observer begin preparations to run his/her observations. Once the current project's Telescope Period is nearing completion, the operator will again consult the DSS in order to chose the next project/allocation.

In addition to the software, algorithms, and policies needed to select the next set of allocation candidates for observing, the DSS also needs to provide a suite of software which will ease the use of the DSS for both observers and Green Bank staff. This includes, but is not limited to: a means for an investigator/observer to know the probability of his/her project being run in the near future, a means of ready communication between the observer, operator, scheduling software, and investigator regarding ongiong, future, and past observations, and easy means for observers to change their contact information and availability, what else?

In addition to the policies, algorithms, and scheduling software needed to select candidate allocations for observing, the DSS also needs to provide a suite of support software which will ease the use of the DSS for both observers and Green Bank staff. This suite of software geared toward all of the support operations that go with dynamic scheduling. Most importantly, this suite of software is geared toward engaging the observer and ensuring that the observer knows what is happening with his or her project at any given moment. This software suite includes, but is not limited to: a means for an investigator/observer to know the probability of his/her project being run in the near future, a means of ready communication between the observer, operator, scheduling software, and investigator regarding ongoing, future, and past observations, and easy means for observers to change their contact information and availability, what else?

To use the GBT's dynamic scheduling software (DSS) All - I would like to change DSS to be Dynamic Scheduling System to allow for it to include software, policies, and even recommendations, rather than being limited to just software. This would pave the way for a software release wherein the user is instructed to read a memo to determine what numbers to put into their data, with the memo being part of the DSS, an investigator first must break his/her observations into discrete allocations, each of which is defined by a unique set of data, such as LST range, weather, needed hardware, etc. This data will be supplied by the project investigators and, while the DSS may recommende values for that data (e.g. given the desired frequency range and right ascension/declination the DSS could recomend a certain LST or weather values), the data entered for each allocation will be set be the investigators, observers, and proposal selection committee, and not by the DSS itself. (These allocation may be associated with specific observing blocks, but that association is known by the investigator(s) only and is not taken into account by the DSS in any form.) When called upon to do so, the DSS will analyze the data associated with all available allocation and attempt to chose the allocations which are best suited to the current weather conditions and hardware limitations of the GBT. The DSS will then display these allocations on an easily readable screen, and the GBT Operator will choose from the suggested allocations to decide which Project should be run next. Once that project is chosen, the operator will get in touch with one of the project's ObservingContacts to inform him or her that his/her project will be running next and to request the observer begin preparations to run his/her observations. Once the current project's Telescope Period is nearing completion, the operatpr will re-run the DSS to chose the next project/allocation.

To use the GBT's dynamic scheduling software (DSS) All - I would like to change DSS to be Dynamic Scheduling System to allow for it to include software, policies, and even recommendations, rather than being limited to just software. This would pave the way for a software release wherein the user is instructed to read a memo to determine what numbers to put into their data, with the memo being part of the DSS, an investigator first must break his/her observations into discrete allocations, each of which is defined by a unique set of data, such as LST range, weather, needed hardware, etc. This data will be supplied by the project investigators and, while the DSS may recommende values for that data (e.g. given the desired frequency range and right ascension/declination the DSS could recomend a certain LST or weather values), the data entered for each allocation will be set be the investigators, observers, and proposal selection committee, and not by the DSS itself. (These allocation may be associated with specific observing blocks, but that association is known by the investigator(s) only and is not taken into account by the DSS in any form.) When called upon to do so, the DSS will analyze the data associated with all available allocation and attempt to chose the allocations which are best suited to the current weather conditions and hardware configuration of the GBT. The DSS will then display these allocations on an easily readable screen, and the GBT Operator will choose from the suggested allocations to decide which Project should be run next. Once that project is chosen, the operator will get in touch with one of the project's ObservingContacts to inform him or her that his/her project will be running next and to request the observer begin preparations to run his/her observations. Once the current project's Telescope Period is nearing completion, the operatpr will re-run the DSS to chose the next project/allocation.

The goal of the dynamic scheduling project is to increase the effiency of the Green Bank Telescope (GBT) through allowing telescope schedules to be optimally matched to the current weather and the available instrumentation while still providing observer control over the ongoing observations. The dynamic scheduling project will provide all of the tools necessary to make dynamic scheduling the GBT possible and will make every attempt feasible to keep the ease of use high for observers, investigators, and support staff.

The goal of the dynamic scheduling project is to increase the effiency of the Green Bank Telescope (GBT) through allowing telescope schedules to be optimally matched to the current weather and the available instrumentation, while still providing observer control over the ongoing observations. The dynamic scheduling project will provide all of the tools necessary to make dynamic scheduling the GBT possible and will make every attempt feasible to keep the ease of use high for observers, investigators, and support staff. To retain flexibility, the GBT's dynamic scheduling system will not run in a hands-off, queue observing mode but instead once the telescope has been handed over to a given project, the Observer will have complete control over the GBT in the same manner as is currently done.

To use the GBT's dynamic scheduling software (DSS) All - I would like to change DSS to be Dynamic Scheduling System to allow for it to include software, policies, and even recommendations, rather than being limited to just software. This would pave the way for a software release wherein the user is instructed to read a memo to determine what numbers to put into their data, with the memo being part of the DSS, an investigator first must break his/her observations into discrete allocations, each of which is defined by a unique set of data, such as LST range, weather, needed hardware, etc. This data will be supplied by the project investigators and, while the DSS may recommende values for that data (e.g. given the desired frequency range and right ascension/declination the DSS could recomend a certain LST or weather values), the data entered for each allocation will be set be the investigators, observers, and proposal selection committee, and not by the DSS itself. (These allocation may be associated with specific observing blocks, but that association is known by the investigator(s) only and is not taken into account by the DSS in any form.) When called upon to do so, the DSS will analyze the data associated with all available allocation and attempt to chose the allocations which are best suited to the current weather conditions and hardware limitations of the GBT. The DSS will then display these allocations on an easily readable screen, and the GBT Operator will choose from the suggested allocations to decide which Project should be run next. Once that project is chosen, the operator will get in touch with one of the project's ObservingContacts to inform him or her that his/her project will be running next and to request the observer begin preparations to run his/her observations. Once the current project's Telescope Period is nearing completion, the operatpr will re-run the DSS to chose the next project/allocation.

In addition to the software, algorithms, and policies needed to select the next set of allocation candidates for observing, the DSS also needs to provide a suite of software which will ease the use of the DSS for both observers and Green Bank staff. This includes, but is not limited to: a means for an investigator/observer to know the probability of his/her project being run in the near future, a means of ready communication between the observer, operator, scheduling software, and investigator regarding ongiong, future, and past observations, and easy means for observers to change their contact information and availability, what else?

-- KarenONeil - 16 Mar 2007

-- KarenONeil - 19 Mar 2007

%META:TOPICINFO{author="KarenONeil" date="1174074005" format="1.0" version="1.1"}%

Summary of GBT Dynamic Scheduling Project

The goal of the dynamic scheduling project is to increase the effiency of the Green Bank Telescope (GBT) through allowing telescope schedules to be optimally matched to the current weather and the available instrumentation while still providing observer control over the ongoing observations. The dynamic scheduling project will provide all of the tools necessary to make dynamic scheduling the GBT possible and will make every attempt feasible to keep the ease of use high for observers, investigators, and support staff.

-- KarenONeil - 16 Mar 2007