Milestones

Major Milestones

Flow Charts

• Flow Chart for DSS Tests

Flow Charts

• Flow Chart for DSS Tests

%META:FILEATTACHMENT{name="DSS_Test_list_v3.pdf" attr="h" comment="Flow Chart for DSS Tests" date="1184683432" path="DSS_Test_list_v3.pdf" size="26101" user="KarenONeil" version="1.2"}%

Goals, Objectives, and Schedule

Schedule

Goals

• Long term goal is to have true dynamic scheduling on the GBT which eases the support burden and which results in high frequency projects being completed more rapidly than is currently (2006) possible.
• All telescope activities, including science, commissioning, tests and maintenance are flexibly scheduled to:
  • Optimize use of high-frequency weather.
  • Enable timely completion of projects.
• Achieve efficient fixed scheduling of crucial maintenance activities, VLBI/bi-static radar or other observations that require coordination with other facilities, and monitoring projects.

Description of Stages

Objectives

• Demonstrate increased flexibility from previous manual dynamic scheduling approach
  • High frequency projects should be completed more rapidly than is currently occurring
  • Project run should better match weather conditions
• Demonstrate increased flexibility from previous software tools and applications
  • Eliminate GO as a production tool by October 1, 2005. DONE
• Ease the burden of the GBT scheduler in matching weather conditions

Schedule

Description of Stages

Stage I

• This is the proof of concept stage

Stage I - Concept Development

Stage II

Stage II - Proof of Concept

Stage III

Stage III - First Release

Stage IV

Stage IV - Second Release

Milestones

Milestones

• • Primary Tests:
    • Dynamic Scheduling System policies
    • Session selection rules and weights
    • Scheduling predictions and look ahead
    • Conceptual software suite
  • Secondary Tests:
    • Proposal information page
    • Ease of user contact

Note that all milestones have slipped due to having fewer resources on the project than anticipated.

-- KarenONeil - 02 May 2006

• All observations are performed by the execution of Scheduling Blocks (SBs) which have been defined in advance.

• • High frequency projects should be completed more rapidly than is currently occuring - Is there a metric we can use to judge this?
  • We should have fewer problems finding sufficient low frequency projects for the telescope - Is there a metric we can use to judge this?

• • High frequency projects should be completed more rapidly than is currently occurring
  • Project run should better match weather conditions

• • Other???

• Ease the burden of the GBT scheduler in matching weather conditions

Description of Stages

Develop Phase I Proposal:

• Interface with JCMT, other telescopes to determine dynamic scheduling "lessons"
• Determine all selection requirements
• Complete strawman proposal for dynamic scheduling system
• Present proposals to the GB staff and 2 outside observers (1 LF anf 1 HF) for comments.
• Modify strawman proposal based on comments receive

Build Stage I System (Summer/Fall/Early Winter 2006)

• Write all software needed for the 2006/2007 tests. Note that all software for tests should be considered prototype and will be rewritten for Stage II. As such, this software could be very simplistic.:
  • Prototype query tool
  • Prototype time accounting tool
  • Prototype Metadata tool
  • Prototype User/Staff Feedback tool
• Train select group of astronomers (and operators) for using Stage I system
• Write documentation for all weather queue information
• This includes determining all weather and other (e.g. project observability, hardware requirements, etc) requirements for each project. Also in Cycle 6-7 we will choose a subset for projects for testing dynamic scheduling, get agreement from observers; begin training staff as needed
• Begin operator training for, e.g. running receiver checkouts and doing pointing runs to familiarize them with the software

Test Stage I (Winter 2006/2007)

• Choose a subset of projects for Phase I testing, get observer's agreement
• We should choose 2 two week periods for the tests, seperated by approximately 1 month; ideally these tests will be somtime between December - early febuary
• The system will be run as outlined in the proposal, with the exception that an extra person will be on hand at all times to insure that the dynamic scheduling program runs accurately and the system is running as it should be.

Redesign Proposal for Stage II (Winter - Spring 2007)

• Redesign should begin as soon as tests are underway
• Proposal for completion of redesign should be written as soon as possible after the tests
• External review should happen in by June
• Proposal will be sent to all NRAO staff at this time also
• During this time the PST must be re-designed to accomodate any metadata needed in the proposing process (e.g. weather queue info)

Build Stage II System (Spring - Fall 2007)

• Rebuilding of system should begin as soon as possible
• Must be complete by Feb 1, 2008, with prototypes (at least) in place by Fall, 2007
• Will include all necessary software for dynamic scheduling
• Will likely not include all desired software for dynamic scheduling

Test Stage II (Fall/Winter 2007)

• The Feb 1 proposal period should include all information needing for dynamic scheduling
• Proposers should be asked if they would like to participate in testing in the fall

Begin Dynamic Scheduling (Winter 2007 - onwards)

• The Oct 1 call for proposals should state that all proposals will be dynamically scheduled

Redesign Proposal for Stage III (Spring 2008)

• This may include removing most peak, focus, and even calibration observations from the project SBs
• Will include the addition of ease of use software

Stage I

