| Originator | Comment | Response |
|---|---|---|
| CarlBignell | I am a little uncertain about the exact definition of the 'allocation' and have some concerns regarding specifics. What does an allocation define exactly? Is it meant to be the exact copy of the sessions in the PST with a few other fields? Is one defined for each source, each source/band combination, ...? Will scheduling blocks be tied to each allocation? Will it be possible to determine which sb's were run when and link all this through the allocation? Do you allow multiple bands in an allocation (there are situations when observing one source contiguously multiple bands are used)? | The name "allocaton" has been replaced with the name "session" to try and clear up some of these confusions. Sessions are intended to be unique, and are not tied by the DSS to any observing scripts. If there is not hardware change required, then multiple bands can be contained within one session, but if there is a hardware change needed (e.g. a new front end) then that would require two different sessions to be created. We do not link observing scripts with sessions, as the DSS doesn not look at observing scripts - this will be done by the observers alone. Ultimately we would like the PST and the DSS definitions of sessions to be the same, but at the moment there are differences. The complete definition of session, with examples, is at DynamicSchedulingGlossary#Session |
| CarlBignell | The investigator is the one setting up these allocations. Unless this is done carefully I think this could have significant deliterous consequences. For example the PSC may put an LST range restriction on one (or more of his sources - in fact you may have the case where 2 sources in the same LST range might have different restrictions; this is independent of them being only allowed to observe a subset of their sources). I agree the investigator(s) needs input into these allocations but in such a way that he cannot change the PSC restrictions. To some extent these allocations (or something similar) are what I use to estimate LST pressure during the PSC meeting. Allocations need to all repeats for monitoring and non-monitoring purposes (unless there is some knowledge about requirements and status between allocations). Not all allocations associated with a project are necessarily of the same type (monitoring vs non-monitoring, etc). | Once a session is created, ideally in the PST, many of the fields cannot be changed by the investigators precisely because the PSC will be usning the information in those fields in their decision as to the time allocations. The telescope scheduler, on the other hand, can change any field. This has been clarified in the documentation in the Project Submission and Time Allocation sections of the DynamicSchedulingOverview. |
| CarlBignell | I have another concern about the definitions of these allocations. Currently not all observers treat sessions the same way - in some cases the total time is listed in one session. So will the investigators really understand all the nuances needed to set up efficient allocations? Certainly once the allocations are defined the observers needs to generate the sbs. | I beleive the problems lie in the differences between the PST and the DSS. We are working on removing these differences. |
| CarlBignell | Another concern is that the DSS will not examine sbs in any way. I really don't understand this because if there is a clear link between allocations and scheduling blocks the system should very easily (providing are enough requirements for scheduling blocks) determine if the observer has his scripts created and verified for specific allocations. | we spent a long time thinking about this, and decided there was no need for the DSS to know the details of the observing scripts. Ideally we would have a system that could generate your observing scripts (almost) from your session information. But this falls into the ease of use category that may be developed later for the DSS, but not yet. |
| CarlBignell | Also 'once a week .. a program ... determine ... if all the information needed in the database is there'. Although depending on the details the allocations and sb creation/editing tool should be able to set a flag in the allocation block indicating that it is ready or not (which could include checks for observer information, etc). | Yes - there will indeed be a flag to not if the information is incompelte, and the observers will be contacted if this is the case. |
| CarlBignell | There also needs to be a mechanism to allow to re-scheduling of all or part of an allocation (can be determine a very long time after the original observations). | Absolutely. Sessions can be broken down into segments. If a segment isn't complete it can be re-observed. Additionally, the telescope scheduler can always change the time (either used time to allcoated time) for any session to allow it to be observed more. |
| CarlBignell | Having dealt with prime focus feed change requirements while manually scheduling, I suggest consideration of planning a fixed receiver change schedule for some significant period (in the current scheme 4 months). This schedule would cover all PF feed changes as well. This schedule could be planned ahead based on the 'accepted' proposal pressure as well as preventative maintenance requirements. Monitoring runs using the PF1 feeds could be coordinated such that it may be possible to have regular (monthly no more frequently) monitoring at FP1 feeds and alternate a 3rd feed possibly every other month (all of this would be tailored by coordinated observation requirements (radar, VLBI, source intrinsic properties, etc). | Yes - this is what we envision as well. There will be a "fixed" telescope schedule which will include things like fixed time projects and feed changes and the dynamic schedule will work around that. |
| CarlBignell | Group B proposals. The example outlined in the overview would on the surface imply that a large number of group B proposals could get on the schedule therefore increasing the guaranteed time carry over in the future trimesters. This may require a re-think of group B and its definition (in the extreme you could having nothing but group B - although there is some attractiveness about this I think it not practical because you need to guarantee that highly rated proposals are completed). | We are using a new definition of proposal ratings which has not yet been approved. In this scenario, "B" rated proposals would not be carried over to a new semester. this policy is now laid out in the DynamicSchedulingOverview under the " Science Grades - The Working Hypothesis" section. |
| CarlBignell | Example 3 indicates that day/night/any are options. This actually might be more complicated (as it is now). For example Q band is currently usually scheduled between 3 hours after sunset and 2 hours after sunrise. Some RFI restrictions may apply to after mind-night compared with just night. | The RFI group never mentioned this as a possibility. Out night definition was just the 3 hours after sunset and 2 hours after sunrise definition. I will contact the RFI group again and revise this definition. |
| CarlBignell | Example 5 lists a case in which the astrid script was not verified ahead of time. This should really be one of the pre-conditions before the allocation is selected for potential projects that are ready. | This example has been removed. |
| CarlBignell | The overall impression I have about the process is that it is too complicated to operate smoothly and leaves open the possibility of problems arising at many different stages. | I hope not, but I don't think we can know until we try it. |
| Pete Chestnut | "Use of support scientist or operator requires agreement in advance and the support scientist or telescope operator would then be listed as an observer on the project." How far in advance? Where is the support scientist or telescope operator listed? | This has been changed to state: "Operator - cannot be used at this time, except in predefined circumstances (e.g. VLBI runs); Staff Observers can only be used for observing by prior agreement with the staff member." How far in advance is really up to the staff member, and he/she should feel free to say no to an observer. |
| Pete Chestnut | "This means that if the data taken by a support scientist or telescope operator is not of adequate quality for the project, due to poor data quality, in appropriate observing decisions, etc., the time used observing will still be billed against the project and allocation's time." Operator's can't currently determine the quality of the data | This has been clarified. Under the DSS scheme, the observer is always responsible for the data quality. Staff is never responsible for this determination |
| Pete Chestnut | "At a minimum, we should be able to post a schedule of the prime focus and other feed changes, at least within a few days." I have concerns about short notice and personnel availability versus other necessary activities | This should be easily adressable by the DSS in the sense that e.g. PF feed changes should only be allowed to be scheduled when all personell are available. There are two ways of thinking about this. In one case, maybe the proper personell are only available Tuesday and Wednesday from 1-4pm. In this case, those times are listed as the only possible times for the feed change. In another case, it may be best to just fixed the time and day for the feed change. That, too, is an option in the DSS. The decision as to how flexible to make the feed change times (and other hardware change/fixes times) is up to the project supervisor. |
| Pete Chestnut | "When RFI is seen by the observers, the GBT telescope operators need to be able to readily look at the GBT RFI monitoring system (to be deployed before dynamic scheduling begins)." I agree. Are there plans for training? | Definately. Operator training is going to be a big component of the DSS. As soon as we have dates for completion of the various peices of the DSS we will begin contacting the telescope operators to show them the system. |
| Pete Chestnut | "In the cases where we have full cooperation with an individual or group (e.g. amateur radio beacons), and that group cannot easily turn off its signal with only 30 minutes notice, we need to do the following..." Is the 30 minutes notice dependent on the time of day? | Nope. The RFI group have expressed their beleif that the above requirement is sufficient. If it isn't then we will have to modify the rules. |
| Pete Chestnut | "When the project is selected by the telescope operator, the operator will see an indicator noting that he or she will need to call the person responsible for the transmitter and request that he or she turn the transmitter off for the upcoming TP." We will need a contact list with back-up person (if any) | Absolutely. That is being worked on as part of the DSS. |
| Pete Chestnut | "The observer should be contacted before the person responsible for the transmitter to ensure the observer is indeed available for observing." This is good. | thanks |
| Pete Chestnut | "30 minutes before the end of a given Telescope Period (TP), the operators will query the Dynamic Scheduling Software (DSS) to determine what the next Allocation should be. " How long will it take to determine the allocation? I am concerned about doing this and contacting observers only 30 minutes prior to that time to begin - especially if you have to track the observer down. | In theory the sectiong the next allocation should take seconds. If it takes longer, or tracking down the observer takes a long time, we will simply have to increase the thrity minutes. Hopefully we will be able to determine the appropriateness of this time scale during our tests in September. |
| Pete Chestnut | "The TP will then run until either (1) the weather turns and the data coming in the system is unusable (a judgment call made by the operators based on strict guidelines given to them)..." What are the strict guidelines? | I've removed that second comment - the operator does not have to make such a call anymore. |
| Pete Chestnut | "Once the TP is over, the operator will be asked by the Dynamic Scheduling Software (DSS) if the time was "successful"." This sometimes isn't known until long after the fact. Could the observer feed this info into the DSS or the project support person? | This has been changed to read: The operator, in consultation with the observer, will answer this and, if it is affirmative, the time will be deducted from the Session & project. If the operator responds negatively, he/she will have to record the reasons why the time was unsuccessful. In this case, the Telescope Scheduler will have to decide (at a later time) whether to mark the time as time lost or to bill it to the Session and project. Note, too, that if a TP was marked as successful but later the data was found to be inadequate, the project investigator(s) can contact the telescope scheduler and request that time not be billed to the project. |
| Pete Chestnut | "The operator, in consultation with the observer, will answer this and, if it is affirmative, the time will be deducted from the Allocation & project. If the operator responds negatively, he/she will have to record the reasons why the time was unsuccessful." The operator is also expected to contact the current observer about the success of the project and document the cause if an observation is unsuccessful. Also, when you throw in the operator's task of changing projects etc., this could get hectic. I also have concerns about the operator doing this at the end of a maintenance day due to their required duties at the GBT. | I belive that things will be no more hectic for the operators with this system then it is now when they enter information about failures into the operator's logs. But if that is not correct, we will have to simplify the system to make it straightforward for this information to be recorded. |
| Pete Chestnut | Do you have any idea (or example) of what the operator will see for a general schedule? | Not yet - but once we have an idea we will definately be in touch with the operators to make sure it is sufficient for their needs. |
| Pete Chestnut | Regarding Example 1 (near the end) - If we shutdown at 9:30 for wind, would it still be 2 hours or 1.5? | If the telescope period ended at 9:30pm then only 1.5 hours would be billed to the project. (Note that the dynamic scheduling software should be making these calculations for the operator, so he/she doesn't have to worry about it.) |
| Pete Chestnut | Will local time be the standard for scheduling? Will need to account for time changes (e.g. EST -> EDT)? | Scheduling will be done in UT by the software, but could easily be displayed as EST/EDT (depending on what's appropriate). This will be a decision made be the telescope operators when it somes time to design the interface. |
| Pete Chestnut | Regarding Example 3 - "but it is an example of the need to look ahead and adjust the boundaries of time periods to allow for better scheduling." Who is doing the "look ahead?" | the software. |
| Pete Chestnut | Regarding Example 4 - "At 7:05 AM the operator calls Joe's room..." Earlier info says that the operator calls 30 minutes prior. Thus 7:30? | Yup - thanks for catching that. |
| Pete Chestnut | Regarding Example 4 - "Sure enough, Joe was getting breakfast. Joe, excited to finally be observing, drops his toast and jam and heads straight to the control room." And what if he's not at the cafeteria? Call, call, call, and give up? Call next person? | If someone is on site then they should be easy to track down. If they aren't on site then yes - move on to the next person. |
| Pete Chestnut | Regarding Example 5 - "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 operators currently log lost time and reasons in the opslog program. This is the official tracking/reporting system for us to report to CV. Could the two (opslog & DSS) be somehow linked to avoid duplicate data entry by the operators? | Absolutely. The plan is to tie the two systems together so the operators are not duplicating their efforts. |
| Pete Chestnut | Regarding Example 6 - "The telescope operator enters all necessary information regarding this RFI into his handy "RFI entering tool" from the DSS..." Again, double entry by the operator in the opslog and the DSS. | Shouldn't be - we will redo the operators tools as necessary to avoid effort duplication. |
| Pete Chestnut | Regarding Example 6 - "The operator then tells Lucy that the telescope is sitting idle and asks her if she could begin observing immediately." How to track/charge lost time? | We will have to have a billing to "between projects" or somethign along those lines. |
| Pete Chestnut | Regarding Example 6 - "The operator then marks this Allocation as unable to run due to the RFI." Again, double entry by the operator in the opslog and the DSS. If different from what was logged then we (I) will have to change in the opslog program. | See above. |
| Pete Chestnut | Regarding Example 6 - "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... 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." Who adds the flag info in the DSS? | It will be automatically entered when the operator notes the problem in the (new) log |
| Pete Chestnut | Avoid project changes opportunities at or near operator shift change. This could delay the end of shift operator from leaving on time and also add a second person into the equation, possibly adding to confusion. | that should be easy, as the operator's define the telescope period. so if the TP should be ending at 7pm, they could just extend it to 7:30pm or later. One of the documents we feel we need before DSS can be released is clear guidelines for the telescope operators. |
| Pete Chestnut | Hopefully, in most cases the decisions would be straight-forward and result in identical outcomes regardless of which operator is on shift. | they should be. |
| Pete Chestnut | I'd like to get Karen or someone to get together with us as a group in the near future and go over over their expected roles, etc. I have concerns about the ops trying to sort out the options of choices, contacting upcoming observers, taking info from the finishing one, filling out success reports, etc , all while trying to complete/start projects, keep up with the opslog which will be our only source of tracking observing/lost time and babysitting the other telescopes as well, or trying to finish up at the end of a maintenance period. We want to ensure that the operators lives are not made overly complicated. | Absolutely - operator training and input into the DSS is vital. As soon as we are far enough along to make use of their input we will begin setting up meetings to talk with the telescope operators. |
| Pete Chestnut | It's a bit hard to envision how all of this will work without seeing the tools they will be provided with and seeing if there is some sort of set base schedule to follow, and how often they will be faced with having to make a decision. | Yes - that is all vague right now until we get some more testing under our belts. |
| Pete Chestnut | Some months back, I was told the support staff would have a larger role in the decision making. Is this still the case? | Yes, with the details still being worked out. |
| Originator | Comment | Response | Fully Resolved? |
|---|---|---|---|
| RichardLacasse | It seems as if it ought to be a requirement that the system accommodate observers who have a demonstrated need to be physically present for their observations. Potentially, the system as described, could have a physically-present observer twiddling their thumbs for quite a while before their observation. Some of these guys have a life - they teach classes and the like, so we can't keep them waiting indefinitely. There is some mention late in the text about increasing probabilities of observing for observers who are on site. I don't know that this is good enough?? | Indeed, we will give preference to on-site observers. We can even guarantee them specific times if we deem it necessary by giving them fixed time allocations. |  |
| RichardLacasse | I don't know how far out in time this scheduling will go. If it goes for months, you might have to watch out for what time of the solar day the LST is in, and where the moon happens to be... | Duly noted. We propose that candidate allocations are re-reviewed each telescope period. Although we might look forward for a week or two, this look ahead is not to generate a schedule but to determine project execution probabilities or likelihoods which are provided to the observer. The observer can review these likelihoods (e.g. numbers, graphs) and determine whether or not their allocation(s) will be scheduled soon. | |
| RichardLacasse | I assume part of your plan is to get reactions from the users. I am a bit concerned that someone may be awakened at some ungodly hour on some random day and told that their observation is starting in an hour. From the scenarios it seems like they get a few emails before the phone call - that helps! Maybe that's a worthwhile cost to get good data, but getting users to buy into that concept is important. | We wholeheartedly agree that user buy-in is critical to the success of dynamic scheduling. In the current proposed policy, observers are notified 30 minutes prior to their telescope time. However, we intend to provide warnings regarding the probability of being called at an ungodly hour in the form of automated e-mails and a project information page. Our intention is to keep observers apprised of their standing in the queue and cognizant of changes to their standing. Also, we are including calendars for observers so that they can specify when they cannot observe, which will be honored in the scheduling process. | |
| ChrisClark | The operator runs the DSS half an hour before the next allocation. This is the same time that remote observers are supposed to contact the operator. It may happen that there are multiple remote observers whose project might be up next trying to contact the operator at this time. | In the proposed model, the operator is viewing the proposed schedulable projects and initiates all communication. The observers only know if their projects have a high probability of running and don't have specific times or dates. But your comment is very interesting and it would be to our advantage to create policies that will minimize or eliminate observer-initiated communications which are simply aimed at querying operators about when they might get scheduled! | |
| JimBraatz | The dynamic scheduling system always counts VLBI observations as fixed time. It would be a considerable advantage to VLBA+GBT programs to schedule these dynamically. The success of sensitivity-limited observations (such as H2O megamasers) is particularly improved because the GBT contributes most of the collecting area and these experiments fail when the weather is bad in GB. Already the VLBA is scheduled dynamically when it is used without the GBT. I realize there are many issues to be dealt with, such as how to handle other telescopes that might possibly be included in the array. But it would be useful to consider the options. | FrankGhigo also raised this issue. We will definitely have to incorporate this into the GBT's dynamic scheduling strategy. Thanks for pointing this out. | |
| RogerNorrod | After a quick read, I don't see any discussion of how PF feed changes are scheduled. The changes are driven by observing demand, so I don't think the issue can be ignored. Some limits need to be in place to prevent wearing out equipment and personnel (1 per week max?), to provide sufficient notice so that the changes can be scheduled (at least one working day notice?), and to allow for situations when weather prevents a scheduled change. | We propose the following example to handle 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 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. | |
| BrianMason | The weather queues need to: a) include the contribution of cloud cover in the opacity/Tsys in some reasonably accurate way; and or b) otherwise include extent of cloud cover as a factor. For many projects, especially continuum projects above xband (but also broad line projects) atmospheric stability is more important than Tsys, and the biggest factor which destroys this typically in green bank is clouds. | We wholeheartedly agree. Jim Condon has championed the importance of cloud cover (more specifically, hydrosols) to telescope scheduling at Dynamic Scheduling meetings as well in his Dynamic Scheduling Project Note, Scientific Requirements for Dynamic Scheduling. He has also made concrete suggestions for instrumentation in a second Project Note, New Instruments and Techniques for Dynamic Scheduling. We plan on presenting requests for such instrumentation to the PTCS group. | |
| BrianMason | The overall process potentially imposes a huge burden on observers-- be on call 24/7 for a whole trimester! If we don't do what we can to keep this burden as low as feasible then could end up with more inefficiency than we have now. The burden will be worst on projects with a small number of collaborators, and projects involving new "experimental" stuff that black belts or nrao staff do, where it is not feasible to run stuff in a more or less automated way. One way to reduce this is to allow the blackout dates to be flexible. IE you don't have to specify them too far in advance. | We have been taking a close look at the JCMT Dynamic Scheduling System and they have placed a high priority and have devoted a great deal of software development time to good user feedback. We recognize that the success of this project rests largely on our ability to engage and inform our users at each stage of dynamic scheduling. We certainly plan to provide users with the utmost flexibility when updating their availability calendars. These calendars will be examined when choosing candidate allocations each Telescope Period, allowing users to continually make changes to their blackout dates. Among other things, we also plan to provide feedback in terms of "likelihoods" to users. Therefore, users will know the likelihood of getting scheduled in the near-term. We hope that this sort of information eases the impact of dynamic scheduling on the lives of our observers. | |
| BrianMason | The simulator (not the validator) needs to be available for routine, production use by many people, so people can in a more real sense validate their scheduling blocks ahead of time. | There are two potential simulator possibilities for observers. The first simulator is the "Simulate" button which is currently available to scientific support staff from the Edit tab within the Observation Management tab in Astrid. We (the SDD) could make this button available to all users quite easily and this was the original plan. However, we (the SDD) have received little or no feedback on this feature (good or bad) and are therefore reluctant to make it available for all. The second simulator is the full system simulator in which every M&C Manager and M&C component is simulated as closely as possible to provide a fairly accurate representation of the real system. We could create one or more simulators of this type simply by running the M&C simulators on recycled desktops with some sort of arbitration scheme for simulator time. However, the M&C simulator suite is incomplete as important Managers (e.g. the Spectral Processor) have no simulators. With that being said, we could release a limited simulator for use. But it would require some months of effort to make a fully-functional simulator possible. This effort is on the SDD's "to do" list (even outside of the context of Dynamic Scheduling), but is perpetually on the back burner due to resource limitations and project priorities. | |
| BobAnderson | If you expect observers to be physically present, won't you have to guarantee that they will have some observing time during this period? | An observer on site will have preference over all other observers with similar weather needs. As a result, dynamic scheduling will work much like optical telescopes do - if you are on site and the weather allows it, you will observe. While this doesn't insure an onsite observer will get telescope time, it means that being on site raises the probability of you observing significantly. Provided an observer stays for a reasonable amount of time (e.g. more than 1 or 2 days) he or she should get on the telescope. While this does not garuntee the time, we will make evey effort to insure the observer's trip is not wasted. | |
| BobAnderson | Regarding Example 1: I don't see any mention of a support astronomer's role during the day of observation. Shouldn't they be aware of the list of project choices, a review of weather queue stats, a check of other weather information to be sure Ron's predictor is giving reasonable information, RFI issues, etc.? If it isn't called out, these activities are going to fall on Ron, or not happen at all. Do we have enough confidence in these other tools for no feedback loops? | The intent is that during the first stages of synamic sheduling first we (the dynamic scheduling team) and later the observing support personell will pay considerable attention to the scheduling process. Once things settle and become routine, the observing support personell should simply be monitoring the telescope to ensure that sensible decisions are being made by the DSS. I have made an addition to example 1 to make this more clear. | |
| BobAnderson | Regarding Roger's first comment: We may need a "telescope configuration" input, e.g., what feed is on PF1, whether PF2 is installed instead, what receivers are in the turret, what equipment is unavailable, etc., all the way through to the back end instruments. | Yes, we will have that, through use of the cabling file. That is, when the DSS looks to see what allocation will be run next, it will use the current cabling file to insure the paths can be routed. The (dynamcially) scheduled feed changes will also be taken into account when determining a project's probability of being observed in the future. | |
| RichardPrestage | I'm afraid I have lots of comments, so I've put them on RichardsOverviewComments. | Responses to Richard's comments are included on his page. | |
| RichardPrestage | I've also made some comments in-line in the DynamicSchedulingGlossary | These have all been cleared up. | |
| Greg Monk | Who is telescope scheduler? His or her backups? | The Telescope Scheduler is Carl Bignell. His backup would be a member of the scientific support staff. This definition is now included in the overview | |
| Greg Monk | More description of what a telescope period is, is it flexible or a set time period? | A period of time which is the maximum time during which projects may not be changed. These exist to insure that an observer can have a guaranteed time for observing, even if the weather improves to the next higher weather category. Typically a Telescope Period will last for 4 hours, however there are numerous conditions under which this time could change:
A telescope period may contain more than one session from more than one allocation within a given project. This definition has been exmpanded and is also now included in the overview. | |
| Greg Monk | The 30 minute notification period by phone for observer(s)? | The operator will evaluate schedulable allocations 30 minutes prior to each Telescope Period and will notify observers that their allocation is scheduled. Additionally, we intend to provide warnings regarding the probability of being called at an ungodly hour in the form of automated e-mails and a project information page. Our intention is to keep observers apprised of their standing in the queue and cognizant of changes to their standing. Also, we are including calendars for observers so that they can specify when they cannot observe, which will be honored in the scheduling process. An allocation is not a candidate for scheduling if there are no observers available according to the project's calendar. If the operator is unable to reach an observer for a particular allocation, then the next allocation's observer is called and so on until an observer is found. The system will provide an automated notification that an observer was called to observe, but could not be reached. | |
| Greg Monk | RFI on page 5 says we are to call the person responsible for transmitting RFI. The telescope period times may be very important as I think NRAO would not want us to call someone at unreasonable hours to do this. | In the cases where we have full cooperation with an individual or group (e.g. amateur radio beacons), and that group cannot easily turn off its signal with only 30 minutes notice, we need to do the following:
In the cases where we have full cooperation with an individual or group and that group can easily turn off the signal with only 30 minutes notice, we need to do the following:
| |
| Greg Monk | Successful or unsuccessful observations? | Definition of "successful": An observation is deemed successful if the observer is able to carry out his/her Observing Block without problems accountable to the GBT (e.g. hardware or software problems). If the observer requests the wrong source or otherwise makes a mistake in his/her session but otherwise the session is run successfully, that sessions still considered successful and the time is logged against the project/activity and allocation. Once the TP is over, the operator will be asked by the Dynamic Scheduling Software (DSS) if the time was "successful". The operator, in consultation with the observer, will answer this and, if it is affirmative, the time will be deducted from the Allocation & project. If the operator responds negatively, she will have to record the reasons why the time was unsuccessful. In this case, the Telescope Scheduler will have to decide (at a later time) whether to mark the time as time lost or to bill it to the Allocation and project. | |
| Greg Monk | How are we to know tsys prior to an observation? | Unfortunately, the confusion here is mostly likely due to overlapping terminology. The information that the dynamic scheduling system will be using is based upon predicted and current weather conditions and what we plan to use is opacity. A description of how we plan to turn weather predictions into scheduling criteria can be found in: http://wiki.gb.nrao.edu/pub/Dynamic/DynamicProjectNotes/dspn2.pdf | |
| FrankGhigo | We have to somehow include dynamic scheduling of VLBI observing. Of course this must be done in close collaboration with the VLBA schedulers and operators. Its no worse a problem than dynamic scheduling of the VLBA itself, in which weather conditions at 10 widely separated telescopes must be taken into account. There is a lot of interesting science that requires high-frequency VLBI, and the use of the GBT is of great importance to increase the sensitivity of the array, so there will be increasing demand for dynamic VLBI. | JimBraatz also raised this issue. We will definitely have to incorporate this into the GBT's dynamic scheduling strategy, and are currently meeting with the VLBI scheduler to insure a system is defined for the GBT. | |
| FrankGhigo | A seeming inconsistency between the remark under "requirements" that says that one can observe interactively or non-interactively, versus the remarks under "key features" that seem to say that the observer must be available either in person or remotely during the experiment. Along these lines, I would argue that for an experienced observer with a well-tested set of observing blocks, the telescope operator could run the scheduling blocks with no monitoring by the observer. The observer would then get his data later. | Interactive and non-interactive do not refer to whether the observer is present or not. Rather, these terms instead refer to the level of observer involvement. In both interactive and non-interactive cases, the observer initiates the blocks. In the interactive case, the observer is actively reviewing and possibly editing SBs as the observation progresses. In the non-interactive case, the observer queues up a bunch of blocks and sits back and waits for data to be acquired - possibly only looking at the data as it comes in through GBTIDL. The key here is that the observer is present and responsible for the quality of their data. We don't think that we are preventing (at least in terms of software) the experienced observer with a well-tested set of observing blocks from providing the operator with an ordered list of blocks to be executed during an observation. These are purely policy issues. Do we want to add the responsibility of executing an observer's blocks on to the operator's already long list of responsibilities? And, if the data are bad, does the observer get their time back? | |
| FrankGhigo | Various terms are used without being explained, i.e, "0-25% Tsys queue" "max time" and "min time" in an allocation, "wind(50-75/E)" | We will add links in the DynamicSchedulingOverview where these terms are used to aid the reader. To answer your specific questions: The Tsys and wind categories references the following wiki page: WeatherQueue Minimum Time (Allocation): An allocation will have a minimum and maximum time associated with it. The minimum time will define the smallest amount of time the observer feels is useful for observing, and will be the smallest amount of time for which the DSS will allow a session for the allocation to be scheduled. Note that the DSS will, of course, attempt to make a much longer TP for the project and allocation, but due to the difficulty in scheduling the telescope it is conceivable that an allocation will be scheduled for only its minimum time. The default minimum time will be set to 2 hours. Examples of minimum time include:
Maximum Time (Allocation): An allocation will have a minimum and maximum time associated with it. The maximum time for that allocation will define the longest period of time in the LST range for which a session will be scheduled (that is, it will define the longest session allowed). The purpose of this definition is to allow for observers to readily break their (non-fixed or windowed time) project into multiple sessions. Unlike fixed time and fixed window projects, the maximum time parameter does not offer any information as to when the next allocation session will be scheduled, except that it will not be scheduled until the LST range for the allocation begins again. The default maximum time will be set to the maximum time of the allocation. Examples of maximum time include:
| |
| Topic OverviewComments . { Edit | Attach | Ref-By | Printable | Diffs | r1.20 | > | r1.19 | > | r1.18 | More } |
| Revision r1.20 - 30 Apr 2007 - 18:24 GMT - KarenONeil |
Content copyright © 1999-2007 by the contributing authors. All material on this collaboration platform is the property of the contributing authors. |