NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Dynamic > OldExamples
   Changes | Index | Search | Go

Example 7 - Survey project

NOTE: This example has been deprecated, until it's use of Weather Bins has been changed to reflect the latest work in the Memos on Scientific Requirements and Stringency

Sarah Connor, from the University of Terminus, submits a proposal to survey OH (at L-band) and H2O (at K-band) masers toward a new class of radio stars. The masers, if present, are expected to be very bright if masing and easy to detect. The duty cycle is low, however, and therefore she wishes to observe each object 10 times for an integration period of 60 seconds in each transition. If a maser is detected she will follow-up with VLBI to image the maser region. She has 100 sources distributed uniformly at all LST ranges. Sarah's observing strategy is to move from source to source across the sky, tracking the target source for 60 seconds while frequency switching. At L-band tonly one pointing per night is needed. At K-band she needs to point and will try to use one pointing calibrator for several target sources when possible to limit the overhead. She wants the time between observing the same source to be at least 1 day. The total time on source is rather small: 100 sources x 2 transitions x 60 seconds = 3.3 hours. But there is a lot of overhead. A fast balancing would be handy smile

Her proposal is accepted. The TAC gives her all of the time and rates the proposal with a B grade. Sarah is the L. Hamilton chair for theoretical astrophysics. Although she has a busy schedule she plans to be involved in the observing. She has one postdoc, Kyle Reese, who will help her with the observations. She enters the Allocation data into the database.

The weather classifications for L and K-band are shown below. Basically she can tolerate the worst weather conditions at L-band. At K-band the wind is somewhat important since the target objects are point sources but since the lines should be bright she can tolerate reasonably poor Tsys values for K-band.

*Weather Classifications (See WeatherQueue) *
Wind/’Tsys’ 0%-25% 25%-50% 50%-75% 75%-100%
Excellent        
Good     K  
Poor       L

Given the constraints of this survey Sarah and Kyle will need to be scheduled over many days, even though the total time is not very large. At the very least they will require 10 Telescope Periods (TPs). Probably more since (1) depending on the overhead they probably will not be able to observe all 100 sources in one TP since not all of the sources will be above the horizon over the timescale it takes to observe them all; and (2) the weather conditions may not allow them to observe both L and K-band transitions in the same TP.

Given our proposed dynamic scheduling scheme I can image that this observing would take quite a while to perform, possibly the entire trimester. They would be contacted many times by NRAO to be ready for observing. The overhead of e-mail and phone calls might be significant. Even our ardent observers, Sarah and Kyle, might tire of this project and desire that the central computer system take over for them.

If we scheduled this project in the traditional way with Fixed Times we would probably give Sarah and Kyle time periods spread out over 10 days with maybe two periods per day. This would still be a lot of work since they would have to startup 20 times. So they would be busy those 10 days but they would not have to worry about observing for the rest of the trimester. The overhead would be less and they could focus on other projects.

Nevertheless, Sarah and Kyle work hard and finish the project and plan to BE BACK.

Example 8 – PF Feed Changes

As a simplistic example, lets assume we have projects for only two of the Prime Focus Feeds (PF400 and PF800), two monitoring projects (A, which needs PF400 & B which needs PF800), and then a few other (not monitoring) projects which also need the PF feeds (C & D need PF400, F, G, & H need PF800). Further, assume project A has to run between the 10th-13th of each month and Project B has to run between the 20th-30th of each month. Finally, assume its the 1st of the month and PF400 is up. At this point we already know that PF800 will go up between the 13-20 of the month. Since we have multiple projects that use both feeds, and to insure that we do indeed get the PF800 up in time, we can narrow this down and make the PF feed change a fixed window allocation which must occur in good (but not great) weather during the work week, which we will set here to be the 14th-19th of the month. As the 14th draws near, whomever is in charge of making the decision for feed changes could either (1) just keep the window open for when the feed change occurs, (2) tie the feed change to a fixed time, or (3) narrow the range of days for the feed change to just a couple days from the original five. Once the feed change occurs, only PF800 projects will run. This sort of decision will have to be made between each of the monitoring projects. And, you can imagine a scenario where all, say, PF400 projects get completed except the monitoring project, in which can the feed changes would occur just before and just after project A runs.

