June 25^th, 2001 APT Visit Planner Meeting at 3:00pm in N310

Jesse, Ron, Andy, Karla, Tricia, Rusty, Leslie

• Tony Krueger pointed out that the APT requirements do not indicate that the Visit Planner should be a standalone tool and that there is no requirement for the Visit Planner to support phase 1 proposals.

  At this point, there is no real compulsion to discount support of phase 1 proposals, but we should not consider a standalone mode for the Visit Planner.

  Tony referenced the APT GUI Requirements and I would suggest that anyone not familiar with them should read over them to get an understanding of the context of APT Tools within APT. The URL for the APT GUI Requirements is:

  http://ra.stsci.edu/apst/apt/documents/documentation/apt-gui-req.pdf
• I completely forgot about setting everything up for the Spike GUI demo. We'll have that next week.

• We talked about the kinds of things that the user will want to do when analyzing schedulability information that the visit planner presents. This is probably really the heart of the matter for trying to figure out the capabilities which the Visit Planner should have.
• We primarily discussed these questions:
  • After scheduling windows are displayed, what will the user do if the result is not satisfactory?
  • What questions will the user ask?
  • What sort of scheduling conflicts can there be? Does it matter if the user can choose the set of visits and scheduling constraints to display?
  • Which observer constraintss are causing there to be unschedulable windows, i.e., which requirements can be relaxed to make some or any windows schedulable?
  • How can observer requirements be changed to create a schedulable window where there was none over a particular period of time?
  • How can observer requirements be changed to create a schedulable window where there was none over any period of time?
  • Points that came up in the discussion:
    • If two constraints are in conflict over a particular period of time, how can one or the other be relaxed to create a schedulable window?
    • For phase 2, some GOs throw their hands up at the first sign of problems and let the PCs deal with it.
    • Linksets are the ugliest and hairiest problems. If any one visit in a linkset can't schedule for some other reason, then all visits in the linkset are marked unschedulable. RPS2 doesn't indicate directly which linkset is the problem so it is hard to visually track down the offending visit.

      Also, there may not be a unique solution. Solving the problem could mean changing the requirements on a visit other than the offending one. Changing requirements in another visit could allow requirements to be relaxed in others.

      We should definitely work towards a visit planner that helps to alleviate the problems of link sets. But, because it is difficult problem, we shouldn't try to deal with it the first time around. [[[Tricia will try to put together a general statement of the linkset problem with examples]]]

    • We think that if a user selects visits to process but does not include linked visits in their selection, the visit planner should include all linked visits in its analysis.
    • A few thoughts on why and how the PI would use the visit planner:
      • To get a "blessing" so that they can submit their proposal.
      • To get information to help them change their proposal to make it submittable.
      • Should the PI be able to iterate in the visit planner to explore without changing the actual proposal?

        [I think allowing this goes against the general APT philosophy. It makes implementation a lot harder and an easy way to get the capability is for users to create "play" visits.

        Someone involved in general APT requirements might be able to say more about this.]

      • The crux of the problem is how do we assist the PI in making the proposal schedulable.
    • Two ways a user can use the tool:
      • Start from scratch and add one constraint at a time, checking the schedulability as they go.
      • Build the whole proposal up front, then check schedulability at the end.

      Different GO's will work differently, and the Visit Planner should be able to meet the needs for different ways of working.
    • Because the user can selectively choose which entities to work with in an APT tool, the requirements between Phase 1 and Phase 2 proposals are not that distinct. The primary issue with Phase 1 proposals is being able to work with only a partially specified proposal.

      We should have the capability to analyze schedulability for a select subset of constraints no matter the type of proposal.

      We should know up front what the complete set of scheduling constraints are and know what the minimum set is required for analyzing schedulability.

    • We took a little bit of a different approach today by concentrating on what the user wants to know once a schedulability run has been done.

      If anyone has any opinions about this track, critical or otherwise, let me know.

      I think this is where we need to think in order to dig out the capabilities the user will need.

      I will try to put together a coherent description of our discussion in a use case kind of flow. Then, next time, maybe we can refine it, then start listing capabilities.

http://ra.stsci.edu/apst/apt/apt-visit-planner/

We'll continue our brain storming on use cases. I've included the uses cases from last week below.

[I do have some concerns that we are glossing over the "analyze" and "modify" data actions. I'll think about this before the meeting.]

• The questions we would like to consider for each use case are:
  • Who Is Using the Visit Planner?
  • When Is the Visit Planner Being Used?
  • What are the inputs?
  • What are the outputs?
  • What actions will the user take on the input/output data?
• We came up with three use cases to start with today:
  • Most basic case:
    • Who: PI, PC
    • When: Late in Phase 2 Writing Process
    • Input: Full Phase 2 Proposal
    • Output: Satisfactory Result, Bar Graph, Diagnostics, Advice
    • What Action: Nothing, the user is done.

  • Same as previous case, but change Output and What Actions
    • Output: Unsatisfactory Result
    • What Actions:
      • Analyze output and input data.
      • Modify input data.
      • Iterate.

  • This time, PC only
    • Who: PC Only
    • What Actions: Analyze and contact PI to change proposal.

• Here is a list of other types of input to consider for making other use cases:
  • Input is nothing, ie, starting from scratch for a phase 1 proposal.
  • Input is nothing for a phase 2 proposal.
  • A partially completed phase 2 proposal.
  • A partially completed phase 1 proposal.
  • A full phase 1 proposal with a partialy completed phase 2 proposal.
  • [How about a full phase 1 proposal (analogous to the cases above for phase 2)]

http://ra.stsci.edu/apst/apt/apt-visit-planner/