	Draft Requirements for handling Solar System Targets with APT

   Here is a sketch of the requirements for APT to be able to handle Solar System 
Target (Moving Target, or MT) proposals.  These proposals historically have made up 
5-20 percent of the total number of active proposals in a given cycle, and by their 
nature are among the more technically challenging to write and implement.  
   
   Some definitions: 
   
   MOSS is the Moving Object Support System, comprising the executable software (a 
program named "Percy") and the fundamental ephemeris data for the Solar System. This 
was originally a stand-alone system, but has become more integrated with the rest of 
the ground system in recent years.  It's capabilities include computation of 
ephemerides of all planets and most known satellites, numerical integration of comet 
and asteroid orbits, computation of timings of geometric events such as eclipses, 
angular separations and sub-earth longitudes, and graphic display.   

   The Solar System Target List (SSTL) is the section of the Phase 2 program that 
contains all the specifications of a Moving Target.  These include the exact 
description of the target in terms of Level 1, 2, 3 bodies, and geometric location 
relative to these bodies in a variety of coordinate systems, (longitude-latitude, 
position angle-radius, etc.)  The SSTL also contains the target-local geometric 
timing constraints. The SSTL contains all of the information required by MOSS
to process a target.
   
   Target Local constraints are time constraints that are imposed by the geometry of 
the target.  Examples include eclipses or occultations, angular separations, and orbital 
longitude ranges.  These are distinct from spacecraft constraints like target 
visibility, SAA crossing, etc.  The MOSS system is solely responsible for computing 
Target Local constraints, and is not used to compute the kinds of constraints that 
apply equally to fixed and moving targets.
   
   Level 1 bodies are objects that orbit the sun.  Single planets (eg Venus), 
asteroids, comets, and centers of mass of satellite systems (eg the Jovian system 
and the Earth-Moon system) are all Level 1 objects.
   
   Level 2 bodies are objects that orbit or circle Level 1 bodies.  Examples would 
include a Jovian Satellite (eg Ganymede), or a surface feature on a planet (Olympus 
Mons on Mars).  The hierarchy is explicitly specified in the SSTL. An observer 
wanting to center an aperture on Ganymede would specify Jupiter as the Level 1 body 
and Ganymede for the Level 2 body.  (Strictly speaking the Level 1 Body would be the 
Jovian system center of mass, but the software understands this distinction internally)
   
   Level 3 bodies continue the same hierarchy, and are defined relative to Level 2 