Note that the above example is about as complicated as it gets. In many cases the PF feed changes will simply occur on the week's maintenance days. In the summertime these will be fixed days, making scheduling activities very easy. During the winter these will likely be scheduled as two fixed window allocations where the [Dynamic.DynamicSchedulingGlossary#FixedWindow][fixed window]] is just the five work days. The actual day these occur could be decided on the fly (like most dynamic scheduling decisions), or if advance notice is needed, someone(s) could look at the weather a day in advance and, when the weather appears appropriate, that person could make the next day a fixed day for maintenance.

Example 9 - Maintanence Activities

The following example attempts to show how the definitions and metadata inputs for Fixed Time and Fixed Window Allocations can be used to sucessfully schedule Maintanence Activities.

The first 2 weeks of a summer month (June) needs two 8 hour maintance days per work week, between 8 AM and 4 PM. The person responsible for entering these requests into the Dynamic Scheduling Software (DSS) (typically the head of telescope operations) understands that there is more then one way to do this. They decide to use the following approach. For all maintanence day Allocations, the Minimum Time and Total Times are 8.0 hours. Four Allocations are created with the following Fixed Window metadata:

If they wished to run this for, say, an entire trimester (12 week period), they could just have:

The third week in June is more complicated. On the Tuesday of that week, an outside contractor is coming for the workday to inspect aspects of the Antenna, an inspection which will take only 4 hours. For this reason, Tuesday must be a Fixed Time maintainence day, while the second maintanence day of the week can be scheduled any other day. The Allocations created just for that week look like this:

The fourth week in June, we need a PF receiver change at the beginning of the week (Monday). This, comnbined needs to combine with other maintenance activities to equal two full maintenance days. Here are the Allocations for this week:

Monday, June 23 has great weather, so other project Allocations are scheduled in the morning. At 8 AM, a 4 hour TP starts with a project session. At noon, another 2 hour TP starts with another project session. By 2 PM the weather has slightly degraded, and the observer gives up his/her time so another TP must be started. The operator sees that there are many good Allocation canidates for filling in the next ~4 hours of telescope time, but the DSS informs them that at 4 PM the PF Receiver Change Allocation will become a Fixed Time. With this information, the operator decides to get the PF Receiver Change out of the way and schedules its Allocation for 2 PM. The change is successful, and another TP is started at 4 PM.

Example 3 - Time Period Boundaries

NOTE: This example has been deprecated, until it's use of Weather Bins and LST ranges has been changed to reflect the latest work in the Memos on Scientific Requirements and Stringency

All times in this example are EST and run from 3:00 PM on Monday (3p) until 11:00 AM on Tuesday (11a). The current time is 8:30 PM on Monday (8.5p) and the current time period started at 5p and runs until 9p at the thermal-transition. The session is allocated from a B graded project which is 85% complete and whose associated Allocation (A7) for the current session requires Tsys 50-75 and excellent wind (50-75/E) and can run anytime. (See WeatherQueue for details regarding Tsys and wind.) Its LST range (in EST) is 5p to 1a. The current weather is, as predicted, 50-75/E. Day/night transition is 9p and night/day transition is 7a. A Fixed Time session from Allocation A8 is scheduled for 9a.

The weather predictions are:

Time (EST) current 11p 2a 5a 8a
Tsys/Wind 50-75/E 25-50/E 25-50/G 0-25/G 0-25/P

The candidate Allocations are (note the current project A7 is still a candidate):

Allocation LST range (in EST) Tsys/Wind % complete Grade Day/Night/Any
A7 5p - 1a 50-75/E 91% B Any
A5 5p - 2a 50-75/E 73% B Any
A6 6p - 8a 50-75/G 10% B Any
A4 3p - 1a 25-50/G 55% A Any
A1 9p - 6a 25-50/G 40% A Night
A2 3p - 11p 25-50/G 45% B Night
-
A3 10p - 9a 25-50/E 90% A Night

