Key Issues, Ideas, and Concerns - Under Development

Issues remaining for Discussion

Come up with better word for Ron's Tsys'; get proper definition of it online
Define or remove use of term "Scheduling Block" – Replaced with “Observing Block”
DayTime?/Night/LST range (Richard's proposal)
what feedback information is needed?
Special cases:
- RFI
- Penn array
Software tools needed (ultimately): not nec. each one, but the overview, including anyting which is needed by the telescope scheduler
Plans for tests: what do we need to know
Plans for tests: what algorithms to we wish to test?
Plans for tests: what software do we wish to build?
Plans for tests: timescales!
Clarify weather grades, percentages, and define the "excellent", "good", and "poor" weather

Key Issues for Policy Development

(RMP) I've put some thoughts on Daytime, Nighttime and LST Range at DaytimeNighttimeLSTRange. This probably needs to be disucssed with Dale Frail, the Proposal Scheduling Committee and the Users' Committee, but lets discuss it internally first.

Data quality monitoring - There are three cases:
1. Everything looks good
2. There are obvious problems that the observer will catch
3. There are subtle problems that the observer probably will not catch
- The current plan is for the observer to be responsible for his/her own data quality. This will catch cases (1) and (2). Case (3), above, is difficult to catch even now. As a result, it will likely always result in some lost telescope time. The charge for that lost time will be determined on a project by project basis. * What happens to the TP in the event of a control system failure?
- In this case, the TP will be stopped, and the telescope time will be charged as a system failure.
- If possible, and the same weather queue is available, the same allocation will be re-run once the problem is fixed
How should observers be handled?
- Observers should be able to enter (and readily change) their availability for observing, as well as their contact information and everything else needed for the observations
- Based on a look ahead, the observers will be notified two weeks in advance that they have a high probability of being scheduled on the GBT
- 24 hours in advance on observing (e.g. at noon on Monday for noon Tuesday - noon Wednesday) observers will again be contacted and informed if it is highly likely that their project will be run, and at roughly what time
- 30 minutes before begining the project, the observer will again be contact to be told their project will be run
What do we require as far as the observer being on site?
- The observers will need a few months advance notice of when their project will be scheduled
- If an observer is on site, that project will receive a higher priority than a remote project if similar classification
Do we have blocks of time that are dynamically scheduled, and blocks of time that are manually scheduled?
- No. Everything should go through the dynamic scheduling system, even those projects with fixed times.
How are maintenence days chosen?
- Just like any other fixed time, or fixed window project
How do we deal with the length of startup required for, e.g. multiple pulsar backend projects?
- the needs to be accounted for in the minimum allocation time by the investogators

Feedback during observations (From Oct 6th Meeting)

Q: When to get feedback from observer (and/or operator) about whether it was a success (their data is good, etc.).
A: At the end of their session's allocated time. Note that this can't just be a flag: if one scan out of the hundreds they took went wrong, they may want to report that, even though their observations were a 'success'.

I agree that "at the end of a session" is often enough, but the information needs to be on a per observing block basis. Are we distinguishing between "minimum observing block" and "observing block", or are they one and the same? What was the JAC experience on this? The definitiion of MSB is that, by definition if any part of it fails, the whole thing needs to be done over (a few bad baselines, or some RFI in a few subscans of an observation does not constitute failure).

I (RMP) think the policy needs to be something like: at the end of the session, all OBs which ran to completion are marked as successful by default; the observer may choose to indicate, on a per-OB basis they were "unsuccessful", GB staff will then confirm or over-rule. Do observer-marked unsuccessul OBs remain in the queue?(e.g. in case there is nothing else worth doing).

At a later stage, we might want to distinguish OBs which failed e.g. to equipment failure, from those that the observer changed their mind on. In this case, they should still be charged the time.

Ideas and Suggestions

Fixed window project: Window length will need to be flexible. E.g. if the project must be run on Tuesday, Wednesday, or Thursday, But thursday is a fixed maintenence day, the program must be smart enough to understand that the window is only Tuesday or Wednesday. If, then, the project then does not get run on Tuesday, the query algorithm would then need to make it a fixed time project for Wednesday. In a more complicated example, assume a fixed window project must be run on Tues, Weds, or Thurs of a given week between 8am-noon. But, there is a fixed time project which runs on Weds at 11am. The softwre again must be smart enough to realize there is a conflict, and set the window for the first projct to only Tues or Thurs.
For monitoring projects, the software should automatically increment the time after the project has been succesfully run. E.g. If a project needs to be run every month between the 10-17th of that month, and the project was just successfully run on May 11, the software should automatically change the window in the SB to read "June 10-17"
Target of Opportunity projects need to be entered the same as all other project, except they should have either a fixed time or a fixed window associated with them.
Test time, calibration, maintenence, etc. projects need to be treated like any other project/allocation, presumably with a fixed time or fixed window.
Pthe DSS must be smart enough to understand about sources - e.g. if an observer wishes to observe two source for two hours each, and one is up now while the other is up in two hours, the program must be able to realize that project has four hours of observable allocations
Must be able to run the program a week(s) in advance (ignoring the weather) and also 30min in advance. Also, there must be a way to state, e.g. the PF Rx will be put in place on Wednesday, as well as to help predict when a new Rx should be put in place.
Need the means to have an automatic check that allocation metadata is in place for monitoring/fixed-time projects.

-- KarenONeil - 02 May 2006

Topic KeyIssues . { Edit | Attach | Ref-By | Printable | Diffs | r1.16 | > | r1.15 | > | r1.14 | More }

Revision r1.16 - 02 Jan 2007 - 23:16 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.


NRAO Home > Green Bank \| Wiki Topic: GB > Dynamic > KeyIssues

Changes \| Index \| Search \| Go