Update Log:
Version 5.0, January 22, 2004: Revised for use in Cycle 5.
Version 4.0, January 28, 2003: Revised for use in Cycle 4.
Version 3.0, September 15, 2001: Revised for use in Cycle 3.
Version 2.0, October 20, 2000: Revised for use in Cycle 2.
Version 1.2, April 14, 1999:
Fixed Julian Date definition example at end of
section 4.2 (discussion of phase_zero keyword); also clarified JD vs. MJD.
Version 1.1, August 11, 1998: GI Cycle 1 version of Document.
The FUSE Public Web Page is http://fuse.pha.jhu.edu. From there you can get to the following resources:
The Phase 2 forms for FUSE Cycle 5 proposals will provide the Mission Planners with verified, detailed information that is necessary for scheduling approved observations. GIs will be provided with a partly filled-out Phase 2 template. Information is carried over from the Phase 1 submission to populate several fields. However it is the GI's responsibility to verify all the information in a Phase 2 form before submitting it.
This document provides supporting information and documentation to help GIs fill out the Phase 2 forms correctly. Instructions for submitting the forms are also given. Section 2 is a brief overview of the current FUSE mission planning procedures. Section 3 lays out some general considerations about the Phase 2 process. Section 4 provides a field-by-field description of the Phase 2 forms, including syntax issues. Allowed values or choices for each parameter are discussed. Section 5 contains instructions for checking and submitting Phase 2 proposals electronically. Appendix A contains filled-out example forms for reference on syntax and other matters, while Appendix B contains reference information on Target Classes (described below). Appendix C provides a checklist for Phase 2 submissions. Appendix D discusses the messages returned by the program that parses your submission and performs error and syntax checking.
2. FUSE Mission Planning Overview
The FUSE Mission Planning system is designed to handle many aspects of scheduling in an automated fashion. However, to simplify the process, we have decided to handle certain aspects of planning in a less automated manner, in particular, those situations that are needed infrequently. We have designed the forms and keywords to handle the "normal" situations in an efficient manner, but request text inputs to describe any off-nominal or uncertain situations or special needs. FUSE mission planners will handle these situations on a case-by-case basis, thus limiting the number of options that need to be supported by the automated software (and incidentally, making life easier for the user community by keeping the forms as simple as possible).
The GI in charge of each program will receive an electronic mail message containing a Phase 2 template file. This will be an ASCII file (note: NOT LaTeX as in Phase 1) containing a set of keywords. Entries for some keywords will be "required," while entries for others will be "optional," depending on the situation (see section 4 for details). GIs receive templates that have been partially filled out with information from Phase 1. (Refer to section 2 for details.) Since the forms will be in ASCII format, users can edit the files using whatever text editor they are familiar with.
The forms contain some fields requesting contact information, followed by a set of keywords that are repeated for each object. These fields provide both "object" and "observation" level information for each target, but there are NOT separate `target list' and `exposure logsheet' sections in Phase 2 as with HST proposals (for instance). In addition, information is requested that will permit planning personnel to validate the feasibility and safety of the requested exposures. We also require the user to submit a total expected count rate from each object, based on a simulated spectrum or exposure time calculation using the on-line tools provided for this purpose. A reasonably accurate count rate is important for verifying the safety of the instrument, as well as managing detector lifetime and onboard memory usage relative to downlink opportunities. Any situations not handled gracefully by the keywords can be described further in text blocks that accompany the Phase 2 submission. We emphasize that these text blocks will be read by the FUSE Scientific Operations, and Mission Planning staff and use the information for help in planning the program. Given the limitations (resources, staffing, etc) implied by extended mission operations, it is crucial that the science priorities and requirements of a program are clearly spelled out (but do be concise!). Is SiC data important to the investigation? What are the reasons behind any applied special requirements? etc. While the FUSE project strives to implement all programs as proposed, it is to the advantage of the proposer that the FUSE project staff at JHU can make the right calls if a fast turn round modification is required to allow the implementation of a given observation.
The user needs to supply very little instrument-specific information. The exposure times, spectrograph apertures, and the option to suggest the instrument mode (time-tag or histogram) are the only three items requested from the GI. We expect to be able to specify other instrument-related parameters based on the information provided by users in conjunction with the current knowledge of the instrument performance at a time much closer to the observation. Options are available in text blocks for users to provide any additional supporting information they think will aid in planning the observations properly.
After filling out the forms and supporting information, the Phase 2 file should be submitted electronically (see section 5). An initial submission to a test account is required to catch and correct syntax or identify other problems prior to the final, official submission of the Phase 2 form. (Multiple iterations with the test account can be made, if necessary.) A parser program running in this test account checks all incoming forms for proper syntax, safe flux levels, and consistency with Phase 1 allocations and allowed targets. This program generates a report that is returned electronically to the submitter. You should resolve any problems found by the Parser prior to officially submitting your program. Any exceptions must be cleared with FUSE personnel prior to official submission.
Upon submission, your program is parsed, processed, and ingested into the Mission Planning Database (MPDB). Additional parameters needed for planning will be calculated from the basic data provided by the user, guide star selection routines will be run, and input files will be created to support timeline scheduling.
3.1 Phase 2 Template File
3. General Phase 2 Considerations
In order to provide GIs with a convenient starting point for their Phase 2 submissions, we send partially filled out Phase 2 template files. Many of the keywords are populated using information from the corresponding Phase 1 proposal. It is extremely important to understand that it is the GIs responsibility to verify all the information in the Phase 2 from prior to final submission. The program ID, the title, the TAC allocation (targets and exposure times) and the PI and Co-I names may not be changed by the user. Other information may be edited or updated in the Phase 2 form. (Note: Co-Is can be added at this stage only at the discretion of the FUSE Project Scientist George Sonneborn. However, the PI may designate one of the Phase 1 Co-Is as the Lead Investigator. This is discussed in section 4.1 below.)
Text Blocks:
The Phase 2 template file is an ASCII file and will be parsed by our software. The Phase 1 proposals were in LaTeX and therefore the text blocks are NOT being carried forward to the Phase 2 forms. LaTeX formatting characters should not be included in any of the text blocks since they will confuse the parser. If you decide to cut and paste text from your Phase 1 proposal, please remove all LaTeX formatting characters. Your abstract should be carried forward directly from Phase 1, although modifications can be made based on changes suggested in the Peer Review process (if this is desired). The Phase 2 version will be archived with your data and will be available to the public. The text blocks requested are important for proper scheduling and will be read and used by FUSE personnel. Please describe carefully the needs of your program in the appropriate text blocks.
Allocations and Targets:
The observing time requested in Phase 1 may have been reduced or, in a few instances, increased as a result of the Peer Review process. The official program time allocation will appear near the top of the Phase 2 template. (Check this against your acceptance letter!) The submitted Phase 2 will need to conform to this allocation, including any time set aside for safety snap (SAFTSNP) observations (see below). For Legacy proposals, separate year one and (where applicable) year two allocations be given. To implement this separation of targets into first and second year allocation GI should select observations totaling the second year allocation and implement the Special Requirements keyword "HOLD" on these observations. The FUSE project will lift these HOLDs at the beginning of the next cycle.
Note that target and observation information is carried forward directly from your Phase 1 proposal! If the Peer Review has changed the allocation, the observing times listed in the observation sections will not add up to the official time allocated. It is the GI's responsibility to modify the requested observation times to comply with the official allocation. This information will be checked upon submission.
Some accepted programs may have had specific targets disallowed due to conflicts with other programs or for other reasons. Any such targets will NOT appear in your Phase 2 template, and should not be added back in. Also, you should NOT add new science targets to your program in Phase 2 (although specific exceptions may be granted by the NASA Project Scientist--see the NRA for details). However, users may need to identify offset stars for use in acquisitions. These can be added as needed in Phase 2, but are not considered science targets. (List any offset stars with priority = 4; see below).
Coordinates and Observing Information:
The target information (including co-ordinates and fluxes) will be carried over from the Phase 1 proposal into the Phase 2 template (assuming that the correct format was used in the former). Additional target information is requested in Phase 2. The user needs to review the information in the Phase 2 template, to update wherever necessary, and to supply the additional information requested.
The responsibility for verifying the accuracy of the supplied information rests with the user. It is strongly encouraged that target co-ordinates are checked using on-line services such as those provided by STScI (Digital Sky Survey and on-line HST Guide Star catalog). Please note that the coordinates given in the SIMBAD data base should be treated with caution as their accuracy varies from one object to another. In general, FUSE does not have the resources to perform independent checks on all of the information you provide in your Phase 2 submission, although we will perform consistency and safety checks on the supplied flux, count rate, and S/N information. Note that if we determined a S/N from the Phase 1 information substantially different from the S/N stated in the Phase 1, the discrepancy will be pointed out in a comment line in the Phase 2 template.
Special Requirements:
Special Requirements (SRs) are handled somewhat differently in Phase 2 than they were in Phase 1, with some being applied at the "object" level and others at the "observation" level (see below). In addition, several additional SRs are available in Phase 2 that were not needed in Phase 1. With the exception of the SAFTSNP SR, you should see SRs in your Phase 2 template as you specified them in Phase 1, but showing up in the appropriate object or observation-specific keyword. You should read section 3.8 ("Special Requirements") carefully and revisit whether the SRs specified in Phase 1 are still appropriate and necessary, and whether any additional SRs are required in Phase 2.
SAFTSNPs are a special case because they are only needed in certain circumstances and because they count against your program allocation. Any SAFTSNPs specified in Phase 1 have NOT been carried forward automatically into the Phase 2 template. This is because new, more specific rules have been developed for when SAFTSNPs are needed, and you are asked to reassess, on a case-by-case basis, the need for these precautionary observations. Details are provided below in section 3.3.
3.2 Time Allocations and Priority Assignments
Each accepted program receives a total on-target time allocation in ksec. The allocation is filled in near the top of the Phase 2 template file and also will be provided to you separately in the program acceptance letter. For two year legacy programs separate year one and two allocations are given. You should check that these numbers are the same and resolve any differences that may have inadvertently occured by contacting FUSE user support (fuse_support@pha.jhu.edu).
GI program target lists (except certain legacy programs) are built for an assumed one year cycle of observations. To help address possible contingencies, we ask that you prioritize your target list in the following simple way: Designate roughly half of the objects/observing time as priority "1" and the other half as priority "2". This will provide us information on relative priorities within a program in the event that a choice has to be made for targets within the program. These will NOT be used to judge priorities among different programs. (As a special case, offset acquisition stars are designated as priority "4", which indicates no science observation is intended. These targets do not get observation times assigned, and do not count against the program's allocation.) The total requested observing time should add up to the program's allocation. For legacy programs each year's targets should be similarly divided and designated.
SAFTSNP observations are charged at 2 ksec (because they effectively use an orbit of spacecraft activity, even though the exposure time is only 60 sec). SAFTSNPs do NOT get rounded up to the 4 ksec minimum observation charge.
3.3 Brightness Limits and Instrument Safety Concerns
General Considerations:
As was the case in Cycle 4, the FUSE project is accepting a limited number of targets exceeding the nominal bright limit in cycle 5. These targets require special observing techniques and a significant amount of effort on part of the FUSE personnel. The targets have been explicitly proposed as over-bright targets at the Phase 1 stage and have been vetted by NASA via the selection process. GIs whose accepted proposals include such over-bright objects should read section 3.4 for a more detailed discussion.
For all other targets that were accepted in Cycle 5, the nominal bright limit is still in place and precautions must be taken to see that the limit is not inadvertently exceeded. Targets not already accepted explicitly as over-bright targets cannot be so designated at this stage.
The Phase 2 submission includes flux and signal-to-noise information for each target as well as an estimated total count rate. This information will be used by FUSE mission planners to verify that the user's expectations are reasonable and consistent with the expected capabilities of the instrument. However, we must ALL remain aware of brightness and safety-related issues as well. FUSE has a stated "Brightness limit" of 1.0 E-10 ergs/cm^2-s-Å for continuum sources at ANY WAVELENGTH within the FUSE bandpass. An equivalent limit for emission lines corresponds to 3.3 E-12 ergs/cm^2-s per 0.033 Å resolution element and scales linearly with line width. (See FUSE Observer's Guide for details.) Because of uncertainties in the flux levels of many targets in the FUSE range, extrapolated fluxes, especially with uncertain extinction curves or from far outside the FUSE wavelength range can be substantially in error. Thus, we must be cautious with any objects that are even within a factor of a few of the stated bright limits.
It is extremely important that you provide the most accurate information possible on source fluxes and an estimate of the TOTAL expected source count rate for each of your targets, especially for reasonably bright targets. This should be done using the FUSE spectral simulator or the Exposure Time Calculator on the FUSE Web page. It will give you (and us!) an idea of the expected target brightness, and will also be important in setting the instrument mode, the acquisition mode, and in estimating the memory usage required to support each observation. (The onboard memory for science data is limited and can easily be filled up, especially during long ground station blackout periods. Hence, memory must be managed as a resource.)
Toward that end, let us clarify as much as possible the meaning of the "flux_accuracy" keyword in Phase 2.
Typically this means that only fluxes based on earlier UV measurements (for example using FUSE, ORFEUS, HUT, IUE) at wavelengths less than about 1190 Å should use the HIGH flag. Fluxes based on optical data should almost always be listed as LOW.
In all cases, your "Feasibility" text block should also describe your flux estimates or extrapolations in sufficient detail that we can understand exactly what you have done. (This is particularly important for any targets at or near the brightness limit.) For example, just saying, "I used the on-line simulator" does not say whether the blackbody mode or a stellar model was used and/or how far you had to extrapolate, making it difficult for us to reproduce or understand your results.
Emission-line objects are a special case because they do not cause TOTAL flux or count-rate problems, but rather cause potentially dangerous levels over localized regions on the detector. While we can flag certain target classes for special inspection, YOU know your targets better than we do! We request for emission-line objects that you specify the flux-related keywords (including line width) for the brightest emission-line expected, whether or not it is the line of specific interest to your science program. FUSE mission planners can then assess the situation directly. Again, this is most important for bright objects that approach the stated bright limits within a factor of a few.
We expect that you, the GIs, will be our first line of defense against any overly-bright objects. Use the text blocks to describe any uncertainties for targets in your program. Specify keywords correctly, and provide the best flux estimates or extrapolations and count rates possible. Specify the SAFTSNP special requirement when necessary (see below). After review of your program, FUSE mission planning reserves the right to invoke SAFTSNP on any targets for which conditions are judged to be potentially dangerous to the instrument.
Proper Use of SAFTSNP:
The SAFTSNP ("Safety SNAP") special requirement, described below in section 3.8, will be implemented in any case where the combination of estimated fluxes and their uncertainties drive us to be concerned about instrument safety. SAFTSNPs are inefficient, both for you (since they "cost" 2 ks each even though the exposure times may be very short) and for us (orbit inefficiency plus the implementation overhead of having to set and release HOLDs on targets, etc.) Our goal is to minimize the use of SAFTSNPs while still remaining comfortable about the safety issues involved. Also, since SAFTSNPs affect the "accounting" of time in a program, it is painful when we have to "add" SAFTSNPs after you have submitted your Phase 2, because it's a zero-sum game and so something else needs to get shortened or dropped! Hence, we need to get SAFTSNPs on all those targets for which they are required right up front in your Phase 2 submissions. This requires that you pay attention to the following strategy for when SAFTSNPs are needed:
Please note that the SAFTSNP special requirement is applied at the "observation" level. Hence, the proper usage is to specify BOTH a SAFTSNP observation AND a "science" observation of each target that needs a SAFTSNP. SAFTSNPs get accounted at 2 ksec each, but you should simply leave the exposure time blank because a default value will be inserted by FUSE mission planners at a later time. The followup science observation should be placed on hold using the HOLD special requirement. (See below.)
PLEASE FOLLOW THESE RULES FOR YOUR PHASE 2 SUBMISSIONS to ensure proper program accounting!!! All specified observations, including any SAFTSNPs at 2 ksec each, have to total less than or equal to your program's allocation.
3.4 Targets Brighter than the Nominal Bright Limit
Starting in Cycle 4, the FUSE project put in place several procedures that allow the observations of targets brighter than the nominal bright limit, without it posing a danger to the detectors. The basic idea is to tweak the optical path through the instrument so that the count rate from the detector is lowered. There are four basic schemes that are likely to be attempted.
3.5 Instrument Mode Selections
The two data-taking modes of the instrument are time-tag mode (TTAG) and histogram mode (HIST). See the FUSE Observer's Guide for more details. FUSE mission planning will normally select the instrument mode based on the expected count rate from each target and other considerations (e.g. on-board memory usage, required resolution, etc.). Up to a count rate of 2500 cts/s TTAG mode will normally be used, and for higher rates, HIST mode will be the normal mode. Since TTAG mode data can be better corrected for image and spectral motions, we take as much data as reasonable in this mode. However, onboard memory usage and downlink opportunities must be carefully planned to make this work smoothly.
There is some gray area in this count rate limit. For a 2500-3500 cts/s object we can (in principle) observe in TTAG mode if scheduled when appropriate memory and downlink are available, but it will require careful coordination and planning (and possibly extra ground station passes). As such, THIS CAPABILITY IS A RESOURCE, and may affect the schedulability of your observations. In this gray area, the user is allowed to SUGGEST TTAG instrument mode if it is important to the science requirements of the program. Text description in the Feasibility section should provide justification. Accurate fluxes are needed for such objects, since even small uncertainties in flux will have large impacts on data rates in this count rate regime.
3.6 Spectral Resolution Considerations
Maintaining the highest spectral resolution would be one reason for requesting TTAG mode even on a moderately bright object. Data obtained in TTAG mode can be post-processed to remove effects of spectral or image motions and maintain the highest possible spectral resolution.
If HIST mode is chosen, you should realize that some amount of Doppler smearing is unavoidable unless the target is very near the orbit pole. However, the degradation for HIST exposures will not be severe. We will minimize these effects (<5 km/s smearing) by scheduling a "4-pack" of HIST exposures per typical viewing period. The "default" mode for HIST exposures, which is set to keep the data sets at a manageable size, will involve 1x8 binning (resulting in 4.8 MB of memory usage for each HIST exposure). This binning, in conjunction with a worst case Doppler smearing of 5 km/s, has a negligible effect on the obtained spectral resolution.
Please note that the requested observing time for HIST observations should still be the "total" requested observing time on the target, NOT the expected length of individual HIST exposures! Users never specify exposure-level information in the Phase 2 forms, only observation-level information. Mission planning scheduling software will implement observing at the exposure level.
3.7 S/N and Fixed-pattern Noise Considerations
Laboratory and on-orbit testing of the FUSE flight detectors have indicated that there is considerable variation of the fixed-pattern noise (FPN) in different parts of the FUSE detectors. For the vast majority of FUSE observations, this makes very little difference; many targets have observed fluxes that, in reasonable integration times, will not support observations at or above a S/N ratio of 25 or 30 per resolution element. However, for the brightest targets allowed for observation by FUSE, there is a range of parameter space where photon statistics could provide higher S/N ratios if not for the FPN.
Limited experiments with a technique involving moving the focal plane arrays and offsetting the target within the LWRS aperture have demonstrated that higher S/N ratios are achievable on bright targets. While we refer to this technique as "Focal Plane Splits", it does not correspond to the formal FP split procedure users may be aware of from other instruments such as HST/GHRS. Rather, it really amounts to obtaining data with the image of a given wavelength projected onto differing parts of a detector, effectively smearing out the FPN. In the demonstration cases, we obtained several spectra having S/N ratios in the 50-100 per pixel range, albeit with extra integration time and special non-standard scheduling efforts.
Starting with Cycle 3 we have added the FPSPLIT special requirement, to indicate those observations for which this technique should be employed. Note that for FPSPLITs to make sense, the time allocation for the total observation has to be sufficient that the S/N achieved in each setting approaches the maximum achievable without the FPSPLIT procedure. In general, only those observations which proposed for and were awarded the required time allocation for this observing technique, in the phase 1 process, should apply this SR. Any new FPSPLIT requests should be approved by the project scientist, Dr. George Sonneborn.
3.8 Special Requirements
Special requirements are less complicated and less extensive than those needed for HST, but serve much the same function: they flag the planning system to some relatively infrequent but supported mode or operation that requires special attention by planners. Invoking SRs often constrains the time at which the observations can be scheduled. As such, most of these should only be specified when required by the science. In some instances, SRs are primarily informational and provide more of a "heads-up" rather than having a functional role. Also, in some instances more than one SR may apply; all appropriate SRs should be listed, separated by commas. However, in a few instances, use of multiple SRs are illegal or at least conflicting. These are all described below.
Information on SRs is requested at an `object' and `observation' level in the Phase 2 submission. A separate general text block is also encouraged to discuss any such requirements of the program.
Object-specific Special Requirements (SRs) pertain to all observations of a given target and are defined with the following options on the `object_spec_req' keyword: TOO or MOVE. The meaning of each of these is:
Observation-specific SRs apply to specific pointings to an object and are defined with the following options on the `obs_spec_req' keyword: SNAP, SAFTSNP, HOLD, ROLL, MON, EPHEM, SPATIAL, CONTIG, CVZ, COORD, FESIMG and FPSPLIT. The meaning of each of these is:
3.9 Target Acquisitions and Offset Targets
Target acquisition is the most complicated part of FUSE autonomous operations, and has an obvious and important impact on the quality and quantity of science returned. Issues involved in FUSE target acquisitions are discussed in detail in section 3.4 of the FUSE Observer's Guide. Here we concentrate on those issues that potentially affect your Phase 2 submission. These issues boil down to answering the following two questions for each of your targets:
The bottom line is that if your targets can be observed through the Lwrs aperture, and if the coordinates are accurate in the HST Guide Star Catalog frame of reference, you have no acquisition problems!
For LWRS observations, the only exceptions to this are a) visually very bright targets, V < 2.5 or so (depending on surrounding guide star field), or b) visually faint targets with poor guide star fields. For targets in category (a), the situation may require us to find a nearby field excluding the bright source to use as an offset field: we will acquire the offset field and then blind offset the bright target into the LWRS aperture. For category (b) targets, it is the assumed marginal quality of the star field surrounding the target that drives us to use an offset field, NOT the faintness of the target! In either of these cases, the situation will be assessed by FUSE mission planners and an offset field (if needed) will be chosen by us.
The situation with MDRS and or HIRS acquisitions is more complicated. Targets with sufficient FUV flux to generate at least 100 cts/s/channel can be acquired with an FUV peak-up in the appropriate aperture. This aligns the channels and centers the target, at least temporarily. The problem is that the relative pointing of the four telescope channels drifts by 4 - 8 arcsec on an orbital timescale, with the SiC channels drifting the most. Typically, the MDRS channels remain roughly aligned for about 10 minutes. (For HIRS, the time is even shorter.) Hence, for MDRS observations requiring both LiF and SiC coverage, a sequence of peak-ups must be scheduled to realign the channels. This is a cumbersome and inefficient process, and we only follow this procedure when driven by specific science goals. Thus, if you are requesting observations with MDRS or HIRS, you should state very clearly how important coverage by the SiC channels is to your scientific investigation.
If a target is too faint for a peak-up but requires MDRS or HIRS, we cannot guarantee coverage by any channel other than LiF1 (the FES guide channel). In certain cases, it may be beneficial to align using a nearby offset star with sufficient FUV flux for a peak-up, but the timescale for misalignment is so short that there are few cases where this strategy applies.
FUV Offset Target Specification
If you determine that one or more of your targets requires an offset star for acquisition, it must be specified in your Phase 2 submission. Offset targets should be named as the primary target (or one of the primary targets if the same offset star is used for multiple target positions) but should end with "-OFF" and be given a priority of "4". This identifies them as targets for which no FUV science exposure will be requested. (You should provide the "real" name(s) of any offset stars in the additional information text block (for cross checking purposes). Coordinates in the same reference frame as your science target and flux and V magnitude information should be provided. (Note: flux information is particularly crucial if the star is needed for PEAK-UP!) Offset stars should be as close as feasible to the primary target, but as a worst case within two degrees. Exposure times and other ancillary information is not required for offset stars. Offset targets are connected to a particular science target with the off_object_num keyword in the observation listing.
3.10 Coordinates and Proper Motion Corrections
It is the GI's responsibility to provide the J2000 target co-ordinates in the Phase 2 form. Co-ordinates should be corrected from the epoch of whatever plate material or catalog originally used to J2000. Usually absolute coordinates good to about ± 2 arcsec should be sufficient for FUSE. In several cases the accuracy required may be higher, and dependent on the aperture and type of acquisition. For objects that will be visible in the FES, the "FES Acq" mode should be fairly forgiving; it will effectively remove coordinate uncertainties relative to the guide star frame of reference even at the several arcsec level, so long as the field around the target is not crowded or complex. For the "Guide star acq" mode, it is most important is to have an accurate RELATIVE target position in the guide star reference frame. Since we utilize the HST Guide Star Catalog to choose FUSE guide stars, this catalog is a good default source for your coordinates when possible. In general, SIMBAD coordinates can be uncertain and/or inconsistent with the HST GSC, and should be used with great caution. We have had a number of failed observations in Cycles 1 & 2 due to the blind use of SIMBAD coordinates by users.
It is also the GI's responsibility to check their objects for significant proper motion, and if necessary correct the coordinate to the current equinox (i.e., roughly the mid-point of the expected cycle of observing). Since acquisitions should be robust for coordinate differences of ~ 2 arcsec, only proper motion corrections larger than 1.5 arcsec need to be incorporated. Objects for which significant PM corrections have been applied to the listed coordinates should be brought to the attention of mission planners in the support_info_text section described below AND by setting the high_prop_motion flag to Y after correcting the supplied coordinate. (This flag is to permit mission planning personnel to easily identify those targets with proper motion corrections, which may be of importance during field verification and guide star work.)
Finally, any target acquisition failures due to inaccurate target coordinates will result in the program being charged for the lost observing time.
4. FUSE Phase 2 Proposal Keyword Definitions
In this section, we step through the Phase 2 form and describe the expected or allowed entries for each of the keywords or text sections. Please note that you can bury comments anywhere within the form by preceding them with a "#" sign. However, any such comments will be for your use only; these comments will not be processed by the FUSE planning software or read by FUSE mission planners. (Only the standard text blocks will be read.) Example forms showing proper syntax are provided in Appendix A.
4.1 Contact information and text blocks:
prog_id: (Required) title: (Required) t_alloc_total: (in ksec, Required) t_alloc_orb: (in orbits, Required only for French Team Programs) t_legacy_yrs: # Years t_year_one: # Ksec t_year_two: # KsecThis information will be filled in or provided to you. Program IDs (these are the four character codes returned by the proposal submission e-mail account. For cycle 5 they begin with the letter "E") were assigned to proposals by the proposal system upon original submission. Note that for planning and tracking purposes, Legacy programs have been reassigned program IDs in the 500 range while Survey programs have been reassigned program IDs in the 900 range. This ID permits tracking of targets and program status throughout the planning and implementation phases. The program's title should be the same as used in Phase 1 (except for removal of LaTeX formatting characters), and will be used in tracking and report generation. t_alloc_total is the total on-target time for the program in ksec, while for French Team programs, the t_alloc_orb keyword is provided and is the official allotment. (Note: French "orbit" allotments include acquisitions.) For legacy programs the nominal duration is indicated by the t_legacy_yrs keyword and the allocations by the t_year_one and (where applicable) t_year_two keywords.
pi_title: (All required) pi_first_name: pi_last_name: pi_affiliation: pi_institution: pi_address: pi_country: pi_phone: pi_fax: pi_email:PI contact information. These entries provide contact information for the Phase 1 principal investigator, who is tasked with being in charge of the specified FUSE science program. This person is assumed to be the primary point of contact for any questions about the program, UNLESS the "Lead Investigator" fields below are filled out. Information from Phase 1 will be carried forward. The name is the only field that should not be changed or updated. Please ensure something is entered in all of these fields, including pi_title. (The parser software needs this to determine a new record, so please enter a title here - Dr., Mr., Ms., Lord, Count, Sir etc.)
li_title: (All required IF there is a lead investigator.) li_first_name: li_last_name: li_affiliation: li_institution: li_address: li_country: li_phone: li_fax: li_email:Lead Investigator (LI) information. At the discretion of the principal investigator of the program, one of the co-investigators included in the Phase 1 proposal may be designated the lead investigator. Only fill in these fields if someone other than the listed program PI will be the primary point of contact for technical questions about the proposal. LI listings should NOT be duplicated again under Co-I listings below; LIs are understood to be Co-Is.
coi_title: (All required for any Co-Is; duplicate and repeat as needed coi_first_name: for each Co-I.) coi_last_name: coi_institution: coi_country: coi_phone: coi_email:Co-I information. (Note: less information is requested for Co-Is.)
abstract_text: (Required)Enter a 200-word (or less) abstract for the program. This flat ASCII text should provide a descriptive overview, and will be made available on-line in the data archive. The Phase 1 proposal abstract should be carried forward, modified (if necessary), and LaTeX commands removed.
feasibility_text: (Required)A description of program feasibility and check of safety-related issues is required with each Phase 2 program. This should include discussion of the quality of the flux estimates, and the method used to calculate count rates, signal-to-noise, and program feasibility. Use of the FUSE simulators and/or the on-line Exposure Time Calculator are STRONGLY encouraged. FUSE mission planners will perform an independent feasibility analysis of all programs using this information and the data provided for each object below. Most users may choose to cut and paste text from a similar section that appeared in Phase 1 proposals as a starting point. Again, please verify and/or revise information carried forward and remove LaTeX commands in this process.
spec_req_text: (Optional, as needed)Information on special requirements is requested at both `object' and `observation' levels below. Here we encourage GIs to discuss any such special requirements to help the FUSE personnel understand the importance and motivation for specifying the requirements. Recall that several Special Requirements are available in Phase 2 that were not part of Phase 1. Please review any Phase 1 specifications carefully and confirm appropriateness. Again, DO NOT specify these frivolously, since many can seriously constrain when a given object or observation can be scheduled. Refer to section 3.8 above for a discussion of these SRs.
If you have any observations that have to be made using the MDRS (4"x20") aperture and definitely require SiC channel coverage (i.e. coverage of 905-1000 Å wavelength region) please mention it in this section. Because of channel drift, the target will in general move in and out of the MDRS aperture in the SiC channels. Therefore special alignment procedures are implemented to ensure SiC coverage for the entire exposure. An explicit statement that SiC coverage is needed will alert the mission planners early and help maintain efficiency.
support_info_text: (Optional, as needed)This is a text block where the proposer can convey any information that is helpful or important for the planning and successful execution of the program, but which cannot be communicated readily via the keywords or in other text blocks. Special observing strategies or requests to use extended satellite capabilities (should they become available) may be included in this section. Below is a representative (but not comprehensive) list of support information issues:
4.2 Object-specific Information: (repeat keywords as needed, for each object; unused "optional" keywords can be dropped or left blank.)
object_number: (Required)This should be a one or two-digit integer with or without leading zeroes (e.g. 1, 01, etc.) that is unique for each target in your program, including any offset stars. This should be the first keyword listed for each new object. If your program requires more than 99 objects, you're special. Contact FUSE mission planners.
object_name: (Required)Object naming conventions and syntax should follow those used in Phase 1, which were originally developed at STScI for use in HST proposals. (Details were provided in Appendix A of the Phase 1 proposal instructions.) Since checks are run against approved Phase 1 targets for each program, you should NOT arbitrarily change target names between Phase 1 and Phase 2.
Offset targets, if needed, should be identified by "Object_name"-OFF, where "Object_name" refers to the primary object (or a primary object) of interest. You should supply the "real" target name of any offset stars in the Supporting Information text block. Offset targets should only be needed in specialized cases, where the primary target is too bright (visually) for guide star acquisition, or where a faint or extended target is being observed in MDRS or HIRS and a direct "peak-up" acquisition in untenable. (See section 3.9 on Target Acquisitions.) Offset targets should be reasonably bright FUV sources if a peak-up and/or channel alignment is to be performed. Other than flux and V magnitude information and an accurate RELATIVE coordinate with respect to your primary source position, no other data are required for offset stars. Offset stars should be specified with a priority of "4".
object_class: (Required)We will use a slightly modified version of the two-digit numerical IUE Object classification scheme, given in Appendix B. This code number provides a rough idea of object type to mission planners, and will follow the observation into the archive for future reference.
object_spec_req: (Optional)Specify any object-specific special requirements (SRs) that apply: MOVE, TOO. (Meanings are described in section 3.8.)
ra_j2000: (Required, unless target is a moving target or dec_j2000: TOO of unknown position.)Coordinates in standard astronomical format (HH:MM:SS.SS and [+/-]DD:MM:SS.S with colons as shown), referenced to the J2000 equinox, are required. If your target is bright enough to be listed in the HST Guide Star Catalog, this coordinate is preferable since it will already be in the proper frame of reference (i.e., relative to nearby guide stars) for use by FUSE. This is sufficient for LWRS aperture observations. If MDRS or HIRS apertures are to be used, and if the target is bright enough at UV wavelengths to permit a PEAK-UP acquisition to work, coordinates accurate to about 2 arcsec or better will be sufficient. If target position is unknown at this time, enter all "9's". Target acq failures due to inaccurate coordinates will result in your program being charged for the lost observing time.
The next set of keywords define the user-supplied flux and source type information necessary for checking observation safety and feasibility and verifying the user's expectations.
source_type: (Required) PC, PE, EC, EEA two-letter abbreviation is entered, indicating first whether the source is point-like (P) or extended (E), and secondly whether it is primarily a continuum (C) or emission-line (E) source. In cases with both continuum and emission lines, the user should choose the one more important to the science program. This flag affects the detailed meaning of some of the entries given below (for instance, the units for flux) and should be consistent with the other data entered.
Also for combination sources, FUSE mission planners need to know of any special situations that might cause safety or count rate concerns. For instance, if you were interested in the continuum level of a symbiotic star, but strong emission lines are also expected, you would specify "PC" here, and give the appropriate fluxes, etc., below. However, the feasibility text block above should discuss the expected peak line intensities and verify that they are below stated safety limits for the detector. (See the FUSE Observer's Guide and discussion above for information about bright limits.)
lambda_ref: (Required)A reference wavelength in Angstroms should be entered. This should be a wavelength between 905 and 1190 Å (i.e. within the FUSE range). This is the wavelength for which the flux below pertains and for which the S/N has been calculated. As such, it should generally be a wavelength of interest to your science program. (However, see comments in section 3.3 for emission line sources.)
flux_lambda_ref: (Required)The user should enter a "flux" value, in n.nnE-nn format (n=0-9) corresponding to the above reference wavelength. (NO LaTeX, and NO SPACES!) The expected units are ergs/cm^2-s-Å for continuum sources, and integrated flux (ergs/cm^2-s) for emission line sources. For objects brighter than the nominal bright limit enter the intrinsic source flux corrected only for interstellar reddening. Do not make any further corrections based on the technique used for observing the source (see section 3.4 for details).
eline_fwhm: (Required for source_type = PE and EE)Only needed if source type involves emission lines. Approximate FWHM of line in Angstroms should be entered. The expected FWHM of emission lines is an important parameter in safety considerations. Discuss any assumptions or uncertainties in this parameter in the Feasibility text block.
sb_lambda_ref: (Required for EC and EE)Expected surface brightness (flux per square arcsec) in n.nnE-nn format; only needed if source type involves an extended source. This number should be the above expected flux (or integrated line flux) divided by the number of square arcsec of emission expected through the chosen aperture.
flux_950: (Required for continuum sources) flux_1050: flux_1150:These keywords list representative continuum fluxes expected at three reference wavelengths in the FUSE range, to be used both for safety checking, count rate estimates, and calculation of `peak-up' acquisition times when necessary. The values entered should be in exponential format (n.nnE-nn) in units of ergs/cm^2-s-Å. As mentioned above, for bright objects requiring special observing procedures, enter the intrinsic flux of the source, corrected only for interstellar reddening (see section 3.4 details).
flux_accuracy: (Required) HIGH, MED, LOWThis keyword is used to indicate the accuracy level of the flux information provided above. (This is important for safety checks, acquisition time calculations, and estimating spacecraft memory usage.) As a general guideline, HIGH should be reserved for an actual observed value in the FUSE range (say 1190 Å or below, from IUE, HUT, ORFEUS, or HST) or a small extrapolation from <1300 Å that is expected to be accurate at the 30% or better level. (See details above in section 3.3.)
v_mag: (Required for all sources)Johnson V magnitude or equivalent. This is used for assessing target acquisition issues and flagging potential FES-related issues. This information will also be carried into the archive with the data. If a V magnitude is not applicable to your target enter 99.
v_range: (Optional)Used only for indicating the extent to which the object may be variable in the visual band, and for flagging potential FES issues. When entered, this should be a V magnitude range, separated by a hyphen and without spaces (e.g., 10.1-14.5).
resolution_element: (Required)This field should indicate the size of the assumed resolution element over which the quoted signal-to-noise ratio below has been calculated, in Å.
expected_ct_rate: (Required, and very important)For each object, the user should provide an estimate of the expected total source count rate (cts/sec), preferably based on a FUSE simulation or Exposure Time Calculator/Count Rate Tool output. This is needed as accurately as possible, and will ultimately drive the selected observing mode (TTAG or HIST) and onboard memory requirements of the observation. The FUSE detectors support count rates up to 32,000 cts/s; higher count rates lead to loss of data.
sig_noise_chan: (Required)This specifies whether the signal-to-noise calculation (below) was performed assuming all channels (TOTAL) or a specific channel (LIF1, LIF2, SIC1, or SIC2). Only a single entry is allowed.
sig_noise: (Required)This should be the expected signal-to-noise per specified resolution element at the reference wavelength given above, and for the channel assumption provided in the sig_noise_chan keyword (above). (Note that for full resolution, S/N=30 is the highest value we expect to be able to support without special procedures.)
spectral_type: (Optional) Provide MK spectral class and luminosity class for all stellar classes (NO SPACES). color_excess: (Optional) Measured E(B-V), if available. red_shift: (Optional) Either standard format, or in km/s; value will be obvious either way.The three items above should be provided when available or appropriate. This information is not used directly for mission planning, but allows us to make consistency checks on the supplied data. Also, this information will accompany the observational data into the archive.
high_prop_motion: (Optional)Leave blank or "N" if no correction, or set to "Y" if a proper motion correction has been applied to the submitted coordinate. If "Y", describe corrections in the supporting information text block. See notes in section 3.10 above for more information.
object_prio: (Required)See notes in section 3.2 (above) on target priorities. Legal values are 1 or 2 (1=high). Designate roughly half of your observing time in each of priority 1 and 2. These priorities are for use within individual programs and are not intended to indicate relative target priorities across different programs. Targets to be used for ancillary purposes (for instance, an OFFSET star, for which an actual FUV observation is not desired) should be specified with priority 4.
The last two object entries deal only with "ephemeris" targets for which the EPHEM SR will be invoked below:
phase_zero: (Optional unless EPHEM used in `obs_spec_req'.) phase_period:The phase_zero keyword provides the Julian day (note: NOT Modified Julian day) of the assumed zero point in the periodic phenomenon of interest. Only the day number ABOVE 2,400,000 SHOULD BE PROVIDED, and no commas should be entered. (For instance, June 1, 1997, was JD2,450,600.5, and would be specified "50600.5" [no quotes].) The phase_period keyword should provide the period of the variation in decimal days, to whatever accuracy is required.
4.3 Observation-specific information: (repeat observation blocks as needed, for each observation of each target; unused "optional" keywords can be dropped or left blank.)
observation_num: (Required; must be first keyword listed in this section for each observation.)An increasing integer, used for specifying separate observations of a target. Ranges from 1-99, and leading zeroes are optional. For software reasons, this should be the FIRST keyword listed for each new observation. If MON, a range is allowed for this field, viz. "1 to 20" (see Appendix A for an example). If your program requires more than 99 observations, you're special. Contact FUSE mission planners. PLEASE NOTE that this number stars at "1" for each new OBJECT being observed!
obs_object_num: (Required)This keyword mirrors the `object_number' from the target listing above, and identifies the object for which this observation is being specified.
off_object_num: (Optional)Enter the `object_number' of any specified offset target needed to acquire your science target.
instrument_mode: (Optional) TTAG, HISTFUSE mission planners will apply rules to decide whether each observation should be performed in TTAG or HIST mode. If it matters to your science, you have the option here of telling us which mode you want or think is appropriate for your observation. Differences will be tracked and resolved as needed. If you specifically request TTAG for objects with expected count rates greater than 2500 cts/s, discuss it in the Feasibility text section.
aperture_req: (Required)Enter the four-letter abbreviation for the desired FUSE aperture for the observation. The options are:
obs_time_req: (Required)Enter the total integration time desired for the observation, in units of seconds. This does not include acquisition, but is the real desired integration time on target, and should correspond to the observing time needed to produce the quoted S/N ratio above. If the MON keyword is set above, however, this should be the length of an individual monitoring observation. As necessary, this observation time may get broken into smaller "exposures" that will total this time when summed together. (Exposure-level planning is performed by the scheduling tool.)
obs_spec_req: (Optional, as needed)Supported observation-specific SRs for Cycle 5 are ROLL, MON, HOLD, EPHEM, SNAP, SAFTSNP, SPATIAL, CONTIG, CVZ, COORD, FESIMG and FPSPLIT. (Meanings are described above in section 3.8.)
A couple of these SRs will spawn secondary keywords that are required only when the primary keyword is present. These include:
For ROLL SR:
aperture_pa: The desired Position Angle (east from north) for the long dimension of the FUSE apertures, in degrees. This angle will be assumed to be modulo 180 degrees unless called out otherwise in the Special Requirements text block. pa_tolerance: The allowed half angle or "tolerance" on the above position angle, to permit scheduling flexibility (i.e., allowed ROLL angles are: aperture_pa +/- pa_tolerance).For MON SR:
MON indicates a target for which a repeated observation (or monitoring program) is desired. In this case, the user must specify a "mon_t_sep" keyword, which is the nominal separation of the observations in decimal days, and a "mon_delta_tsep" keyword (also in days) indicating the amount of leeway allowed in the separation. In this case, the "obs_time_req" keyword (given below) pertains to an individual observation. (Thus all MON observations are assumed to be the same length.) Remember: MON and EPHEM are mutually exclusive.
mon_t_sep: nominal separation of individual observations, in decimal days. mon_delta_tsep: tolerance permitted on nominal separation, also in decimal days.
For EPHEM SR:
EPHEM indicates a target for which a specific ephemeris constraint applies to the observation (such as a binary star or cataclysmic variable phase). Such observations need to be scheduled at certain specific UTs (or at least within some range of UT). The EPHEM special requirement spawns the additional keywords "phase_zero" and "phase_period" (discussed above under object-specific keywords) and:
phase_desired: The midpoint of the desired phase to observe. phase_delta: Specifies phase coverage relative to the "phase_desired".
The phase_desired keyword should be a number between 0.0 and 1.0, and phase_delta will be assumed to indicate a desired plus or minus in phase space. For example, if phase_desired is 0.5 and phase_delta is 0.1, then we will assume you are after an observation covering phase 0.4 - 0.6. Description should also be provided in the Special Requirements text. Remember: MON and EPHEM are mutually exclusive.
For FESIMG SR:
The user can specify whether a reference FES image should be obtained with the object in the aperture, or with the object bumped out of the aperture (i.e. actually visible in the FES image). The user can no longer specify a filter request since the FES is used in CLEAR mode by default. The relevant keyword is:
targ_pos: Legal values are IN or OUT, specifying the target position relative to the aperture. (Default will be "IN.")
A Final Word About Filling Out Phase 2 Forms:
Each specified "observation" is tied to an "object" via the obs_object_num keyword, as described above. This provides the user with the option to organize the Phase 2 submission in one of two ways:
Organize your submission whichever way makes the most sense for your program; the Parser will not care! Remember, however, that the observation section for each new object should start with observation_num: 1.
5. Phase 2 Template File Checking and Submission
To assist you in the proper generation of your Phase 2 submissions, two electronic submission accounts at JHU are available.
p2test@pha.jhu.edu -- error checking and formatting. p2submit@pha.jhu.edu -- final submission.
The "p2test" account has been set up to help you debug many syntax or other errors that may exist in your draft Phase 2 files. An electronic proposal submission to this account will be acknowledged by e-mail. PLEASE INCLUDE YOUR PROGRAM ID NUMBER IN THE SUBJECT LINE OF E-MAIL TO THIS ACCOUNT, which will ensure proper tracking of your Phase 2 inputs on our end. You will receive a return e-mail containing a "Parser log" and a "formatted" ASCII version of your proposal for your reference.
The formatted proposal is to allow you to more readily perform sanity checks on the entered data and text. Text blocks will be shown in ASCII format at the beginning, but more importantly your keyword entries from the Phase 2 template will be shown in landscape mode tabular format for each target, making it easier to check whether the observation specifications have been entered correctly.
Please note that the exact format will depend somewhat on your particular keyword entries, and that FOR DISPLAY PURPOSES SOME OF THE FIELDS MAY BE TRUNCATED from what you entered in the Phase 2 template! (This is only done for printing purposes, and does NOT affect your actual Phase 2 entries.) Please note: THIS FORMATTED OUTPUT IS FOR YOUR REFERENCE ONLY! DO NOT EDIT CHANGES INTO THE FORMATTED FILE, and DO NOT SUBMIT THE FORMATTED FILE TO US!! The keyword-driven Phase 2 template file is the only file we can use for FUSE mission planning purposes.
The Parser Log will contains FYI messages, Notes, Warnings, and Errors found by our software and attempts to provide sufficient explanatory information for debugging the perceived problem(s). In addition to syntax errors, any missing keywords (including secondary or linked keywords for optional parameters), out-of-range fluxes, objects requiring SAFTSNPs (but not specified), etc., will be flagged and reported. You should look carefully at any Notes or Warnings, and correct any Errors prior to official submission of your program. Appendix D lists typical Parser messages with further explanations.
If you have questions, review the materials presented here first, and then contact us. DO NOT SEND QUESTIONS TO THE PHASE 2 SUBMISSION ACCOUNTS!! Your primary interface for questions should be the `fuse_support@pha.jhu.edu' e-mail help account at JHU. This account will be monitored during normal business hours by a member of the FUSE User Support Group who will get back to you as soon as possible. The primary contacts for Guest Investigators are: Drs. B-G Andersson and Ravi Sankrit (e-mail: bg@pha.jhu.edu, ravi@pha.jhu.edu). Please include your program ID number in the subject line of all e-mail sent to the fuse_support e-mail account.
When your Phase 2 file is error free (from the standpoint of the Parser anyway) and IS COMPLETE, you should make your official submission to the "p2submit" account listed above, again INCLUDING YOUR PROGRAM ID IN THE SUBJECT LINE of the submission message. This submission will be acknowledged electronically and a clean formatted output will be e-mailed back to the address used for the submission.
From a program accounting standpoint, it is highly desirable for us to receive complete Phase 2 submissions, with all expected targets represented and at or below your program's allocation. If you foresee the need to submit a partial program, you must contact us specifically with an explanation.
Deadline and schedule information will be provided separately from this document. A checklist for your Phase 2 submission is provided in Appendix C below.
Appendix A. Example FUSE Phase 2 Template Forms
NOTE: This form is an actual Cycle 5 Phase 2 template. It has been reproduced here with the permission of the PI of the program.
#
#
# #########################################
# ## ##
# ## FUSE Phase 2 Proposal Template ##
# ## ##
# ## for use in Cycle 5, 4/01/2003 ##
# ## ##
# #########################################
#
# Refer to FUSE Cycle 5 Phase 2 Instructions for complete details.
#
# Proposal Identification
# This Proposal is a STANDARD program
prog_id: D049
title: Detailed FUSE Study of a Star Behind the Cygnus Loop
t_alloc_total: 46 # Ksec
t_alloc_orb: # Orbits, for French programs only.
# ######################
# ## ##
# ## PI Information ##
# ## ##
# ######################
pi_title: Prof.
pi_first_name: William
pi_last_name: Blair
pi_affiliation: Dept. of Physics and Astronomy
pi_institution: Johns Hopkins University
pi_address: 3400 N. Charles St., Baltimore, MD 21218
pi_country: USA
pi_phone: 410-516-8447
pi_fax: 410-516-8260
pi_email: wpb@pha.jhu.edu
# ######################
# ## ##
# ## LI Information ##
# ## ##
# ######################
# Optional, if Program PI designates a separate primary contact person.
li_title:
li_first_name:
li_last_name:
li_affiliation:
li_institution:
li_address:
li_country:
li_phone:
li_fax:
li_email:
# ########################
# ## ##
# ## Co-I Information ##
# ## ##
# ########################
# COI - 1, repeat if necessary for other Co-Is.
coi_title: Dr.
coi_first_name: Ravi
coi_last_name: Sankrit
coi_institution: Johns Hopkins University
coi_country: USA
coi_phone: 410-516-3340
coi_email: ravi@pha.jhu.edu
# ########################
# ## ##
# ## Co-I Information ##
# ## ##
# ########################
# COI - 2, repeat if necessary for other Co-Is.
coi_title: Dr.
coi_first_name: Pierre
coi_last_name: Chayer
coi_institution: Johns Hopkins University
coi_country: USA
coi_phone: 410-516-8252
coi_email: chayer@pha.jhu.edu
# ########################
# ## ##
# ## Co-I Information ##
# ## ##
# ########################
# COI - 3, repeat if necessary for other Co-Is.
coi_title: Mr.
coi_first_name: Charles
coi_last_name: Danforth
coi_institution: Johns Hopkins University
coi_country: USA
coi_phone: 410-338-8034
coi_email: danforth@pha.jhu.edu
# ########################
# ## ##
# ## Co-I Information ##
# ## ##
# ########################
# COI - 4, repeat if necessary for other Co-Is.
coi_title: Dr.
coi_first_name: John C.
coi_last_name: Raymond
coi_institution: Smithsonian Astrophysical Observatory
coi_country: USA
coi_phone: 617-495-7416
coi_email: raymond@cfa.harvard.edu
# ############################
# ## ##
# ## Proposal Information ##
# ## ##
# ############################
#
# NOTE: Although not required, keeping text block lines to 80 characters
# or less will prevent line wraps and improve readability in the
# formatted output.
# -------------
# | Abstract |
# -------------
abstract_text:
# ENTER ABSTRACT TEXT HERE.
# ----------------
# | Feasibility |
# ----------------
feasibility_text:
# ENTER FEASIBILITY AND SAFETY DISCUSSION HERE.
# ------------------
# | Special Reqs. |
# ------------------
spec_req_text:
# ENTER DISCUSSION OF SPECIAL REQUIREMENTS KEYWORDS SPECIFIED HERE.
# ------------------
# | Support Info. |
# ------------------
support_info_text:
# ENTER ANY OTHER RELEVANT SUPPORTING INFORMATION HERE.
# For targets above the nominal bright limit (1e-10 ergs-1s-1cm-2A-1),
# if you have a preferred observational technique, please discuss.
# State the wavelength coverage required. See Phase 2 Instructions.
#
# Object-specific Information
#
# Note: Keywords are on uncommented lines, terminated with a colon.
# ENTER INPUTS TO THE RIGHT OF THE COLON for each relevant keyword,
# NOT on the following line. The blank lines below are for readability
# only. Comments or example formats are listed above each item (to
# prevent line wraps in the electronic submission). After the fact,
# comment lines may be deleted if you wish.
#
# Also, you may add other comment lines at will, so long as each comment
# line begins with a pound sign and is <=80 characters in length. However,
# any such lines are for YOUR BENEFIT ONLY and are not part of your official
# submission. (Only uncommented lines are visible to the Parser and carried
# forward into the database.)
#
# Repeat the following keywords as necessary for each separate target.
# Optional keywords may be left blank or dropped entirely.
#
# ############################
# ## ##
# ## Object 1 Information ##
# ## ##
# ############################
# Object number. Use 1-99.
object_number: 1
# Object name from Phase 1 when possible. NO SPACES in target name.
object_name: KPD2055+3111
# Numerical object class from listing in Appendix B.
object_class:
# Object-level special requirement(s): MOVE and/or TOO.
object_spec_req:
# RA and Dec in J2000.
# Use format: 20:31:45.22 and +31:02:01.5 (INCLUDING the colons).
ra_j2000: 20:57:26.85
dec_j2000: 31:22:53.0
# Two-letter source type designation: PC, PE, EC, or EE.
source_type: PC
# Reference wavelength in Angstroms; e.g., 1032.0.
lambda_ref: 1030
# Reference flux in cgs units; e.g., 1.2E-12. NO SPACES.
flux_lambda_ref: 4e-13
# FWHM of emission line in Angstroms; e.g., 0.5.
# Required for PE and EE types.
eline_fwhm:
# "Flux" per sq. arcsec. Extended sources only (EE and EC).
# Example: 3.0E-15
sb_lambda_ref:
# Equiv. continuum fluxes at 950, 1050, and 1150 A; e.g., 1.2E-12.
# NOTE: For BRIGHT objects (fluxes above the nominal limit of 1e-10)
# these MUST be the INTRINSIC fluxes for the TARGET
# NO offset or defocused fluxes. See Phase 2 Instructions.
flux_950:
flux_1050:
flux_1150:
# Flux accuracy: HIGH, MED, or LOW. See Phase 2 Instructions.
flux_accuracy:
# V magnitude in magnitudes; e.g., 12.5.
# If V magnitude is not applicable to your target, enter 99.
v_mag: 14.1
# Magnitude range (variable sources only). Example: 9.9-13.2.
v_range:
# Resolution element (for S/N calc.) in Angstroms; e.g., 0.033.
resolution_element: 0.032
# Total expected cts/sec, preferably from Exposure Time Calculator,
# Count Rate Tool or simulated spectrum. Provide count rate estimates
# appropriate for INTRINSIC source fluxes.
expected_ct_rate:
# Channel assumption for S/N calculation. See Phase 2 Instructions.
# Valid entries are: LIF1, LIF2, SIC1, SIC2, or TOTAL.
sig_noise_chan: LIF1
# Calculated S/N per specified resolution element; e.g., 15.
sig_noise: 21
# NB: sig_noise: 28.92 has been computed from the flux_lambda_ref above.
# This value is a TOTAL channel S/N calculation and will be incorrect
# if the channel specified above is different from TOTAL.
# Spectral type (if appropriate). NO SPACES.
# Do NOT enter the FUSE source type designation (e.g., "PE") here.
spectral_type: sdOB
# E(B-V) in magnitudes; e.g., 0.10.
color_excess: 0.1
# Source redshift: Z format or km/s, as appropriate.
red_shift:
# High proper motion flag. Enter Y if you applied a Proper Motion
# correction to the coordinates above. Enter N or leave blank otherwise.
high_prop_motion:
# Target priority within this program: 1 or 2 for science targets.
# Use 4 for offset stars.
object_prio:
# Phase zero point and period. See Phase 2 instructions.
# Only needed for EPHEM observations.
phase_zero:
phase_period:
#
# ##################################################
# ## ##
# ## Object 1 Observation-specific Information ##
# ## ##
# ##################################################
#
# Repeat as needed to specify additional observations of a given target.
# The `observation_num:' keyword must be first for each new observation.
#
# As with above, comments and format examples are given preceding each
# line. These comments may be deleted if you wish.
# Observation number: Use 1-99.
# Start with 1 for each new object.
# For MON observations, enter 1 TO N, where N is the
# total number of observations on the object.
observation_num: 1
# Object number of the target for this observation.
obs_object_num: 1
# Object number of the offset target, if any.
off_object_num:
# Instrument mode: HIST or TTAG.
instrument_mode:
# Aperture for science: LWRS, MDRS, or HIRS.
aperture_req: MDRS
# Observation time in SECONDS; e.g., 20000. NO COMMAS.
# NOTE: "per observation" for MON observations.
obs_time_req: 26000
# Observation-level special requirements:
# HOLD, SNAP, SAFTSNP, MON, ROLL, EPHEM, SPATIAL, CONTIG,
# CVZ, COORD, FESIMG, FPSPLIT. See Phase 2 Instructions for details.
# If you need to specify more than one special requirement,
# enter them all on one line with commas between them.
obs_spec_req:
# If ROLL spec. requirement was specified above, enter
# position angle and tolerance in decimal degrees.
# Allowed ROLL angles are: aperture_pa +/- pa_tolerance.
# Sample inputs: aperture_pa: 25.0 and pa_tolerance: 5.0.
aperture_pa:
pa_tolerance:
# If MON spec. req. was specified above, enter separation
# and tolerance on separation. Example: 21.00 and 3.00.
mon_t_sep:
mon_delta_tsep:
# If EPHEM spec. req. was specified above, enter
# desired phase (between 0.0 and 1.0) and
# phase tolerance. Example: 0.5 and 0.05.
phase_desired:
phase_delta:
# If FESIMG spec. req. was specified above, enter
# target position with respect to aperture: IN or OUT.
targ_pos:
# ############################
# ## ##
# ## Object 2 Information ##
# ## ##
# ############################
# Object number. Use 1-99.
object_number: 2
# Object name from Phase 1 when possible. NO SPACES in target name.
object_name: NGC6992-P1
# Numerical object class from listing in Appendix B.
object_class:
# Object-level special requirement(s): MOVE and/or TOO.
object_spec_req:
# RA and Dec in J2000.
# Use format: 20:31:45.22 and +31:02:01.5 (INCLUDING the colons).
ra_j2000: 20:57:26.75
dec_j2000: 31:22:43.0
# Two-letter source type designation: PC, PE, EC, or EE.
source_type: EE
# Reference wavelength in Angstroms; e.g., 1032.0.
lambda_ref: 1032
# Reference flux in cgs units; e.g., 1.2E-12. NO SPACES.
flux_lambda_ref: 7.5e-13
# FWHM of emission line in Angstroms; e.g., 0.5.
# Required for PE and EE types.
eline_fwhm: 0.2
# "Flux" per sq. arcsec. Extended sources only (EE and EC).
# Example: 3.0E-15
sb_lambda_ref: 9.4e-15
# Equiv. continuum fluxes at 950, 1050, and 1150 A; e.g., 1.2E-12.
# NOTE: For BRIGHT objects (fluxes above the nominal limit of 1e-10)
# these MUST be the INTRINSIC fluxes for the TARGET
# NO offset or defocused fluxes. See Phase 2 Instructions.
flux_950:
flux_1050:
flux_1150:
# Flux accuracy: HIGH, MED, or LOW. See Phase 2 Instructions.
flux_accuracy:
# V magnitude in magnitudes; e.g., 12.5.
# If V magnitude is not applicable to your target, enter 99.
v_mag: 99
# Magnitude range (variable sources only). Example: 9.9-13.2.
v_range:
# Resolution element (for S/N calc.) in Angstroms; e.g., 0.033.
resolution_element: 0.032
# Total expected cts/sec, preferably from Exposure Time Calculator,
# Count Rate Tool or simulated spectrum. Provide count rate estimates
# appropriate for INTRINSIC source fluxes.
expected_ct_rate:
# Channel assumption for S/N calculation. See Phase 2 Instructions.
# Valid entries are: LIF1, LIF2, SIC1, SIC2, or TOTAL.
sig_noise_chan: LIF1
# Calculated S/N per specified resolution element; e.g., 15.
sig_noise: 17.8
# NB: sig_noise: 54.62 has been computed from the flux_lambda_ref above.
# This value is a TOTAL channel S/N calculation and will be incorrect
# if the channel specified above is different from TOTAL.
# Spectral type (if appropriate). NO SPACES.
# Do NOT enter the FUSE source type designation (e.g., "PE") here.
spectral_type: SNR
# E(B-V) in magnitudes; e.g., 0.10.
color_excess: 0.08
# Source redshift: Z format or km/s, as appropriate.
red_shift:
# High proper motion flag. Enter Y if you applied a Proper Motion
# correction to the coordinates above. Enter N or leave blank otherwise.
high_prop_motion:
# Target priority within this program: 1 or 2 for science targets.
# Use 4 for offset stars.
object_prio:
# Phase zero point and period. See Phase 2 instructions.
# Only needed for EPHEM observations.
phase_zero:
phase_period:
#
# ##################################################
# ## ##
# ## Object 2 Observation-specific Information ##
# ## ##
# ##################################################
#
# Repeat as needed to specify additional observations of a given target.
# The `observation_num:' keyword must be first for each new observation.
#
# As with above, comments and format examples are given preceding each
# line. These comments may be deleted if you wish.
# Observation number: Use 1-99.
# Start with 1 for each new object.
# For MON observations, enter 1 TO N, where N is the
# total number of observations on the object.
observation_num: 1
# Object number of the target for this observation.
obs_object_num: 2
# Object number of the offset target, if any.
off_object_num:
# Instrument mode: HIST or TTAG.
instrument_mode:
# Aperture for science: LWRS, MDRS, or HIRS.
aperture_req: MDRS
# Observation time in SECONDS; e.g., 20000. NO COMMAS.
# NOTE: "per observation" for MON observations.
obs_time_req: 10000
# Observation-level special requirements:
# HOLD, SNAP, SAFTSNP, MON, ROLL, EPHEM, SPATIAL, CONTIG,
# CVZ, COORD, FESIMG, FPSPLIT. See Phase 2 Instructions for details.
# If you need to specify more than one special requirement,
# enter them all on one line with commas between them.
obs_spec_req:
# If ROLL spec. requirement was specified above, enter
# position angle and tolerance in decimal degrees.
# Allowed ROLL angles are: aperture_pa +/- pa_tolerance.
# Sample inputs: aperture_pa: 25.0 and pa_tolerance: 5.0.
aperture_pa:
pa_tolerance:
# If MON spec. req. was specified above, enter separation
# and tolerance on separation. Example: 21.00 and 3.00.
mon_t_sep:
mon_delta_tsep:
# If EPHEM spec. req. was specified above, enter
# desired phase (between 0.0 and 1.0) and
# phase tolerance. Example: 0.5 and 0.05.
phase_desired:
phase_delta:
# If FESIMG spec. req. was specified above, enter
# target position with respect to aperture: IN or OUT.
targ_pos:
# ############################
# ## ##
# ## Object 3 Information ##
# ## ##
# ############################
# Object number. Use 1-99.
object_number: 3
# Object name from Phase 1 when possible. NO SPACES in target name.
object_name: NGC6992-P2
# Numerical object class from listing in Appendix B.
object_class:
# Object-level special requirement(s): MOVE and/or TOO.
object_spec_req:
# RA and Dec in J2000.
# Use format: 20:31:45.22 and +31:02:01.5 (INCLUDING the colons).
ra_j2000: 20:57:26.95
dec_j2000: 31:23:03.0
# Two-letter source type designation: PC, PE, EC, or EE.
source_type: EE
# Reference wavelength in Angstroms; e.g., 1032.0.
lambda_ref: 1032
# Reference flux in cgs units; e.g., 1.2E-12. NO SPACES.
flux_lambda_ref: 7.5e-13
# FWHM of emission line in Angstroms; e.g., 0.5.
# Required for PE and EE types.
eline_fwhm: 0.2
# "Flux" per sq. arcsec. Extended sources only (EE and EC).
# Example: 3.0E-15
sb_lambda_ref: 9.4e-15
# Equiv. continuum fluxes at 950, 1050, and 1150 A; e.g., 1.2E-12.
# NOTE: For BRIGHT objects (fluxes above the nominal limit of 1e-10)
# these MUST be the INTRINSIC fluxes for the TARGET
# NO offset or defocused fluxes. See Phase 2 Instructions.
flux_950:
flux_1050:
flux_1150:
# Flux accuracy: HIGH, MED, or LOW. See Phase 2 Instructions.
flux_accuracy:
# V magnitude in magnitudes; e.g., 12.5.
# If V magnitude is not applicable to your target, enter 99.
v_mag: 99
# Magnitude range (variable sources only). Example: 9.9-13.2.
v_range:
# Resolution element (for S/N calc.) in Angstroms; e.g., 0.033.
resolution_element: 0.032
# Total expected cts/sec, preferably from Exposure Time Calculator,
# Count Rate Tool or simulated spectrum. Provide count rate estimates
# appropriate for INTRINSIC source fluxes.
expected_ct_rate:
# Channel assumption for S/N calculation. See Phase 2 Instructions.
# Valid entries are: LIF1, LIF2, SIC1, SIC2, or TOTAL.
sig_noise_chan: LIF1
# Calculated S/N per specified resolution element; e.g., 15.
sig_noise: 17.8
# NB: sig_noise: 54.62 has been computed from the flux_lambda_ref above.
# This value is a TOTAL channel S/N calculation and will be incorrect
# if the channel specified above is different from TOTAL.
# Spectral type (if appropriate). NO SPACES.
# Do NOT enter the FUSE source type designation (e.g., "PE") here.
spectral_type: SNR
# E(B-V) in magnitudes; e.g., 0.10.
color_excess: 0.08
# Source redshift: Z format or km/s, as appropriate.
red_shift:
# High proper motion flag. Enter Y if you applied a Proper Motion
# correction to the coordinates above. Enter N or leave blank otherwise.
high_prop_motion:
# Target priority within this program: 1 or 2 for science targets.
# Use 4 for offset stars.
object_prio:
# Phase zero point and period. See Phase 2 instructions.
# Only needed for EPHEM observations.
phase_zero:
phase_period:
#
# ##################################################
# ## ##
# ## Object 3 Observation-specific Information ##
# ## ##
# ##################################################
#
# Repeat as needed to specify additional observations of a given target.
# The `observation_num:' keyword must be first for each new observation.
#
# As with above, comments and format examples are given preceding each
# line. These comments may be deleted if you wish.
# Observation number: Use 1-99.
# Start with 1 for each new object.
# For MON observations, enter 1 TO N, where N is the
# total number of observations on the object.
observation_num: 1
# Object number of the target for this observation.
obs_object_num: 3
# Object number of the offset target, if any.
off_object_num:
# Instrument mode: HIST or TTAG.
instrument_mode:
# Aperture for science: LWRS, MDRS, or HIRS.
aperture_req: MDRS
# Observation time in SECONDS; e.g., 20000. NO COMMAS.
# NOTE: "per observation" for MON observations.
obs_time_req: 10000
# Observation-level special requirements:
# HOLD, SNAP, SAFTSNP, MON, ROLL, EPHEM, SPATIAL, CONTIG,
# CVZ, COORD, FESIMG, FPSPLIT. See Phase 2 Instructions for details.
# If you need to specify more than one special requirement,
# enter them all on one line with commas between them.
obs_spec_req:
# If ROLL spec. requirement was specified above, enter
# position angle and tolerance in decimal degrees.
# Allowed ROLL angles are: aperture_pa +/- pa_tolerance.
# Sample inputs: aperture_pa: 25.0 and pa_tolerance: 5.0.
aperture_pa:
pa_tolerance:
# If MON spec. req. was specified above, enter separation
# and tolerance on separation. Example: 21.00 and 3.00.
mon_t_sep:
mon_delta_tsep:
# If EPHEM spec. req. was specified above, enter
# desired phase (between 0.0 and 1.0) and
# phase tolerance. Example: 0.5 and 0.05.
phase_desired:
phase_delta:
# If FESIMG spec. req. was specified above, enter
# target position with respect to aperture: IN or OUT.
targ_pos:
# Duplicate above lines as necessary for additional
# targets and/or observations.
# End of form.
Appendix B: Numerical Object Class Designations
Below are the IUE target class codes (cf. IUE Observer's Guide, in IUE Newsletter 32, pg. 78, July 1987), including a few changes or additions. Obviously, some of these are not appropriate for FUSE, but many are. Specifying a reasonable code number will make comparisons between the IUE and FUSE archives more straightforward.
00 Sun 50 R, N, or S Type Star 01 Earth 51 Long Period Variables 02 Moon 52 Irregular Variables 03 Planet 53 Regular Variables 04 Planetary Satellite 54 Dwarf Novae 05 Minor Planet 55 Classical Novae 06 Comet 56 Supernovae 07 Sky Background 57 Symbiotic Stars 08 Great Red Spot 58 T Tauri Stars 09 59 X-ray Source 10 WC 60 Shell Star 11 WN 61 Eta Carinae 12 Main Sequence O 62 Pulsar 13 Supergiant O 63 Nova-like 14 Oe 64 Other 15 Of 65 Misidentified Targets 16 O Subdwarf 66 Interacting Binaries 17 WD O 67 18 Post-AGB Star 68 19 Other Strong UV source 69 Herbig-Haro Object 20 B0-B2 IV-V 70 Cent. Star Plan. Neb. 21 B3-B5 IV-V 71 Planetary Nebula 22 B6-B9.5 IV-V 72 H II Region 23 B0-B2 I-III 73 Reflection Nebula 24 B3-B5 I-III 74 Dark Cloud (Absorp. spectrum) 25 B6-B9.5 I-III 75 Supernova Remnant 26 Be 76 Ring Nebula (Shock-ionized) 27 Bp 77 28 B Subdwarf 78 29 WDB 79 30 A0-3 IV-V 80 Spiral Galaxy 31 A4-9 IV-V 81 Elliptical Galaxy 32 A0-3 I-III 82 Irregular Galaxy 33 A4-9 I-III 83 Globular Cluster 34 Ae 84 Seyfert Galaxy 35 Am 85 Quasar 36 Ap 86 Radio Galaxy 37 WDA 87 BL Lac Object 38 Horiz. Branch Stars 88 Emission-line Galaxy (non-Seyfert) 39 Composite Spectra 89 Starburst Galaxy 40 F0-2 90 Intergalactic Medium 41 F3-9 91 42 Fp 92 43 Late-type Degenerates 93 44 G IV-V 94 45 G I-III 95 46 K IV-V 96 47 K I-III 97 48 M IV-V 98 49 M I-III 99
Appendix C: FUSE Phase 2 Submission Checklist for Cycle 5
Appendix D: Phase 2 Parser Message Summary
The Parser program that is run on incoming Phase 2 submissions in both the `p2test' and `p2submit' accounts performs a number of automated checks on the file to ensure proper syntax, check for required keywords, and check allocations and target listings against those approved by NASA. In addition, the Parser performs some "sanity checks" on the supplied fluxes and signal-to-noise and flags those situations where it finds large differences from what the user has provided.
The Parser log file will thus contain a number of messages to the user, some of which are benign ("FYI" and "NOTE" messages), some of which are potentially serious ("WARNINGS"), and some of which indicate unacceptable conditions in the file ("ERRORS").
ERRORS MUST BE FIXED BEFORE THE PROGRAM WILL BE ACCEPTED INTO THE FUSE PLANNING SYSTEM.
You should also review the Parser log file for each submission of your program to ensure NOTES and/or WARNINGS are understood and/or benign.
Below are some typical messages produced by the Parser with some brief explanations.
NOTE: The observation time for ObjectThis message occurs if you specify an observing time of less than 4000 seconds in the Phase 2 keyword obs_time_req. Because you will be charged 4000 seconds for any short observations (due to overheads), you should take this into account when comparing your total observing time to your allocation., Observation is between 1000 and 4000 seconds. For accounting purposes you will be charged 4000 seconds.
FYI: Due to the brightness of this observation's target, it will
be placed on hold until a SAFTSNP is completed.
Object: 01 Observation: 01
Warning: Count Rate exceeds 32000
Object: 3 Observation: 1
Specified: 39000 Computed: 41221
What you should do: The FUSE detectors cannot record events faster than 32,000 cts/sec
without losing information. This message flags situations where photometric information
may be lost. Also, such targets may be near the brightness limit, depending on
source spectrum shape. Review the target to ensure safety and that photometric
inaccuracy is not a concern to the science.
Warning: The program specified count rate of 8731.2 was not within
50.0 percent of the computed count rate of 19526.8 .
Object: 14 Name: HD12345
What you should do: Count rates calculated by you and by the Parser can be
different for a number of reasons, some of which could be valid and understandable
and others of which could be due to an error. We have no way of knowing a priori
what causes a flagged difference. You should review any such cases flagged by the
Parser to ensure that you understand why a difference in count rate was determined,
entering the most accurate count rate available. (Accurate count rates are important
for managing spacecraft memory usage on the satellite and selecting the proper instrument
mode.) Note especially that the Parser uses provided fluxes to extrapolate a continuum, and
may be in error for emission line sources.
Warning: You have specified a S/N > 30, which may not
be attainable at full resolution.
Object: 2 Name: HD123456
Program Specified S/N: 35
Parser Computed S/N: 38.7
What you should do: This message is generated whenever a S/N over 30 is
requested (independent of resolution element). To achieve S/N>30 an FPSPLIT procedure
is required. Only if you proposed for, and was awarded time, to do this in the phase 1
process should you enter observations with S/N significantly in excess of 30.
For reference, the S/N value calculated
by the Parser will also be shown.
Warning: The Program Specified S/N of 4 was not within
20.0 percent of the computed S/N of 9.86 .
Object: 1 Name: HD12345
What you should do: This message is triggered when the Parser's S/N calculation is
different from that supplied by the user by some threshold (which we have set to 20%).
In many cases, there are understandable reasons for the difference, in which case the
warning is benign. Check these warnings to ensure the differences are understood.
Warning: This observation may be changed from TTAG to HIST
due to a computed count rate of 2734.9
If TTAG needed, supply justification in support_info_text.
Object: 29 Observation: 1
What you should do: This message results if the Parser computes a
count rate on your target >2500 but you have specified TTAG mode. Review
need for TTAG and supply text justification if you proceed in this manner.
Warning message will still appear in log even when text is included.
Warning: No Object Name from the Phase 1 version of this
program was found that exactly matched this Phase 2 Object.
Below are the Phase 2 Object Number 1 and all Phase 1 Objects
whose pointings are similar.
Target RA (J2000) Dec (J2000)
-------------------- ------------ ------------
Phase 2: NGC1234 01:02:34 12:34:58
Phase 1: MY-STAR 01:02:34.3 12:35:01
What you should do: This message is generated if/when you have updated or changed a
target name from Phase 1. The Parser tries to verify that all submitted targets have
a Phase 1 counterpart. Hence, when names don't match, it searches on coordinates and
lists the closest targets it finds. Verify that the target
you have entered is indeed an approved target for your program and enter a note in
the Support Info text section to clarify.
WARNING: Strategy: is an unrecognized keyword in the following line.
Strategy: We will observe NGC1234 on 3 separate occasions
NOTE: This error may be caused when a : is a member of the
character string in a text block.
What you should do: Since keywords in the template end in colons, the Parser
can get fooled by colons used in the text. Look through your text blocks (abstract,
feasibility, special requirements, etc.) for a text line that has a
colon (:) in it. Delete the colon (or change it to a semi-colon or
dash). NOTE: These messages sometimes pop up from e-mail headers on submissions.
These warnings are benign and can be ignored.
Warning: Encountered a line of text with a length greater
than 90 characters. This may have been caused
by using software that word-wrapped. You should
consider putting hard carriage returns on your
text lines.
What you should do: It is best to enter text in standard 80 character (or less)
lines to prevent line wraps. Long text lines sometimes get truncated by e-mail
tools and cause other problems. Just hit a hard carriage return once in awhile to
avoid problems!
Warning: You indicated an offset star for a HIRS Observation
that could not be located by the phase 2 checking
software. Please double check your program for this.
What you should do: Ensure that all offset stars are entered properly AND
cross-references properly to their science targets using the `off_object_num'
keyword.
Warning: Signal-to-noise channel has not been specified. Value of TOTAL will be used in S/N computation. If this is not correct, please fix the sig_noise_chan value in the Phase 2 and re-submit. Object: 01 Name: HD1234What you should do: The keyword sig_noise_chan was added in Cycle 2 to permit users to indicate whether the S/N was calculated for an individual channel or for the "total" effective area from all channels at a given reference wavelength. Check the provided information and make sure "TOTAL" is what you want!
Error: Object Number 29 is not on TAC-approved list for this program.
Target RA (J2000) Dec (J2000)
-------------------- ------------ ------------
BD+123456 12:34:56.11 +12:00:14.5
What you should do: Review your acceptance letter and materials to ensure that
you have only included approved targets in your Phase 2 submission. The Parser
compares your Phase 2 targets against the approved Phase 1 list. If a coordinate update
occurs that is different by more than 30 arcsec from the Phase 1 listing, this error
message may get generated even if the target name is exactly the same. If this
message is incorrect, contact FUSE MP personnel at `fuse_support' for assistance.
Error: Total computed observing time for this program is greater
than amount allocated.
Computed Time: 14000 Allocated Time: 12000
What you should do: This error most often occurs due to
improper accounting of short exposure time objects and SAFTSNPs. Review and adjust
the obs_time_req keywords in
your Phase 2. Observations <4000 seconds are accounted as 4000 seconds,
and SAFTSNP's are accounted as 2000 seconds against your allocation. Adjust the
observing times appropriately so that your total computed time agrees with the
allocated time. Programs requesting more than their allocations cannot be accepted.
Error: The object in this observation is too faint to be
peaked up in the HIRS or MDRS aperture. You must either
specify an offset star or change to the LWRS aperture.
Object: 5 Observation: 1
What you should do: If the HIRS or MDRS aperture is needed, you must supply
an offset star (see section 4.4 of the FUSE Observers Guide). Otherwise,
change the aperture_req keyword to LWRS.
ERROR: This Target has a flux >= MED brightness limit of 5.0E-11
and no SAFTSNP has been specified.
Object: 9 Name: HD108767
What you should do: This is one of several messages that can result from relatively
bright fluxes and relatively poor flux accuracy. Review the rules for when
a SAFTSNP observation is required and add one on the indicated target as needed.
ERROR: Right Ascension 56:10:05.9 for Object 01.
is not within expected range 00:00:00 - 23:59:59
What you should do: This should only occur for a severe typo in one of your
coordinates that drives it out of range. Fix the typo.
ERROR: Both your main target and indicated offset target are too
faint to be peaked up in the HIRS or MDRS aperture. You must either
specify a different offset star or change to the LWRS aperture.
Object: 01 Observation: 01 Offset: 02
What you should do: If a peak-up is needed to acquire the target and align the channels,
either the target or the supplied offset star must have sufficient flux to produce
at least 100 counts/channel/10 s integration. Check the supplied fluxes and/or choose
a brighter offset star.
There are numerous other Warning or ERROR messages for such things as missing or improperly specified information, missing required keywords, and out-of-range parameters whose meaning should be self-explanatory. If you have questions, please email FUSE User Support