All the Allocations are from the current semester, the observers are not on site, and are not thesis projects. They are listed in priority order according to the selection rules, highest first. Strictly speaking, A3 should not even be listed until 10p given its LST range, but it is an example of the need to look ahead and adjust the boundaries of time periods to allow for better scheduling.

Notes:

In this case, the telescope operator is likely to see that it would be highly advantageous to run project A4. Thus, even though the Dynamic Scheduling Software (DSS) did not give the operator a heads up in this case, the operator would likely choose to simply extend A7 until 10pm and then begin a new TP with A3. This is a great example to show where it would be advantageous to have the DSS look ahead and help the telescope operator with these decisions.

We should remove this example. By some mechanism (human intervention, whatever), we should not allow projects which do not have some sort of valid Observing Blcok to get on the telescope. If nothing else, the "friends" should be looking at the proposals which are near the top of the queue, and makign sure they have valid Observing Blocks. In principle, this example shouldn't happen now, so we certainly shouldn't suggest it can happen in the future.

The example could be salvaged by proposing equipment failure which happens during, or immediately prior to the observations in question, so that the SBs have to be modified, or whatever.

Example 4 – Bah Humbug

In May, Maggie Astronomer writes a proposal and makes a request for 48 hours of telescope time to observe a new pulsar using the PF2 receiver at 940.0 MHz. She submits the proposal in advance of the June 1st semester deadline, requiring only poor weather, and any time observations. The proposal is refereed and assessed at the August Telescope Scheduling Meeting. The proposal is accepted, with a time Allocation of 48 hours, as a "B" proposal. Upon notification of her successful Allocation of time, in September Maggie prepares 1 Allocation. The Allocation consists of a configuration, specifying that she will need the spigot, cgsr2 and gasp back ends. She does not specify any unavailable times but lists 3 different telephone numbers where she can be reached. One telephone number for November, one for December, and one for January and February. She also completes her Observing Blocks (OBs) but finds she can not validate them because the config tool reports that it can not route the if paths required. Maggie decides to save the OBs in the observation database anyway. The OBs are marked as invalid in the internals of the database. Maggie promptly forgets about them.

Maggie receives notification on November 1st that she is likely to observe in the 2 week period starting November 14th (This occurs even though her scripts are invalid as the DSS does not look at an observer’s scripts.) But the weather is terrible in the first week of November. There is bad weather 5 out of 7 days. Each day she has received an e-mail telling her that her status has changed. Her likelihood to observe has steadily increased. On November 9, she receives an e-mail that there is a very good chance she will observe in the next 12 hours. She thinks, "There's a really good chance that I might get on the GBT tonight or tomorrow. I wish I had known earlier that I would be scheduled so soon. Oh well, I guess I'll cancel my dinner plans for tonight". She also decides that it would be a good time to add her cell phone number to her contact listing.

On November 10th, Maggie gets a phone call at 13:00 from the GBT operator that informs her that her project will be on in 30 minutes. She immediately VNC's into the GBT network and begins setting up her project. At 13:30 she takes control of the telescope and starts her project, but her scripts still do not validate due to problems with her parameter list for the OnOff scan. It turns out that there were many problems in the observing block besides the configuration problem, but the configuration error was the first one that occurred and the only error listed. The rest of the OB was never verified. She spends 43 minutes fixing the errors in the OB. She observes for the remaining 7 hours and 17 minutes. When the operator asks if her time was successful, she claims that she should not be charged the 43 minutes of setup time. The operator flags this in the Dynamic Scheduling Software (DSS) tool with a short description of the problem. An e-mail to the Telescope Scheduler is generated, stating that there is a problem concerning the charged time for Project XX, on the date of 11-10, at time 21:00. The e-mail contains the operator’s description of the issue.

Topic OldExamples . { Edit | Attach | Ref-By | Printable | Diffs | r1.1 | More }
Revision r1.1 - 26 Apr 2007 - 10:52 GMT - KarenONeil
Parents: WebHome 		Content copyright © 1999-2007 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors.