Bright Object Tool Meeting Minutes (6/29/00)
--------------------------------------------

Attendees: Tony Krueger, Ron Downes, Ray Lucas, Steve Lubow, 
Jesse Doggett, Mike Asbury, Ed Hopkins, Karla Peterson 


Goal of this meeting: Move towards selecting an implementation so we
can start considering the cost.

Discussion of motivation for BO Tool
------------------------------------

1) How many proposals in cycle 9 had a bright object problem that had
to be sent back to the PI?

   Ron guesses 5 + 5%, but this small number of the problem proposals 
   require a disproportionately large amount of work.

2) How many proposals in cycle 9 had to change as a result of the
bright object problem?

   (Same as 1)

3) How difficult is it for a PI to predict and analyze bleeding
problems? Could they run the ETC on suspect objects and then choose an
orientation in the VTT?

   Ron says that it is difficult now, but certainly not impossible. 

4) If we don't provide a PI tool, what impact will that have on
the PI's ability to evaluate bright object issues for their science?

   Ron thinks that having the tool would reduce HOPRs and improve
   science. It would also improve the archive.


Ron told us how bright object checking is done now:

   Only health and safety checking is currently done. 

   On all MAMA imaging observations, special requests are made to CASB 
   to extract the GSC2 data and then individually evaluated using ETC.

   The bright object alerts that are returned from NGSS processing are
   used to do worst case checks on spectroscopic targets and it gives many 
   false alarms.

   Mike's tool adds the value of automatically extracting GSC2 info and 
   superimposing on DSS images.  

   But the CS will still need to consider each star found in the GSC2
   query. They will have to compute a V magnitude and gross spectral
   type from the F and J magnitudes in the GSC2. Then they will have
   to feed this information into the ETC to derive a count rate. In
   other words, even with Mike's tool, doing health and safety
   checking for MAMA imaging will be labor intensive. (And note that
   ACS will also have a MAMA Imaging mode.)


Ron indicated that the call to the ETC in his previous requirements
could be eliminated and that lookup tables could suffice given the
uncertainty of the derived spectral types. The tables would contain
count rates for configurations for a one second exposure and that
could then be scaled to the actual exposure time. (This assumes a
linear response of the detector.) He thought this would be fine for
STIS, but still needs to check with the other instrument teams to
confirm that these assumptions were good for all the detectors.

The CTE (charge transfer efficiency) calculation would require a call
to a different tool, but since it was in the requirements as a "nice
to have", we will most likely not to this, at least in the near term.



Review of Steve's Ideas
-----------------------

(Comments from the meeting are prefixed with ###)

Steve's Suggested Interim Design:

For PIs:
--------
1) Decide which exposures to check

	PI decides to check an exposure

### PI may already have a particular concern or they may want to process
### all the exposures in the proposal.
###
### The PI may also find out about problem from the CS and then skip to the
### display using data sent by the CS.


2) Collect required exposure information

	PI types information into a data entry box

### Or possibly take the information from a file.  It would be some sort 
### of manual process because it wouldn't make sense to spend time
### developing a system that take the information from an RPS2 file.
### (And we won't be requiring use of this tool in Cycle 10.)
### But for cycle 11, consider more automated means, possibly getting info
### from the APT's internal state.


3) Decide how large an area to check

	Size of macroaperture
	Let user decide

4) Retrieve information on objects in area

	Use GSC2

5) Discard objects that won't be a problem

### Using the lookup table, the objects not discarded are the bright objects.
### (Assuming that we have been able to get rid of the ETC step.)


7) Report problems

	Text report
	Display:
		Objects
		Macroaperture
		Against DSS image

### Or optionally display bright object data without an image.  Skycat can 
### do this and it would be faster to not retrieve the DSS image. The user
### can decide later to go back and display with a DSS image.

		In a fully live VTT


For CSs:
--------
1) Decide which exposures to check

	Query ASSIST and CS selects exposures from list
	Query ASSIST and batch process all unique exposures

### Weaknesses of using Assist: It doesn't have the patterns expanded, 
### and if there is no orientation specified the pattern could go in
### any direction. So a very large area would need to be checked.
###
### We could either make the tool learn to calculate the extent of a pattern 
### or pop up a warning that there was a pattern but it is not being
### taken into account.


2) Collect required exposure information

	Query ASSIST

