Marco Morais                                                    06/26/08
                                                        revised 07/02/08
                  revised upon consultation with Peter and Karl 07/10/08
                           revised upon consultation with Peter 07/11/08
                               revised after completing reports 08/01/08

The following document describes the observation reports generated for all 
cycle 5 proposals.

--------------------------------------------------------------------------------
                        Automated Observation Reports
--------------------------------------------------------------------------------

 #1 Brightness Check

  Brightness check with observation position read from the proposal.
  There will be no brightness check for NA positions.

    NUV zodiacal light value of 20 kcps will be used for all reports
    in order to be consistent with what was used by the GI during 
    the proposal development process.

    A 'PASS' or 'FAIL' result will be displayed in the GITR form for each 
    of the 3 tests performed by the brightness checker { 'Bright Star', 
    'Total Field', and 'Overcountrate Position' }.  A link to an offline 
    copy of the product page will appear in the GITR form for all of the 
    details of the tests.

    Applicable to archival observations for purposes of review: No.

    List of Applicable Issues: { brtcr, cr, glblcr, ovlpocr }.

 #2 Sky Plot

  Sky plot with observation position read from the proposal.  There
  will be no sky plot for NA positions.

    The sky plot width will be 5 deg.  Archival observations will
    appear on the plot.  A TOAST search with the following parameters
    will be used to generate the list of archival observations to
    appear on the plot: { cone search with radius of 4.5 deg.; no
    AIS; no CAI; no grism }.  Science targets from the current 
    observation will appear on the sky plot.

    The sky plot image will appear inline with the observation in
    the GITR.  A link to an offline copy of the product page will
    appear in the GITR form for all of the other details describing
    the appearance of the plot.

    Applicable to archival observations for purposes of review: No.

    List of Applicable Issues: { }.

 #3 MPS

  The MPS report is constructed by running the visibility tool with the
  observation position read from the proposal.  There will be no
  MPS report for NA positions.

    The visibility tool will be run for all of 2009.  The visibility
    tool will be modified so that a file containing the following
    information is written: { minimum NUV zodiacal light during the 
    visibility period; maximum NUV zodiacal light during the 
    visibility period; diffuse galactic emission; # of visibile eclipses; 
    visibility ratio }.

    The visibility plot image will appear inline with the observation
    in the GITR.  In addition, each of the parameters written to the
    file above will appear in a table in the GITR form.  A link to an
    offline copy of the product page will appear in the GITR form
    for all of the other details describing the appearance of the plot.

    Applicable to archival observations for purposes of review: No.

    List of Applicable Issues: { vis20, vis5 }.

 #4 Archival Overlaps

  The archival overlaps report is constructed by performing the 3 overlap 
  tests described below (A1, A2, B1) for each science target in the 
  observation.  There will be no archival overlaps report for NA positions.

    A TOAST search with the following parameters will be used to generate
    the list of archival overlaps for each science target: { point search
    with the position and diameter corresponding to values from the
    science target; the search radius will be the GALEX FOVR 0.5 deg.;
    no AIS; no CAI; same optics wheel setting as proposed observation }.  
    In the tests below, the value of the 'Total Exposure Time' field in 
    TOAST will be used.

    The following tests will be performed for each science target using 
    the list of positions returned by the TOAST search for that science
    target.

    (A1) Is any single archival observation able to satisfy >= 80 %
         of the GI requested exposure time? ('T' = yes, 'F' = no)
    (A2) Is the sum of all the archival observations able to satisfy
         >= 80 % of the GI requested exposure time? ('T' = yes, 'F' = no)
    (B1) Using the sum of all the archival observations computed in (A2),
         compute the difference between the GI requested exposure time
         and the sum from (A2). This sum is the time needed for a new
         observation.  When this value is less than 0 (eg GI requested
         exposure time is satisfied by (A2)), then the value will be
         reported as 0.

    The 80% threshold should be settable from the command line interface 
    of the script used to generate the automated observation reports
    because it is subject to change in the future.

    The following table will appear in the GITR form (notes: STX = Science 
    Target # X).  All tests will be performed and reported and a link to
    TOAST query for each science target will be displayed.  The goal is 
    that all of the information be presented to the analyst and for the
    analyst to make a determination as to whether the A1, A2, or B1 options
    are applicable.

    TOAST   A1      A1      A1       A2      A2      A2        B1
     link result   exp./  obsvtn.  result   exp./  obsvtn.  new exp.
                   %sat.   name             %sat.   names    needed
    --------------------------------------------------------------------------
    ST1    T/F     X/%      ''       T/F     X/%      ''        X
    ...    ...     ...      ...      ...     ...      ...      ...
    STN    T/F     X/%      ''       T/F     X/%      ''        X
    --------------------------------------------------------------------------

    ***THE METHOD FOR SYNTHESIZING THIS INFORMATION INTO A SINGLE OBSERVATION
       VALUE FOR THE 'OVLPARCH' ISSUE IS TBD.***

    ***I WOULD RECOMMEND THAT THE ARCHIVAL OVERLAPS TESTS BE ENCAPSULATED IN
       A NEW CGI PROGRAM FOR THE PURPOSES OF USE BY GIS NEXT YEAR AND IT
       WOULD FACILITATE INTEGRATION INTO THE GITR FORM THIS YEAR.***

    Applicable to archival observations for purposes of review: Yes, only for 
    archival proposals where the value of the specialcoadd xml element is 
    set to 'YES'.

    List of Applicable Issues: { ovlparch }.

 #5 Same GI Overlaps

  The same GI overlaps report is constructed by looking for overlaps
  between the current observation and all other observations in the
  proposal.  There will be no archival overlaps report for NA postions.

    The following test will be performd for each observation.  The
    angular separation aka offset will be computed between each new
    (eg non-archival) observation center position and the center position 
    of all of the other new (eg non-archival) observations in this 
    proposal with the same optics wheel setting.  Any observation having 
    an offset <= 1 deg. will be considered to be in violation and the 
    applicable issue, ovlpgisame, will be set.

    The GITR form will display the following table only for observations
    that are in violation (notes: OBSX = Observation # X).

    Obs.  Obs.  RA   DEC       Offset
    Name  Num              (deg) (arcmin)
    ---------------------------------------
    OBSX   X   ...   ...    ...     ...
    ...   ...  ...   ...    ...     ...
    OBSN  ...  ...   ...    ...     ...
    ---------------------------------------

    There will be no links to other products for this report.

    Applicable to archival observations for purposes of review: No.

    List of Applicable Issues: { ovlpgisame }.

 #6 Other GI Overlaps

  The other GI overlaps report is constructed by looking for overlaps
  between the current observation and all other observations in all
  proposals for this cycle.  There will be no archival overlaps report 
  for NA postions.

    The following test will be performd for each observation.  The
    angular separation aka offset will be computed between each new
    (eg non-archival) observation center position and the center position 
    of all of the other new (eg non-archival) observations having the same 
    optics wheel setting in all of the other proposals for this cycle.  Any 
    observation having an offset <= 1 deg. will be considered to be in 
    violation and the applicable issue, ovlpgioth, will be set.

    The GITR form will display the following table for any observations
    that are in violation (notes: PROPX = Proposal # X, 
    OBSX = Observation # X).

    Prop.  Obs.  Obs.  RA   DEC       Offset
    Num    Name  Num              (deg) (arcmin)
    ---------------------------------------------
    PROPX  OBSX   X   ...   ...    ...     ...
     ...   ...   ...  ...   ...    ...     ...
    PROPN  OBSN  ...  ...   ...    ...     ...
    ---------------------------------------------

    There will be no links to other products for this report.

    Applicable to archival observations for purposes of review: No.

    List of Applicable Issues: { ovlpgioth }.

 #7 New Predecessor Test

  The new predecessor test is constructed by comparing the offset
  and exposure time of the predecessor supplied as input with the
  criteria for new predecessors.  There will be no report for
  imaging observations and no report for grism observations that 
  propose archival predecessor(s).  The report for grism observations
  that are NA positions and use new predecessors will implicity
  apply the offset criteria to pairs of positions at (0., 0.);
  the outcome for these predecessors will be solely based upon
  exposure time criteria.

    The criteria for new predecessors are: { offset between the 
    grism observation center position and new imaging predecessor
    observation center position <= 1.0 arcmin; the predecessor time 
    must be exactly 5% of the grism observation rounded up to 1.5ks; }.

    The results of each criteria will be reported as 'PASS' or
    'FAIL' as well as the intersection of the criteria with each
    other.  There will be no links to other products for this report.

    Applicable to archival observations for purposes of review: No.

    List of Applicable Issues: { prediadq }.

 #8 Archival Predecessor Test

  The archival predecessor test is constructed by comparing the offset
  and exposure time of the predecessor supplied as input with the
  criteria for archvial predecessors.  There will be no report for
  imaging observations and no report for grism observations that 
  propose new predecessor(s) and no report for grism observations that 
  are NA positions and use new predecessors.  Grism observations that
  are NA positions and use archival predecessors will always be
  considered failures.

    The criteria for archival predecessors are: { offset between the 
    grism observation center position and archival imaging predecessor
    observation center position <= 15 arcmin; the predecessor time 
    must be > 5% rounded up to 1.5ks; all of the science targets
    in the proposed observation must be completely contained by the
    archival predecessor }.

    A TOAST search will be used to obtain the coordinates and the
    total exposure time of the archival predecessor rather than 
    relying on the information provided by the GI with the proposal.

    The results of each criteria will be reported as 'PASS' or
    'FAIL' as well as the intersection of the criteria with each
    other.  There will be no links to other products for this report.

    Applicable to archival observations for purposes of review: No.

    List of Applicable Issues: { prediadq }.

 #9 Recommended Predecessor Test

  The recommended predecessor test is performed by supplying Tom
  with a csv file containing proposals, observations, and science
  targets.  Tom returns a recommended predecessor file, also in 
  csv format, that is passed as an argument to the automated
  report generation script, gitr_gen_prop_reports.pl.  The
  logic for parsing the recommended predecessor file is in
  the script, but is based primarily on the value of the 'pred_flag'
  field in the file.  The discussion below relates the use of
  this field to determine whether differences between the
  recommended predecessor and the GI supplied predecessor indicate
  that reviewer attention is required.

    # mapping from values in pred_flag field to human readable text
    my %pred_flags = (
      0   => 'no archival predecessor available',
      1   => 'predecessor adequate',
      2   => 'predecessor adequate',
      3   => 'predecessor adequate',
      4   => 'predecessor needs more time and/or special coadd',
      -1  => 'predecessor needs more time and/or special coadd',
      -2  => 'predecessor needs more time and/or special coadd',
      -3  => 'predecessor needs more time and/or special coadd',
      -4  => 'predecessor needs more time and/or special coadd',
      -9  => 'NA position, requires new obs. for predecessor',
    );

  The logic for mapping the flags follows.

  If the grism observation has a proposed new imaging predecessor,
  then do the following:  If Tom's flag is one of {0, -9} then
  reviewer attention is not required, else reviewer attention is
  required.

  If the grism observation has a proposed archival imaging
  predecessor, then do the following: If Tom's flag is one of
  {1, 2, 3} and the name of Tom's recommended predecessor matches
  the name of the proposed predecessor then reviewer attention
  is not required, else reviewer attention is required.

  Applicable to archival observations for purposes of review: No.

  List of Applicable Issues: { prednotopt }.

--------------------------------------------------------------------------------
                HTML Rewriting of GI Product Pages
--------------------------------------------------------------------------------

This is what I implemented to have the html rewriting work so that the 
pages work locally and on a machine without an internet connection.

I wrote a single program that is general purpose enough to be able to 
rewrite a page from any of the 7 types of products.  The program is
in cvs in soda/tim/src/perl/gitr-exec/gitr_rewrite_product_page.pl.

The GI runs and the automated runs will be rewritten before opening the
pages for review.  The reviewer runs will be rewritten after closing the 
pages for review.

The following is a description of the modifications that are made as
part of the HTML rewriting.  Each one of the modifications below is
encapsulated as a separate subroutine that is invoked from the HTML 
rewriting script.  The description of each modification appears as
a comment block immedidately preceeding the subroutine.

  # Search for all