Key Issues, Ideas, and Concerns

Key Issues, Ideas, and Concerns - Under Development

• come up with better word for Ron's Tsys'; get proper definition of it online
• Define or remove use of term "Scheduling Block"

• 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”

I agree that "at the end of a session" is often enough, but the information needs to be on a per scheduling block basis. Are we distinguishing between "minimum scheduling block" and "scheduling 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 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 SBs which ran to completion are marked as successful by default; the observer may choose to indicate, on a per-SB basis they were "unsuccessful", GB staff will then confirm or over-rule. Do observer-marked unsuccessul SBs remain in the queue?(e.g. in case there is nothing else worth doing).

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 SBs 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.

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.

• Review overview page

• come up with better word for Ron's Tsys'; get proper definition of it online

• Feedback information needed

• what feedback information is needed?

• Review selection rules

• feedback information needed
• special cases:

• Feedback information needed
• Special cases:

• 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!

• 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!

• (RMP) What quantity is the Query Tool working on? From the SoftwareSuite definition: "This is the tool which will use our predefined algorithms and metadata to choose which projects/SBs should be run at a given time." Is it choosing projects, sessions or SBs? Or it is working on all three linked together? I believe in the JAC implementation it actually selects individual SBs, but presumably these are grouped together by project/session in the results window, so it would be easy to continually select SBs from the same project/session one after the other.

• (RMP) Is it implicit / explicit / agreed that the Query Tool simply presents a list of possible SBs in some sort of priority order, and it is a human being who makes the final decision? Have we clarified who that human being is in different circumstances. e.g. presumably it is the P.I. if they are present and executing their own fixed-window project. I think we've been blurring the distinction as to what happens before the next "project" is decided, and what happens within that project. This might be another reason for dropping TPs, and sticking with sessions - in that case the Operator/GB staff person picks the next session; the Observer once notified it is their session, picks SBs (from their project only). But we should keep the long-term goal in mind, dynamically selecting individual SBs to run, irrespective of project.

• What do we do about replacing SBs in the queue if the observer is not available to evaluate the data?
  • If an observer is not available, his/her project will not be run and a different project (for whom an observer can be found) will be run.
• What happens to the SB in the event of a control system failure?
  • In this case, the SB will be stopped, and the telescope time will be charged as a system failure.
  • If possible, and the same weather queue is available, the scheduling block will be re-run once the problem is fixed

* 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

• • We could simply add in a "setup time" parameter to the metadata that sefaults to say five minutes for some projects, more for others

• • the needs to be accounted for in the minimum allocation time by the investogators

• 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.

• 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.

• Test time, calibration, maintenence, etc. projects need to be treated like any other SB, presumably with a fixed time or fixed window.
• Program 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 data

• 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

• There needs to be a way to look at the project metadata almost exclusively, when running the program in advance, in case SBs are changed.
• Need the means to have an automatic check that Sbs are in place for monitoring/fixed-time projects.

• Need the means to have an automatic check that allocation metadata is in place for monitoring/fixed-time projects.