bodies.  Examples include a surface feature on a satellite (Pele Volcano on Io) or a 
satellite of a satellite (I can't think of any.)  This hierarchy could be continued 
indefinitely, but only Level 3 is supported.
   

   LEVEL 0 REQUIREMENTS:  
   
   These are current capabilities in RPS2 that are actively used. RPS2 cannot be 
retired until it's successor has demonstrated all of these capabilities.
   
   o  Spelling and Syntax checking of the Solar System Target List (SSTL).  
   
   o   Basic ephemerides for Level 1 bodies.  These are data files that are
       pre-computed by MOSS and are used for schedulability and feasibility
       computations where the position of the target is necessary.  RPS2 uses the
       Level 1 body in all these computations, since Level 2 and 3 bodies are always
       within a few arcminutes of their Level 1 body.  This reduces the amount of
       ephemeris data needed by RPS2 to 7 files, one each for Venus, Mars, Jupiter,
       Saturn, Uranus, Neptune, and Pluto.
      
       There are two formats in use for these files.  The .trh file contains ascii
       state vectors, and the .cby file contains binary Chebychev polynomial 
       coefficients.  It is desirable to be able to read both kinds.  The .cby file
       is used operationally, but is computed very slowly, while the .trh file 
       is computed quickly.  
        
       This requirement is simply that the files must be supplied with the software
       package.
      
   o   Ability to read and use pre-computed ephemerides.  Feasibility and 
       schedulability calculations require knowledge of the location of the target.
       For targets whose Level 1 bodies are planets, the ephemeris files detailed
       in the previous requirement are used by default.  There must also
       provision for reading user-supplied or locally-computed ephemeris files of
       the same types listed above.  RPS2 currently has no capability to compute
       ephemerides, but can use a .trh file if it is placed in the same directory
       the .prop file lives in.  This capability is generally used for comets and
       asteroids. The orbital elements are supplied by the proposer in the SSTL and
       integrated by Program Coordinators.  The files are e-mailed back to the RPS2
       users.  RPS2 gives appropriate diagnostics about whether or not it found and
       can use these files.
       
    o  Ability to read and use pre-computed target-local window files.  Occasionally
       it is desirable to include target-local time constraints in RPS2
       schedulability computations and display. These are handled in the same way
       as comet and asteroid ephemeris files. They are computed at the STScI and 
       mailed to the user. (They are used only "occasionally" simply because of the 
       extra effort involved; it'd be better if they were always present.)

   LEVEL 1 REQUIREMENTS FOR APT/VTT:
   
   These represent genuine advancements over the current capabilities of RPS2, and 
have been considered good candidates for RPS2 if we were to continue developing it. 
These would significantly improve Phase 2 development for Solar System observers, 
and are believed to be easily realized, since most of the underlying machinery is
already in existence.
   
   o   Invoke MOSS to process the targets in the SSTL automatically when the Phase 2
       program is processed. Transformation currently has the capability to generate
       MOSS command scripts directly from the SSTL, which are used operationally
       without intervention to generate the MT ephemeris and window files required
       for flight. What's required is to design the control mechanisms that would
       automate this process. The computations can be done at a much lower level of
       precision than is required for flight.
       
       The benefits would include 
       
       - Automatic inclusion of comet and asteroid ephemerides without any required
         interaction with the Program Coordinator;
       
       - Automatic inclusion of target-local timing constraints in schedulability
         calculations and display. This would be very beneficial, as it is easy to
         construct sets of target-local timing constraints which individually seem
         quite reasonable but whose intersection with each other or with other HST
         timing constraints is null.
         
         Even experienced Program Coordinators can mis-judge the difficulty of 
         scheduling a program without this knowledge.  Currently, MT programs are 
         submitted when they are "probably" schedulable according to the author's 
         and PC's judgment, but it is not known for sure until in-house processing
         produces and intersects the target-local timing constraints.  Giving 
         the proposers this capability precludes unschedulable proposals from ever
         being submitted - and grants us the moral authority to refuse to accept
         MT proposals that are unschedulable at the Spike/RPS2 level.
         
       The necessary steps are:
       
       - Generate the MOSS script directly from the SSTL (Trans currently knows how
         to do this);
       
       - Invoke MOSS to execute the script (as simple as starting up Percy with the
         name of the script as an argument);
       
       - Place the resulting .trh and .wnd files in the appropriate locations where 
         they can be found and used.  RPS2 currently knows how to take it from there.
         
       Some issues to be resolved include:
        
        - Bundle all of MOSS with APT or devise a remote server similar to the 
          current guide star server?  A bundled version could be offered separately
          from the "standard" version, that only MT observers would need to
          down load.  
          
        - Intelligent change detection would be needed so that MOSS was only invoked
          where necessary, and to determine when the existing files are not usable.
          
        - User control of the process.  The user should be able to disable MOSS
          execution to save time.  It would be desirable to allow the user to
          specify the time bounds over which to perform the computations.  Many 
          MT observations are very time constrained and the observer knows exactly
          when the event will occur; it would be extremely inneficient to compute
          lengthy time spans which are known to be useless.  (RPS2 currently knows
          how to deal gracefully with ephemeris and window files that do not span
          the entire planning interval.)
          
   0  Finder Charts.  We have existing software that can write MOSS scripts to
      generate finder charts. When MOSS runs the script, a color postscript file is
      generated that shows the target position, the HST apertures in their correct
      orientation, and any Solar System objects that fall within the field of view.
      The Solar System objects are modeled as tri-axial ellipsoids, in their correct
      orientation and location for the time specified, and drawn in wire-mesh
      format.  MOSS takes care of all of this; the script merely specifies the time,
      instrument, pointing, and size and orientation of the field of view.
      
      A simple implementation would be to allow the user to specify a time
      and a target in the SSTL, and display the resulting postscript files
      using ghostview.  This capability currently exists in the PC Tool-box.
      
      A better implementation would be to allow the user to choose a visit and have
      the software compute a time when the visit is schedulable, and display the
      targets automatically in a format consistent with the conventions of the 
      APT or VTT.  It would be desirable to retain the ability to choose a specific
      target and arbitrary time.
      
      It is probably not necessary (or even possible or desirable) to integrate MT
      target display with fixed-target image display capabilities; the paradigms are
      quite different.  Consistency in user-interface look and feel is sufficient.
      Solar System observers seldom care about the starry background their targets
      are found in. Such a capability might be useful for BOP checking, if that 
      process intends to use the APT.
	      
    LEVEL 2 REQUIREMENTS: 
    
    It is doubtful if there are any.  We have long taken the position that 
observers who need capabilities beyond what can be specified in the SSTL should get 
an account or download a copy of the MOSS system itself and use it directly.  Any 
integration of MOSS and APT/VTT beyond the above probably amounts to writing a GUI 
to MOSS. While this might be a worthy project in itself, it's not related to APT and 
MOSS has an elegant and easy to learn CLI that fits the computational and scientific 
paradigm very well. 