• This is the proof of concept stage
• This stage will consist of prototype software used to simulate and test the basic concepts behind dynamic scheduling
• During this stage we will also develop all documentation needed to continue on to Stage II
• This stage will end with an external review of the project plans

Stage II

• This will be the first real test of the dynamic scheduling software
• The tests need to involve a large number and variety of projects to insure the DSS is accurately tested
• As with all stages, simulations will also play a large role here

Stage III

• The goal here is to complete all tools needed to begin dynamic scheduling on the GBT
• At this point there will likely be many tools and additions which are desired for ease-of-use, but which are not necessary for the system to work

Stage IV

• This will be modifications and additions to the Stage III DSS
• The complete description of desired changes and additions will be made once Stage III has been run for at least 1 semester
• During this stage we will also implement the highest priority items remaining from the ease-of-use list

Build Stage III System (Summer-Fall 2008?)

• Completing any/all issues for the complete software suite:

Milestones

Test Stage III (Fall/Winter 2008?)

Release Stage III (Winter 2009?)

• Long term goal is to have true dynamic scheduling on the GBT which eases the support burden and which results in high frequency projects being completed more rapidly than is currently (2005) possible.

• Long term goal is to have true dynamic scheduling on the GBT which eases the support burden and which results in high frequency projects being completed more rapidly than is currently (2006) possible.

Build Stage I System (Summer/Fall 2006)

Build Stage I System (Summer/Fall/Early Winter 2006)

• Proposal for completion of redesign should be written by mid-March
• External review should happen in late March

• Proposal for completion of redesign should be written as soon as possible after the tests
• External review should happen in by June

Build Stage II System (Spring - Summer 2007)

• Rebuilding of system should begin April 1
• Must be complete by Oct 1
• Software needed for Stage II are version 1 of:
  • Query Tool
  • Time Accounting Tool
  • Web fedback page
  • Metadata tool
  • Running SBs Tool
  • Observer/Staff Feedback Tool
• Software desired for Stage II:
  • Tool for building SBs
  • Observing Log
  • Time Accounting Tool - complete version

Build Stage II System (Spring - Fall 2007)

• Rebuilding of system should begin as soon as possible
• Must be complete by Feb 1, 2008, with prototypes (at least) in place by Fall, 2007
• Will include all necessary software for dynamic scheduling
• Will likely not include all desired software for dynamic scheduling

Test Stage II (Fall 2007)

• The June 1 proposal period should include all information needing for dynamic scheduling

Test Stage II (Fall/Winter 2007)

• The Feb 1 proposal period should include all information needing for dynamic scheduling

• Will include the addition of ease of use software

• Tool for building SBs
  • Query Tool
  • Observing Log
  • Time Accounting Tool
  • Web fedback page
  • Metadata tool
  • Data Reduction
  • Quick Look Data Display
  • Running SBs Tool
  • Observer/Staff Feedback tools

Test Stage III (Fall 2008?)

Test Stage III (Fall/Winter 2008?)

Release Stage III (Winter 2008?)

Release Stage III (Winter 2009?)

Dynamic Scheduling Tasks

Goals, Objectives, and Schedule

Goals

• Long term goal is to have true dynamic scheduling on the GBT which eases the support burden and which results in high frequency projects being completed more rapidly than is currently (2005) possible.
• All telescope activities, including science, commissioning, tests and maintenance are flexibly scheduled to:
  • Optimize use of high-frequency weather.
  • Enable timely completion of projects.
• Achieve efficient fixed scheduling of crucial maintenance activities, VLBI/bi-static radar or other observations that require coordination with other facilities, and monitoring projects.
• All observations are performed by the execution of Scheduling Blocks (SBs) which have been defined in advance.

Objectives

• Demonstrate increased flexibility from previous manual dynamic scheduling approach
  • High frequency projects should be completed more rapidly than is currently occuring - Is there a metric we can use to judge this?
  • We should have fewer problems finding sufficient low frequency projects for the telescope - Is there a metric we can use to judge this?
• Demonstrate increased flexibility from previous software tools and applications
  • Eliminate GO as a production tool by October 1, 2005. DONE
  • Other???

Schedule

• Proposal will be sent to all NRAO staff at this time also

• • Prototype User/Staff Feedback tool

• • Observer/Staff Feedback Tool

• • Observer/Staff Feedback tools

• Write all software needed for the 2006/2007 tests:

• Write all software needed for the 2006/2007 tests. Note that all software for tests should be considered prototype and will be rewritten for Stage II. As such, this software could be very simplistic.:

• This includes determining all weather and other (e.g. project observability, hardware requirements, etc) requirements for each project. Also in Cycle 7 we will choose a subset for projects for testing dynamic scheduling, get agreement from observers; begin training staff as needed

• Write documentation for all weather queue information
• This includes determining all weather and other (e.g. project observability, hardware requirements, etc) requirements for each project. Also in Cycle 6-7 we will choose a subset for projects for testing dynamic scheduling, get agreement from observers; begin training staff as needed

• We should choose 2 two week periods for the tests, seperated by approximately 1 month; ideally these tests will be in mid-january and mid-febuary

