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

Dynamic Scheduling Examples

Example 1 - Basic Observing Example

In May, Willie writes a proposal and makes a request for 30 hours of telescope time to observe a one distant source. He submits the proposal in advance of the June 1st semester deadline. His scientific requirements result in land his session in the "good" winds, night time, and "excellent" opacity categories. The proposal is refereed and assessed at the August Telescope Scheduling Meeting. The proposal is accepted, with all 30 hours given an “A” ranking.

Willie then take a look at his project web page to see what information, if any, is missing from his proposal session to complete the DSS data needed for his one project session. His plan for the observations are to run a peak and focus every hour, and to run a nodded (position switched) observation on his source for the rest of his observing time. As a result, he states that he has a minimum session time of 1 hour (breaking his observations up cleanly this way without wasting time by running more peak and focus scans than needed) and a maximum time of 30 hours (the default).

As his proposal is given an A ranking, it has a high probability of being run as soon as the weather is sufficient. As a result, as soon as the semester starts on September 1, Willie knows he will likely be called as soon as the good weather and his needed LST range occur. Being anxious to get his data and to insure there is no lost opportunities, Willie keeps his contact information as up-to-date as possible.

On September 4, three days into the semester, Willie gets a call on his cell phone and is told his project session will be on in 30 minutes and should be able to run for the next 6 hours. Willie bikes in to his office, starts a vnc session and the observing software, and waits for the phone call from the GBT telescope operator telling him he can start to observe. At 21:30 he receives the phone call and begins his observations. The weather holds and he gets 6 good hours of data. Happy, Willie spends the day reducing the data and hoping the weather is enough that night for him to observe again.

Example 2 – A More Complicated Example

In May, Sam Astronomer writes a proposal and makes a request for 22 hours of telescope time to observe a set of eleven 22GHz water masers, each distributed at a different LST range. She submits the proposal in advance of the June 1st semester deadline. Her scientific requirments result in specifying "good" winds, night time observations, and "excellent" Tsys conditions for this proposal. The proposal is refereed and assessed at the August Telescope Scheduling Meeting. The proposal is accepted, but with a time Session of only 16 hours, and as a "B" proposal. Upon notification of her successful allocation of time, in September Sam uses the Dynamic Scheduling Software (DSS) to complete the DSS data needed for each of her eleven Sessions, one for each source in her proposal. Her plan for each Session is to run a configuration, peak and focus on a flux calibrator, and a series of OnOff scans on the specific water maser source, the sum total of which takes ~1 hour. As a result, Sam sets both her Minimum Time and Maximum Time session time for each source to 1 hour. For science reasons, Sam also wishes to have a minimum of at least 30 days in-between her observations and so she sets the time between for her observations to 30 days. (Note that in this case she does not care what the maximum amount of time between observations is here, just the minimum). Finally, even though Sam has been given only 16 of her requested 22 hours, at this point she doesn't care which masers are observed, and so she leaves the Session priorities the same (and set to the default of "1") for all of her observations. Sam also notes that she will not be available to execute her observations remotely in December.

Knowing she is working on her Session's data, Sam's Project Friend contacts her and informs her that in his opinion her project could be run in less stringent weather conditions, thereby increasing her chances of getting data. But because Sam Astronomer is very keen to get good calibration, she requests that her observation maintains its present weather requirements, in spite of the fact that decreases her chances of obtaining observations. Sam completes her Session data and also completes her Observing Blocks which, after validation, are placed in the observation database.

In mid-October Sam receives an e-mail stating that the likelihood of her Sessions has changed, and that she should go to the project's web page to see the new likelihood of her observing. Logging into the project's web page, Sam find that the DSS has assigned Sam's proposal a high probability of being run within the next week, provided the weather is excellent. Given her source positions, these observations are most sensibly executed in the 8pm - midnight observing time, and Sam confirms that she will be available during that week for observing. (Note that while each Session as a Maximum Time of 1 hour, the source posistions for the Session overlap, resulting in the DSS being able to schedule a four hour Telescope Period (TP) for Sam.) In the first half of the week, the weather is poor, observations with Sam's weather requirements are performed. On Wednesday the weather improves, and Sam receives another automated e-mail stating that her proposal now has a very high probability of running within the next 24 hours. Looking at the weather forecast, Sam realizes she has a high probability of observing and (being a conscientious astronomer) she reviews her Session data and Observing Blocks to ensure that they are ready to go.

