Potential proposers for the GHRS may be interested in answers to some of the questions we have received: 1. Geocoronal Lyman-alpha through the SSA. If an object is observed in Dark Time, the relative quietness of the sky and the small size of the SSA mean that geocoronal Ly-a is coming through at a rate of only 0.02 to 0.03 counts per second, most of which is falling on one diode. This is only a factor of 2 or 3 above detector dark noise. 2. Spectrum bandpasses and dispersions. The GHRS Instrument Handbook provides typical values for these quantities for the various gratings. However, in certain situations one needs to know a precise value. We will include an algorithm in the next version to allow you to do this, but for the present if you need precise information on what wavelengths can be centered on or the bandpass achieved at a particular wavelength, please contact us. 3. Acquisition counts. The GHRS Instrument Handbook now recommends that you achieve 1,000 to 10,000 counts in the peak pixel during an acquisition. Those values were based on the old Point Spread Function. The high contrast of the post-COSTAR PSF means that that condition can be relaxed. It is our opinion that satisfactory acquisitions should be achieved with about 100 counts in the peak pixel, that value allowing for some error as well when estimating. This may be of particular value in acquiring faint objects if you are confident of the UV flux (perhaps from an IUE observation) and so can make a good prediction. 4. Achieving high signal-to-noise on faintish objects. A recurrent problem is applying FP-SPLIT to not-so-bright objects to get the best possible S/N. The objects are bright enough to get the needed overall S/N, but that needs to be broken down into segments that are only 5 to 10 minutes long, and within one of those there may not be enough counts to do a good cross-correlation to register the spectra. The carrousel positioning is, unfortunately, not reliable enough to do the registering without the ability to do the cross-correlation. There is no easy cure for this. One possibility is to specify discrete grating positions at which to integrate instead of using FP-SPLIT. One would then obtain a WAVECAL for each position. If the separate exposures were pushed to 10 minutes each, the fraction of time spent on WAVECALs is not too excessive. 5. Overhead times in special cases. The nominal overheads listed on the worksheets that come with the Phase I Proposal Instructions are adequate in most cases, but occasionally one may wish to obtain a large number of repeated exposures on an object and to get them with better S/N than RAPID mode allows. For example, if NUM-EXP (repeat observations) were specified for a WSCAN, the full set of repeats would be done first at the initial wavelength, then the carrousel would be moved and a second series obtained at the second wavelength. In other words, the wavelengths would _not_ be cycled through repeatedly. In this situation, the true overhead time per repeat is about 5 seconds. As a concrete example: Suppose we use STEP-PATT=5, which has a minimum cycle time of 27.2 seconds, and also specify 999 repeats (1,000 exposures total). The total exposure time is then 1000x27.2=27,200 seconds. During this operation the overhead would be 4 minutes plus 1000x5 seconds, or 5,240 seconds. The overall duty cycle is then about 79% (84% from these numbers less a 6% correction for the time spent looking at background). Other STEP-PATTs could be used to get shorter exposures, but with less on-target efficiency (high percentage of overhead time). 6. The memory problem. As noted in the Instrument Handbook, observers can run into a problem if their program specifies so many instructions that too much onboard memory is used. The typical limit is about 40 separate ACCUMs (each taking its own Exposure Logsheet Line) or, equivalently, 10 FP-SPLITs that each have four set points. A WSCAN with 40 individual wavelength set points would also cause a problem. However, the number of repeats on an Exposure Logsheet line (NUM-EXP on the Phase II Proposal) does _not_ create a memory problem. In the above example, an ACCUM with NUM-EXP=999 would not cause a memory problem. D. Soderblom July 29, 1994