• We should choose 2 two week periods for the tests, seperated by approximately 1 month; ideally these tests will be somtime between December - early febuary

• During this time the PST must be re-designed to acomoadate all information needed for dynamic scheduling

• During this time the PST must be re-designed to accomodate any metadata needed in the proposing process (e.g. weather queue info)

• Write all software needed for the 2006/2007 tests
• Train select group of astronomers (and oeprators?) for using Phase I
• This includes determinetermine ing all weather and other (e.g. project observability, hardware requirements, etc) requirements for each project. Also in Cycle 7 we will choose a subset for projects for testing dynamic scheduling, get agreement from observers; begin training staff as needed

• Write all software needed for the 2006/2007 tests:
  • Prototype query tool
  • Prototype time accounting tool
  • Prototype Metadata tool
• Train select group of astronomers (and operators) for using Stage I system
• This includes determining all weather and other (e.g. project observability, hardware requirements, etc) requirements for each project. Also in Cycle 7 we will choose a subset for projects for testing dynamic scheduling, get agreement from observers; begin training staff as needed

• Software needed for Stage II are version 1 of:
  • Query Tool
  • Time Accounting Tool
  • Web fedback page
  • Metadata tool
  • Running SBs Tool
• Software desired for Stage II:
  • Tool for building SBs
  • Observing Log
  • Time Accounting Tool - complete version

* Completing any/all issues for the complete software suite:

• • Tool for building SBs
  • Query Tool
  • Observing Log
  • Time Accounting Tool
  • Web fedback page
  • Metadata tool
  • Data Reduction
  • Quick Look Data Display
  • Running SBs Tool

• Complete proposal for testing the system in the 2006/2007 winter season

• We should choose 2 two week periods for the tests, seperated by approximately 1 month; ideally these tests will be in mid-january and mid-febuary
• The system will be run as outlined in the proposal, with the exception that an extra person will be on hand at all times to insure that the dynamic scheduling program runs accurately and the system is running as it should be.

• External review should happen about mid-way through this

• Redesign should begin as soon as tests are underway
• Proposal for completion of redesign should be written by mid-March
• External review should happen in late March
• During this time the PST must be re-designed to acomoadate all information needed for dynamic scheduling

• Rebuilding of system should begin April 1
• Must be complete by Oct 1

• The June 1 proposal period should include all information needing for dynamic scheduling
• Proposers should be asked if they would like to participate in testing in the fall

• The Oct 1 call for proposals should state that all proposals will be dynamically scheduled

• Begin operator training for, e.g. running receiver checkouts and doing pointing runs to familiarize them with the software

• This may include removing most peak, focus, and even calibration observations from the project SBs

• Interface with JCMT, other telescopes to determine synamic scheduling "lessons"

• Interface with JCMT, other telescopes to determine dynamic scheduling "lessons"

Dynamic Scheduling Tasks

Dynamic Scheduling Tasks

• Present proposals to the GB staff for comments.

• Present proposals to the GB staff and 2 outside observers (1 LF anf 1 HF) for comments.

Build Phase I System

Build Stage I System (Summer/Fall 2006)

Test Phase I

Test Stage I (Winter 2006/2007)

Redesign Proposal for Phase II

Redesign Proposal for Stage II (Winter - Spring 2007)

• External review should happen about mid-way through this

Build Phase II System

Build Stage II System (Spring - Summer 2007)

Test Phase II

Test Stage II (Fall 2007)

Begin Dynamic Scheduling

Begin Dynamic Scheduling (Winter 2007 - onwards)

Redesign Proposal for Stage III (Spring 2008)

Build Stage III System (Summer-Fall 2008?)

Test Stage III (Fall 2008?)

Release Stage III (Winter 2008?)

We have no external review scheduled. Should we do this (probably)? When?

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

Dynamic Scheduling Tasks

• Dynamic Scheduling Tasks
  • Develop Phase I Proposal:
  • Build Phase I System
  • Test Phase I
  • Redesign Proposal for Phase II
  • Build Phase II System
  • Test Phase II
  • Begin Dynamic Scheduling

Develop Phase I Proposal:

• Interface with JCMT, other telescopes to determine synamic scheduling "lessons"
• Determine all selection requirements
• Complete strawman proposal for dynamic scheduling system
• Complete proposal for testing the system in the 2006/2007 winter season
• Present proposals to the GB staff for comments.
• Modify strawman proposal based on comments receive

Build Phase I System

• Write all software needed for the 2006/2007 tests
• Train select group of astronomers (and oeprators?) for using Phase I
• This includes determinetermine ing all weather and other (e.g. project observability, hardware requirements, etc) requirements for each project. Also in Cycle 7 we will choose a subset for projects for testing dynamic scheduling, get agreement from observers; begin training staff as needed

Test Phase I

• Choose a subset of projects for Phase I testing, get observer's agreement

Redesign Proposal for Phase II

Build Phase II System

Test Phase II

Begin Dynamic Scheduling

We have no external review scheduled. Should we do this (probably)? When?

-- KarenONeil - 02 May 2006