• (RMP) need to clarify Project versus Proposal, and use one or the other uniformly everywhere - or else clarify the difference (or maybe RichardPrestage is just obtuse....

Issues remaining for Discussion

• Review selection rules
• Review overview page
• Define or remove use of term "Scheduling Block"
• DayTime?/Night/LST range (Richard's proposal)
• feedback information 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

• (RMP) Need to clarify sessions and repeats. In the PST, say the proposer defines a "session" as e.g. an eight hour period of time with a given LST range, and they ask that to be repeated 10 times. I've been considering that as 10 individual sessions; the repeat count is just a convenience to save having to create the same object over and over again. But do others consider this whole thing one "session"? If so, what is the eight hour time period called?

• (RMP) I'd like to float the idea of dropping the concept of Telescope Period. I know, I'm sorry - I think I invented it - and this is just a suggestion. But at the time, I had kind of forgotten about (my) definition of a single session, and was looking for a time period longer than a Scheduling Block which formed a natural way of letting an observer continue observing for a while. I think the (observer-specified) concept of a "session" satisfies the need, and so the Telescope Period is redundant. I think in most of the discussion and documentation, we could just exchange the concepts; e.g. "thirty minutes before the end of the Telescope Period, we must reassess x", would become "thirty minutes before the end of the session, we must reassess x". If we went down this route, all the same considerations would apply - i.e. don't start a four hour session two hours before a fixed-window project needs to start. We might have to consider the flexibility of breaking up sessions however, e.g. if there is nothing better to do, do two hours of a four-hour session to fill up the gap in time, as long as the SBs are individually two hours or shorter.

• The Proposal Scheduling Committee would prefer to be known as the Proposal Scheduling Committee, not the Time Allocation Committee. The PSC general accept the referees proposed time allowance, and view themselves largely as applying agreed policy and the referees rankings to select the top ranked proposals until the total available telescope time is used. This is in contrast to a Time Allocation Committee, where the members of the committee get more involved in judging the scientific merit and/or amount of time each proposal should receive. the PSC does certainly make scientific judgments, but prefers not to over-rule the referees rankings without good reason. Just an FYI as to why I have been changing this everywhere.

The query tool will definately be working on session metadata. the SoftwareSuite page is veyr out of date and will be updated soon. Karen

The query tool will definately be working on session metadata and knows nothing about SBs for Phase I. the SoftwareSuite page is veyr out of date and will be updated soon. Karen

• The "repeat" metadata information should be incremented down automatically when the observer/operator states the SB was run succesfully. But - there needs to be an easy mechanism for and observer to change the number of repeats later.

• (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.

• (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.

• (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.

• need to clarify Project versus Proposal, and use one or the other uniformly everywhere - or else clarify the difference (or maybe RichardPrestage is just obtuse....

• (RMP) need to clarify Project versus Proposal, and use one or the other uniformly everywhere - or else clarify the difference (or maybe RichardPrestage is just obtuse....

• The Proposal Scheduling Committee would prefer to be known as the Proposal Scheduling Committee, not the Time Allocation Committee. The PSC general accept the referees proposed time allowance, and view themselves largely as applying agreed policy and the referees rankings to select the top ranked proposals until the total available telescope time is used. This is in contrast to a Time Allocation Committee, where the members of the committee get more involved in judging the scientific merit and/or amount of time each proposal should receive. the PSC does certsinly make scientific judgments, but prefers not to over-rule the referees rankings without good reason. Just an FYI as to why I have been changing this everywhere.

• (RMP) Need to clarify sessions and repeats. In the PST, say the proposer defines a "session" as e.g. an eight hour period of time with a given LST range, and they ask that to be repeated 10 times. I've been considering that as 10 individual sessions; the repeat count is just a convenience to save having to create the same object over and over again. But do others consider this whole thing one "session"? If so, what is the eight hour time period called?

• (RMP) I'd like to float the idea of dropping the concept of Telescope Period. I know, I'm sorry - I think I invented it - and this is just a suggestion. But at the time, I had kind of forgotten about (my) definition of a single session, and was looking for a time period longer than a Scheduling Block which formed a natural way of letting an observer continue observing for a while. I think the (observer-specified) concept of a "session" satisfies the need, and so the Telescope Period is redundant. I think in most of the discussion and documentation, we could just exchange the concepts; e.g. "thirty minutes before the end of the Telescope Period, we must reassess x", would become "thirty minutes before the end of the session, we must reassess x". If we went down this route, all the same considerations would apply - i.e. don't start a four hour session two hours before a fixed-window project needs to start. We might have to consider the flexibility of breaking up sessions however, e.g. if there is nothing better to do, do two hours of a four-hour session to fill up the gap in time, as long as the SBs are individually two hours or shorter.

• The Proposal Scheduling Committee would prefer to be known as the Proposal Scheduling Committee, not the Time Allocation Committee. The PSC general accept the referees proposed time allowance, and view themselves largely as applying agreed policy and the referees rankings to select the top ranked proposals until the total available telescope time is used. This is in contrast to a Time Allocation Committee, where the members of the committee get more involved in judging the scientific merit and/or amount of time each proposal should receive. the PSC does certainly make scientific judgments, but prefers not to over-rule the referees rankings without good reason. Just an FYI as to why I have been changing this everywhere.

• (RMP) What quantity is the Query Tool working on? From the SoftwareSuite definition: "This is the tool which will use our predefined algorithms and metadata to choose which projects/SBs should be run at a given time." Is it choosing projects, sessions or SBs? Or it is working on all three linked together? I believe in the JAC implementation it actually selects individual SBs, but presumably these are grouped together by project/session in the results window, so it would be easy to continually select SBs from the same project/session one after the other.

• (RMP) Is it implicit / explicit / agreed that the Query Tool simply presents a list of possible SBs in some sort of priority order, and it is a human being who makes the final decision? Have we clarified who that human being is in different circumstances. e.g. presumably it is the P.I. if they are present and executing their own fixed-window project. I think we've been blurring the distinction as to what happens before the next "project" is decided, and what happens within that project. This might be another reason for dropping TPs, and sticking with sessions - in that case the Operator/GB staff person picks the next session; the Observer once notified it is their session, picks SBs (from their project only). But we should keep the long-term goal in mind, dynamically selecting individual SBs to run, irrespective of project.

For an extreme subtlety, we might want to distinguish SBs 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.

At a later stage, we might want to distinguish SBs 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.

* I'm confused by the concept of "sessions" having "repeats". I know that in the Proposal Submission Tool, one can specify session and number of repeats, but I think this is just a quick way of creating "n" identical sessions. I don't see how number of repeats left is any more useful than just knowing the percentage completion of the whole proposal.

• need to clarify Project versus Proposal, and use one or the other uniformly everywhere - or else clarify the difference (or maybe RichardPrestage is just obtuse....

• The Proposal Scheduling Committee would prefer to be known as the Proposal Scheduling Committee, not the Time Allocation Committee. The PSC general accept the referees proposed time allowance, and view themselves largely as applying agreed policy and the referees rankings to select the top ranked proposals until the total available telescope time is used. This is in contrast to a Time Allocation Committee, where the members of the committee get more involved in judging the scientific merit and/or amount of time each proposal should receive. the PSC does certsinly make scientific judgments, but prefers not to over-rule the referees rankings without good reason. Just an FYI as to why I have been changing this everywhere.

• 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'.

For an extreme subtlety, we might want to distinguish SBs 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.

* I'm confused by the concept of "sessions" having "repeats". I know that in the Proposal Submission Tool, one can specify session and number of repeats, but I think this is just a quick way of creating "n" identical sessions. I don't see how number of repeats left is any more useful than just knowing the percentage completion of the whole proposal.

Key Issues, Ideas, and Concerns

TOC: No TOC in "Dynamic.KeyIssues"

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.
• The "repeat" metadata information should be incremented down automatically when the observer/operator states the SB was run succesfully. But - there needs to be an easy mechanism for and observer to change the number of repeats later.
• 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 SB, presumably with a fixed time or fixed window.
• Program 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 data
• 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.
• There needs to be a way to look at the project metadata almost exclusively, when running the program in advance, in case SBs are changed.
• Need the means to have an automatic check that Sbs are in place for monitoring/fixed-time projects.

• How do we deal with the length of startup required for, e.g. multiple pulsar backend projects?
  • We could simply add in a "setup time" parameter to the metadata that sefaults to say five minutes for some projects, more for others

• How should observers be handled? Should we just tell them when they are scheduled, or what level of flexibility do we provide?
  • TDB

• 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

• • TBD

• • 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

• • TBD

• • Just like any other fixed time, or fixed window project

• How are maintenence days chosen?
  • TBD

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

Key Issues for Policy Development

• 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 do we do about replacing SBs in the queue if the observer is not available to evaluate the data? *If an observer is not available, his/her project will not be run and a different project (for whom an observer can be found) will be run.
• What happens to the SB in the event of a control system failure?
  • In this case, the SB will be stopped, and the telescope time will be charged as a system failure.
  • If possible, and the same weather queue is available, the scheduling block will be re-run once the problem is fixed
• How should observers be handled? Should we just tell them when they are scheduled, or what level of flexibility do we provide?
  • TDB
• What do we require as far as the observer being on site?
  • TBD
• 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.

-- KarenONeil - 02 May 2006