June 14^th, 2001 APT Visit Planner Meeting at 1:30pm in N310

Leslie said she could demo Spike and RPS2 for us at an upcoming meeting. [She is out on the 18th, so we'll shoot for the 25th.] Karla says operational proposal 9105 is a good one to use for a Spike/RPS2 demo.

Will we need somehow to sanity check for the visit planner such as Trans can provide for Spike?

HST visits are designed to be as independent as possible.

The OCM provides sanity check only for exposure level details, not visit level ones which would be pertinent to the visit planner.

Catching "sanity" problems like two targets in a visit too far a part is better.

We talked alot about whether or not it is meaningful to think that observatory restrictions (ObsyRns) and observation requirements (ObsnReqs) are similar things and decided that they are.

From Spike's perspective, the ObsnReqs are input data, whereas ObsyRns are part of the "code" (or definition of the software system).

But, both the ObsnReqs and ObsyRns are just constraints on the control of the observation.

We had problems with both the "Scheduling Constraint" term and "when" in the definition since ObsnReqs and ObsyRns in and of themselves don't, in general, aren't temporal constraints (except for those that are explicitly temporal).

We changed "Scheduling Constraint" to become "Observation Constraint". We also decided to use "Observer Requirement" in place of "Observation Requirement". So, for things that constrain an observation, we came up with these terms:

• Observer Requirements (ObsvrReqs): The requirements which observers place on observations to meet science goals.
• Observatory Restrictions (ObsryRns): The restrictions which an observatory places on observations as a matter of policy or physical limitations
• Observation Constraint (ObsnCsnt): An Observer Requirement or Observatory Restriction that constrains the circumstances under which a visit may be scheduled.

We also added a new concept of the thing it is that actually becomes a temporal constraint. That we called a Scheduling Constraint. For example, the combination of a minimum sun angle with an RA and DEC constrains when a visit can be scheduled. (And note, that neither one alone, sun angle or target position does not constrain when a visit can be scheduled.)

We didn't like timeline since that implies a sequence of events. The group gravitated towards "Suitability Windows". [However, RPS2 uses "Scheduling Windows", so we may want to consider Scheduling instead of Suitability.]

For the "Total" windows, we liked "Total" or "Overall". [RPS2 uses "Total".]

• Scheduling Constraint: An observation requirement or observatory restriction that constrains when a visit may be scheduled.

• Scheduling Time: A timeline that indicates when a visit can and cannot schedule.
• Total Scheduling Timeline: A scheduling timeline that takes into account all scheduling constraints.
• Specific Scheduling Timeline: A scheduling timeline that takes into account only a specific subset of scheduling constraints.

  [[Actually "specific" is a somewhat unspecific word. How about "Scheduling Constraint Timeline" or "Specific Constraint Timeline" for timelines that encompass a single constraint and "Partial Scheduling Timeline" for timelines built from a subset of constraints.]]

• Scheduling Violation: A point on a scheduling timeline at which a visit cannot schedule.
• Scheduling Success: A point on a scheduling timeline at which a visit can schedule.

Violation to me connotes that the observer has made some type of error, whereas success to me connotes a situation where the visit has actually been scheduled as opposed to a particular point on the timeline.]]