On Thursday, as expected, Sam receives another e-mail regarding her project's priority, and she sees that she is very likely to observe that night from 8pm-midnight. Knowing she might be home at 7:30 and not in her office as she had previously thought, Sam then updates her contact information to contain both her home and office phone numbers. At 7:30pm, the weather is still excellent, and the Operator calls Sam to inform her that the current Telescope Period (TP) will complete at 8:15pm, at which point her TP will begin. At 8pm, Sam starts a VNC session at the GBT, but has some problems with her internet connections. She telephones the telescope operator and informs him of her problems and also tells him the name of the first OB she would like run. At 8:15pm, at the start of Sam's TP, and knowing Sam was still having problems logging on, the operator submits the OB requested by Sam. At 8:30pm Sam finally gets logged in and calls the telescope operator to inform him that she now has full connectivity and will be submitting her own OBs for the rest of her TP.

At this point, she discovers her first OB has been executing for fifteen minutes. Sam monitors the telescope status and her data in real-time as it is acquired, and her first two observations execute as expected. For the third observation, the maser is unexpectedly weak, and Sam decides to modify her Observing Blocks (OBs) in real time to extend the total integration time on this source. This observation proceeds successfully, but after that the wind begins to rise. Sam has the option to continue to observe to the end of her TP, but if she does so, the poor observations done under windy weather will still count to her total time Session. At 9:30pm Sam informs the Operator that she plans to quit observing at 10pm. The Operator queries the DSS, selects an appropriate Session based off the new weather conditions, and phones the contact person(s) for that project to inform him that his Session will be run next.

At 10pm, Sam quits, having completed two of her sixteen hours. Having started, Sam would now be very high priority to continue observing. However, she does not receive the time in October or November. Since Sam has marked that she is not available in December, her remaining Sessions are retained in the database. Since her proposal has been started, it is high priority for completion in January. On the basis of her October observations, Sam decides to modify her remaining Sessions' priorities, insuring the sources already observed get the highest priority for further observations. Note that during this entire process the on duty observing support person has also been sporadically checking the DSS and telescope status to insure everything is running smoothly and sensibly.

Example 3 - Rapid Response Proposal

In November John puts in a rapid response proposal to observe a comet that will be passing by in two weeks. The proposal is for L-band and has a total time request of 10 hours, broken into four 2.5 hour Sessions (each differentiated by different source lists). After appropriate reviews, the proposal is granted all 10 hours of time. At this point John is told to immediately put together his Session data, OBs, and contact information so his Sessions can get in the Dynamic Scheduling Software (DSS). Within the project's data John lists the project as a Fixed Time project, and gives the dates and times which the various Sessions must be run. As this is a Fixed Time project, the Telescope Scheduler tells John the exact telescope times he will have. As this is an important, and difficult, observation, John decides to come to Green Bank for the observing.

Two hours before John's project is run a new TP begins. The dynamic scheduling program realizes that a Fixed Time project is coming up, and notifies the telescope operator that the next project will run for only 2 hours, instead of the more common four hours.

30 minutes before his project is to run, the telescope operator calls John's dorm room and informs him that his project will be on in 30 minutes. At that point John comes to the GBT control room to get logged into the computers and begin setting his project up (without actually changing any of the GBT's parameters). When his time begins, John submits his 2.5 hours of OBs, and then spends the time monitoring the data as it comes in. After 2 hours of John's observing, the telescope operator runs the DSS to determine the next project on the telescope, and begins the process of informing the next observer that his/her project is up.

Example 4 - Breaking things into Sessions

Professor Joe Astronomer at the University of Somewhere on the East Coast submits his first NRAO proposal before the June 1st deadline, which looks like this in the PST:

In August the PSC reviews this proposal and awards the applicant all his/her time (how convenient). His project now has the following:

The PSC directs Joe to use a Dynamic Scheduling Software (DSS) web page for converting his allocated PST sessions into GBT sessions. Joe follows this advice and goes to the specified web page, which redirects him to the NRAO User portal, he enters his userid and password. Once he successfully logs on, he follows the link to the DSS Session Tool. Here he finds his original PST sessions and supplies the additional information to create the following GBT sessions:

In addition, for the semester, he provides contact information for observing. Having read all the Dynamic Scheduling Software (DSS) user documentation, he realizes that this could prove a pain with his teaching schedule in the Fall semester, and that trip he has to make to his mother-in-law's around Christmas. Unfortunately, he can’t count on his Co-Investigators to observe, and his graduate student is worthless. So, he realizes that he has a good chance of pre-determining his observing schedule by being on site in Green Bank for a few days.

Joe will also be completely unavailable the week of Oct. 10 - 15, but sees from the DSS hardware schedule that both his needed receivers will be down for maintenance that week, so he doesn't bother, since he won't have a chance to observe then anyways. But Joe is diligent, and reads the fine print - the DSS hardware schedule may be subject to last minute changes! So he decides that adding this dates to the black out list would be a good idea after all.

Joe then proceeds to prepare for teaching his classes and as a result, forgets to properly prepare his Observing Blocks (OBs). Two weeks before Oct. 1, he receives an automated e-mail from the DSS reminding him that he has no OBs in the GBT database. In a flurry, Joe prepares, validates, and submits the OBs he will need for next semester's observing.

Also close to this period, he receives an automated e-mail from the DSS reminding him that his DSS project web page will automatically update on a regular basis, and that if the likelihood of any of his Sessions being given time increases, he will get further e-mail notifications. Joe checks this web page, and is dismayed, though not surprised to find that he has very little chance of observing at the beginning of October with all the competing projects. He does, however, appreciate the feedback this web page provides.

October goes by and Joe never receives an e-mail warning him to prepare observing. He does, however, check his project page as part of his daily routine and sees that his Sessions' likelihoods aren't changing much.

During this month, Joe goes to his Uncles and discovers that his Uncle just has dial-up. He counts his lucky stars he wasn't given any time that weekend.

As November roles around, he gets his first e-mail notification that he may have a chance to observe his fair weather Session (One) in the next week. He goes to his project page, checks things out, and follows another link that makes it clear to him that as the semester has progressed, other projects have been completed, reducing the competition between projects for telescope time.

Joe has horrible luck, and the weather is excellent for most of this week. He watches his likelihood fall back down again as the excellent weather pushes other Grade A high frequency project Sessions ahead of him.

By this time, Thanksgiving is approaching. Two days before Joe is to leave for GB, he is relieved to get an e-mail warning him of impending observation time. Checking his project page, he sees that the fact of his being on site has pushed his likelihood up significantly.

Joe shows up the evening of Nov. 19, tired from his long drive. He realizes that he could be observing as early as 9 PM, and, not entirely prepared, he is relieved when he contacts the operator and is told that this is probably unlikely, unless the weather changes unexpectedly. But he should be prepared to observe anytime after about 4 AM, as the weather is expected to change in his favor by that time.

At 7:30 AM the operator calls Joe's room to inform him that his Session One is the top candidate for observing starting around 8 AM. But Joe isn't in his room. However, the operator (a new one, not the one he talked to last evening) can see from the DSS that Joe should be on site, so she tries the cafeteria. Sure enough, Joe was getting breakfast. Joe, excited to finally be observing, drops his toast and jam and heads straight to the control room.

He Observes.

Example 5 - RFI

The telescope operator has selected Session A1, from project X, to run. The observer, Max, from A1 has been contacted and the Telescope Period (TP) has just begun. All of Max's observing for this Session is within the same, small frequency band. When he begins his observations, he discovers a frequency hopping signal is present across his entire observing band. He tells the telescope operator that he simply cannot observe with this signal present, and requests to give up his time. Looking at the Dynamic Scheduling Software (DSS), the operator sees that Max has no other Sessions which can be observed in the current LST and weather conditions, and so Max gives up the telescope and goes back to bed. The telescope operator enters all necessary information regarding this RFI into his handy "RFI entering tool" from the DSS, including marking that Max's Session cannot be run until the RFI is mitigated, and then re-runs the DSS to look for another Session to run.