3) Decide how large an area to check

	Size of predefined "superaperture"
	Size of extent of pattern

4) Retrieve information on objects in area

	Use GSC2

5) Discard objects that won't be a problem

7) Report problems

	Text report
	Display:
		Objects
		Macroaperture
		Against DSS image
		In a static image on the web

### There is no compelling reason to have the static image.  It is
### advantageous to have the CS and PI looking at the same thing.
### And as noted before, the input file to the VTT should be mailable
### to the PI.

### The CS process is more automated and will usually use the text 
### output (which might be e-mailed back) to alert when there are 
### bright object's of concern for any of the visits. Then the Cs
### would bring up the VTT to examine the bright objects.


Jesse's Idea
------------

The main differences were to have a server at STScI that takes an RPS2
file from the user and processes it through to a mock PMDB (like the
RPS2/NGSS server) and does all the bright object checking from that
data.  Also we would devise a VTT-lite for display that only works
with fields for bright object data.

But, we've decided that having the user manually input the info is
acceptable for now, and to use a lookup table instead of the ETC.  So,
having a server with a mock PMDB at STScI is a more expensive interim
solution.

Also, we've decided that it's okay to allow the GO to have access to
all the target tuning capabilities of the VTT on hand when doing
bright object analysis.  So, there is no need for a special bright
object tool.

So, nix that idea.


Additional Discussion
---------------------

Because we're going to a lookup table instead of the ETCs, the only
bottleneck will be reading GSC2 (and optionally reading DSS images).
It would be good for Mike to do some timing tests on large sets of
GSC2 requests.

If the GSC2 requests are fast enough, an interactive mode might be
possible for one at a time field analysis, but not if you're driving
from a file with many exposures.

For patterns, Ron believes there are only a few proposal per year with
large mosaics (as opposed to dithers).  Ron will investigate how many
we get.

In the future when the tool is less cumbersome to use, we will
probably require all MAMA imaging proposers to run the bright object
tool before submission. They can then do the work to prove that the
object in question is not really a problem, or choose a new pointing
ahead of time.

We need to ask the instrument teams for the default "super apertures".

How generic a tool is this that we are creating? Will other telescopes
need a bright object checker? Could be - and maybe it would only
require that the lookup tables be replaced.


Review design we have agreed on
-------------------------------

IP = Interim PI Tool 
LP = Long Term PI Tool
C = CS Tool

1) Decide which exposures to check

IP	PI decides to check one or more exposure(s)
LP	APT user selects one or more exposures and requests processing
LP	Query APT internal state - batch process all unique exposures
C	Query ASSIST and CS selects exposures from list
C	Query ASSIST and batch process all unique exposures

2) Collect required exposure information

IP	PI types information into a data entry box
IP	PI types information into a flat file
LP	Query APT internal state 
C	Query Operational ASSIST

3) Decide how large an area to check

	Size of macroaperture
	Size of predefined "superaperture"
	Size of extent of pattern
	Let user decide

(Ron will ask teams what they want for this)


4) Retrieve information from GSC2 on objects in area

5) Discard objects that won't be a problem based on lookup tables

6) Report problems

	Text report which lists which exposures have problems
		(can to mailed back to CS)

	Text report which lists problems (for review w/o VTT)

	Intermediate file:

		Which would be mailable to a PI

		Which would allow you to select exposure for display

		Which would allow results to be displayed in the VTT

		In the VTT all field objects identified should be
		displayed in way to differentiate problem objects.
		(This could use the catalogs feature.)

		In the VTT there should be some way to tell how large
		an area was checked. (A dotted line would be fine.)

		In the VTT if an exposure does not have an exact orient
		then only the inscribed and circumscribed circles
		should be drawn for the aperture. But you need to be
		able to switch on the aperture so that orientation
		can be investigated.
		
		In the VTT you should be able to display against a
		blank field or any FITS image
		


Action Items
------------
Jesse/Karla: Produce minutes of this meeting.
Ron	  : Investigate demographics of past pattern request.
	    Find out from instrument teams:
	      - If all detectors are linear to enable exposure time scaling.
	      - If it's adequate for all instruments to compute count rates
	        from a lookup table given the uncertainty in spectral types.
            Update requirements based on these minutes.
Mike	  : Determine how long it takes to access GSC2.
Mike/Jesse: Scope out a design and come up with a cost.
Jesse     : Organize next meeting.