VISIT PLANNER CHARTER ===================== Goal ==== Develop and Field an APT visit planner tool. Current Concept & Requirements Talked About =========================================== 1) Visit Planner will interact with CASM (Spike) 2) Visit Planner will display CASM schedulability information 3) The Visit Planner GUI will interact with CASM (Spike) in a Batch model. That is somehow a PI selects a set of Visits to get schedulability information on. Could be 1 to all in the proposal. Spike is called to process all the visits and the results are displayed in the visit planner GUI. 4) Spike team probably can't support a change to their interfaces for APT. Probably should use the RPS2 file input and output model. That is, VDF, LDF, Diag, Descrip. The APT orbit planner would have to create the VDF and LDF files from the APT data model. The APT orbit planner would have to read the diag/descrip files. Could change the interface but need to make sure Spike team can support it. 5) An original concept was that the Visit Planner would allow PIs to graphically edit their visit links (ie., after, before). Not sure if this is a must have requirement or even a requirement anymore. Gary and Rob are developing a Phase 2 editor which will have to support entering Visit spec reqs. Should talk to them about their plans. We definitely don't want to develop two different models for this. One editor for all of APT is the goal. 6) Development Only. It is envisioned the Spike will run as a remote server and as a local server. Coordinate with Tom D since the orbit planner (transverse) has the same requirement with Trans. Tom had this on his plate to do. 7) There is an unresovled issue with the Trans interface to Spike in APT. In RPS2, Trans writes a TIC file which specifies information about the orbit visibility used. Spike uses this info to calculate is schedulability info. Jesse to coordinate with Tom on the need for this file interface or will things be shared through the APT data model. In RPS2, Trans must run before Spike. We may want to relax that constraint in APT. If trans didn't run on the Visit Spike is processing, we could just us a orbit visibility based on some efficiency number. To Spike its just a set of numbers. Something to look into. 8) How will we support Guide Star Availability in APT. Today it affects schedulability in RPS2. How will we integrate the current RPS2/NGSS work into the visit planner. If we have to slip a capability, I think the Guide Star capability is an area in the VP which could slip. Not many users of this capability. Other Tools to Evaluate for Applicability ========================================= 1) SEA group developed Volt which already does the following in a prototypic way. - Uses CASM as an engine in a remote server model. - Generates VDFs, LDFs for CASM input - Displays scheduability output (not sure if it reads diag/descrip files) The Output is more dynamic that the DG. The DG is pretty static. - Not sure what it does about the TIC (trans info). Probably just uses a number for all visits. - May want to use a paired down version of VOLT since Volt is designed to work with multiple observatories. Our APT case is the degenerate case, one observatory. 2) Look at RPS2 DG output for what to preserve/change. Working Group Reporting ======================= 1) Visit Planner Development area off of APT page 2) Create Group email for group communication Group Members Role ============= ==== - Chris Odea Science Input - Trisha Royle Operations Input - Jesse Doggett Development - Karla Peterson Testing Meetings and Effort =================== Meeting schedule to be determined by the working group. Schedule & Deliverables ======================= 1) We will have to have a concept/requirements review for the tool. Hopefully in the July timeframe. 2) Would like to release a prototype that is integrated in the APT top level GUI as a tool to the community for Phase2 Cycle 11 use (jan 2002). What this prototype will do is nebulous and nothing has been publicised about the capabilities. We have said we plan to release a prototype. 3) Would like to release an Operational Visit Planner for cycle 12 Phase 1. Main reason is to have 6 months to get feedback before Cycle 12 Phase 2 release. 4) The ultimate goal is to have a operational Visit Planner for Cycle 12 Phase 2 (jan 2003). Priorities for Cycle 12 Phase 2 =============================== 1) Support RPS2 schedulabilities in APT VP (Required) 2) Support NGSS/RPS2 capabilities in APT VP (Required or Would Be Nice?) 3) Support Coordinated Observing (would be nice)