The next three Session candidates all use the same receiver as Max, and so all three have indicators showing that they may be affected by the same RFI problem. Undaunted, the telescope operator calls the observer, Flo, for Session A3 (project Q) to see if she is available for observing. The operator then informs Flo about the RFI which Max has seen. She states that she is running a project very similar to Max's and in the same frequency range, and that she, too, cannot run her Session. Sighing, the telescope operator hangs up the phone and marks Flo’s Session as also unable to run due to the RFI.

The operator then calls the observer, Lucy, for Session A126 (project JK). He again informs Lucy about the RFI, but this time Lucy states that she thinks she can observe in spite of it. The operator then tells Lucy that the telescope is sitting idle and asks her if she could begin observing immediately. Lucy states that it will take her 10 minutes to get her computer booted up and things running, and informs the telescope operator of the name of her first two Observing Blocks (OBs). The operator agrees to run those OBs and asks Lucy to call back once she is ready to take over the observations. Fifteen minutes later Lucy logs in and sees her observations have been running, but that she is also affected by the RFI and cannot run. She calls the telescope operator and informs him of the problem. The operator then marks this Session as unable to run due to the RFI. The fifteen minutes of telescope time are marked down as lost time, and the reason is given. This lost time note automatically generates an e-mail to the Telscope Scheduler. In the morning, the Telescope Scheduler will decide if the time was truly ‘lost’ or if it should be billed to Session A126. (Such decisions will be made on a case-by-case basis.)

The operator then calls the observer, Fred, for Session A29 (project T). He again informs Fred about the RFI, but this time Fred states that he thinks he can observe in spite of it. The operator then tells Fred that the telescope is sitting idle and asks the observer if he could begin observing immediately. Fred states that it will take him 20 minutes to get his computer booted up and things running, and informs the telescope operator of the name of his first two Observing Blocks. The operator agrees to run those OBs and asks Fred to call back once he is ready to take over the observations. Thirty minutes later Fred logs in and sees his observations have been running smoothly. He calls the telescope operator and thanks him for starting the project, and then takes over the observing process. His TP continues smoothly, as does the observing for the rest of the night.

Upon arriving at work the next morning, the various members of the RFI group note that they have an e-mail about new RFI seen during the night. Reading the e-mail, they discover that three Sessions have been put on hold until the RFI is taken care of. The members of the group then diligently set out to hunt down the RFI. After considerable work, they discover the RFI is due to some broken equipment owned by the power company. They call the power company who states they cannot fix the problem for another day. The RFI group informs the telescope operator and other on-duty support staff of this fact (in case any observers wish to know the status of the RFI), and all wait patiently for the problem to be fixed.

That night, even though their Sessions were listed by the DSS to run, the operator sees that Max, Flo, and Lucy’s observations are still marked as not observable and so those Sessions are not chosen to run during the night.

The next day the power company fixes the broken hardware and informs the RFI group of that fact. The RFI group then sniffs around a bit to ensure the problem is really fixed. Convinced it is, they enter into the database that the RFI is now gone, and also note that it was and how it was fixed. they also inform the telescope operator and other on-duty support staff that the RFI is no longer present.

That night Max's Session again comes to the top of the DSS queue. This time, though, there is no flag on the project, and so Max is again called and told his project is up. When he asks if the RFI from before is gone, the operator states that indeed the flag for the RFI has been removed from his Session (else the operator would not have called him). Curious, Max asks what the problem was. The operator queries the RFI database lets Max know of what the problem was and how it was fixed. Max happily accepts his time and, when his TP starts, see that the RFI is gone. He then is able to perform the observations which ultimately, he hopes will lead to his Nobel prize. In his (planned)speech he thanks the RFI group, support staff, and dynamic scheduling team for making his observations possible smile

The next night Flo's project gets to run, and then Lucy’s.

Topic DynamicSchedulingExamples . { Edit | Attach | Ref-By | Printable | Diffs | r1.1 | More }
Revision r1.1 - 01 May 2007 - 15:42 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.