Update Log:
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.
General link to the FUSE Public Web page is http://fuse.pha.jhu.edu. From there you can get to the following resources:
The submission of Phase 2 Proposals for Cycle 3 will provide FUSE Mission Planners with verified, detailed information for properly scheduling approved Phase 1 proposals on the satellite. The forms to support the Phase 2 submission are identical for the Principal Investigator (PI) team and GIs; the only difference is that a GI will be provided with a Phase 2 "template" that is partially filled-out (using data from your Phase 1 submission).
The purpose of this document is to provide all of the supporting information and documentation necessary to help GIs fill out the Phase 2 template files properly. Section 2 provides a brief overview of the current procedures for FUSE mission planning. Section 3 describes some general considerations about the Phase 2 process. Section 4 provides a field-by-field description of the Phase 2 forms, including syntax issues, and discusses allowed values or choices for each parameter. Section 5 provides details on checking and submitting your proposal 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 general 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. It is important to realize that these text blocks will not just be stuffed in a file somewhere; FUSE mission planners will actually read this information and use it to help plan your program.
Another important point is that very little instrument-specific information is requested from the user. Other than the requested exposure time, desired spectrograph aperture and the option to suggest instrument mode (time-tag or histogram), nothing else is requested. Rather, 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. Again, 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 will be submitted electronically (see section 5). An initial submission to a "test" account is required to catch and correct syntax or other problems prior to an "official" submission of the program. (Multiple iterations with the test account can be made, if necessary.) A "Parser" program running in this test account checks all incoming programs 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
To provide GIs with a starting point for their Phase 2 work, we will provide a partially filled-out Phase 2 template file for your use, with many keywords populated using information from your Phase 1 proposal. This is being done largely for your convenience! It is extremely important for you to understand this, and also to know and understand some of the limitations of this process. The bottom line is that it is the user's responsibility to verify all information in the Phase 2 forms prior to final submission. You should feel free to edit or update any information carried forward into the Phase 2 template, the exceptions being the Program ID (PID), the Program Title, the TAC Allocation, and the PI and Co-I names. (Note: Co-IS can only be added in Phase 2 at the discretion of FUSE Project Scientist George Sonneborn. However, at the program PI's discretion, one of the Phase 1 Co-Is can be listed as a "Lead Investigator." See discussion in section 4.1 below.)
Text Blocks:
The Phase 2 template file is an ASCII file and will be parsed by our software. Since the Phase 1 proposals were in LaTeX (to allow formatting), we have decided NOT to carry forward appropriate text blocks from Phase 1 to Phase 2. We expect many users will "cut and paste" appropriate text from Phase 1 and modify or embellish it for use in Phase 2. You should remove LaTeX formatting characters in this process and/or simply not use formatting characters if you are typing in new text because they may cause problems in the Parser. 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). This will be the version archived with your data and will be available to the public. Again, the text blocks requested are important for proper scheduling and will not be just filed away. Please describe carefully the needs of your program in the requested text blocks.
Allocations and Targets:
The observing time you requested in Phase 1 may have been reduced (or in a few instances increased) in the Peer Review process. Your "official" program time allocation will appear in your Phase 2 template. (Check this against your acceptance letter!) Your submitted program will need to conform to this allocation, including any time set aside for so-called SAFTSNP observations (see below).
You should note however that target and observation information is carried forward directly from your Phase 1 proposal! If the Peer Review has reduced your allocation, the observing time listed in your Phase 2 template will oversubscribe your allocation. It is your responsibility to modify the requested observation times to comply with your observing time allocation. This information will be checked upon submission.
In addition, some accepted programs may have had specific targets disallowed due to conflicts with other programs. 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:
If you worked hard in Phase 1 and provided accurate coordinates and support information for your targets, you should be in good shape here. The information you provided for your targets should be reproduced in the Phase 2 template just as you provided it, assuming you followed the correct format for submission in Phase 1. Additional information is requested in Phase 2, however, so you will still have some work to do.
If you cut corners in Phase 1, supplying approximate coordinates or
other info, it is time to pay the piper! You will need to carefully review and
update the information that is returned in the Phase 2 template as well as
supplying the additional information requested. Again, in either case,
the responsibility for verifying the accuracy of the supplied information rests
with the user. You are strongly encouraged to check coordinate accuracies 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 they can be of low quality.
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
substantially different S/N (based on your Phase 1 information) than you listed
in your Phase 1 proposal, a comment line will appear in your Phase 2 template
highlighting the difference.
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 becoming active 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 the "Special Requirements" section (3.7) 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. This will be filled in for you in the template file, and provided to you separately. You should check for consistency between these numbers and resolve any differences that may inadvertently occur by contacting FUSE user support (fuse_support@pha.jhu.edu)
GI program target lists 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". We intend these priorities to be largely informational, providing us with information on "relative" priorities within a program in the event they are needed. They will NOT be used to judge relative target priorities between 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 for all objects in the program should add up to your program's allocation.
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:
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 those fluxes that are based on measurements in the satellite UV (IUE, HUT, ORFEUS etc. at wavelengths less than ~1190A), 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 hope YOU 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.7, will be implemented in any cases 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 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.5 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.6 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.
During Cycles 1 & 2, 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.
For cycle 3, we have added the SR FPSPLIT, 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.7 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. (Note: HIRES and NIGHT special requirements are no longer valid. However, those proposers who requested and were awarded the extra observing time to achieve a given amount of shadow observations (a factor 1.6; see the cycle 3 NRA) should note this in the text blocks of the phase 2 submissions) Very briefly, 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. Very briefly, the meaning of each of these is:
3.8 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:
To jump right to the bottom line, if your targets can be observed with the LWRS aperture, and if your target 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.9 Coordinates and Proper Motion Corrections
It is the user's responsibility to provide target coordinates in Phase 2 corrected from the epoch of whatever plate material or catalog they are using to J2000. In general, absolute coordinates good to about ± 2 arcsec should be sufficient for FUSE. However, in detail the accuracy required is somewhat 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 user'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.)
As a final note, any target acquisition failures due to inaccurate target coordinates will result in your 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)This 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 3 they begin with the letter "C") were assigned to proposals by the proposal system upon original submission. 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.)
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 cannot be changed or updated. Please ensure something is entered in all of these fields, including `pi_title'. (Our software keys off this to determine a new record.) So enter SOMETHING here: Dr., Prof. , Mr. , Ms., 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 his/her discretion, the program PI can designate one of the Phase 1 Co-Is to be a "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 an `object' and `observation' level below. A text block is encouraged here to discuss in general terms any such requirements of the program. 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.7 above for a discussion of these SRs.
support_info_text: (Optional, as needed)Brief text block. The user should describe any special considerations or strategy issues here, or desires to use possible "extended" capabilities of the satellite, should they become available. These may include such things as:
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.8 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.7.)
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 mnemonic 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 of "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.
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-Å.
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 Support Info text. See notes in section 3.9 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 mnemonic 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 3 are ROLL, MON, HOLD, EPHEM, SNAP, SAFTSNP, SPATIAL, CONTIG, CVZ, COORD, FESIMG and FPSPLIT. (Meanings are described above in section 3.7.)
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 -- for error checking and formatting.
p2submit@pha.jhu.edu -- for submission of error free, complete Phase 2
program files.
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 a "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), and for moving targets Hal Weaver (e-mail: weaver@pha.jhu.edu). It is an excellent protocol to 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 shows examples and syntax, but is not meant to represent a completely self-consistent proposal. For visibility, comments and unused keywords are left in place, but you may delete them if unused or unneeded.
#
#
#
# #########################################
# ## ##
# ## FUSE Phase 2 Proposal Example ##
# ## ##
# ## for Use in Cycle 3, 9/1/2001 ##
# ## ##
# #########################################
#
#
# Proposal Identification
prog_id: P114
title: FUSE Team Project on Supernova Remnants
t_alloc_total: 25 # Ksec
t_alloc_orb: # Orbits, for French programs only.
# ######################
# ## ##
# ## PI Information ##
# ## ##
# ######################
pi_title: Dr.
pi_first_name: William P.
pi_last_name: Blair
pi_affiliation: Dept. of Physics and Astronomy
pi_institution: Johns Hopkins University
pi_address: 34th and Charles Streets, Baltimore , MD, 21218-2686
pi_country: USA
pi_phone: 410-516-1234
pi_fax: 410-516-1234
pi_email: wpb@pha.jhu.edu
# ######################
# ## ##
# ## LI Information ##
# ## ##
# ######################
li_title: Mr.
li_first_name: Carl A.
li_last_name: Johnson
li_affiliation: Space Telescope Science Institute
li_institution: AURA
li_address: 3700 San Martin Drive, Baltimore, MD, 21218
li_country: USA
li_phone: 410-338-1234
li_fax: 410-338-1234
li_email: cjohnson@stsci.edu
# ########################
# ## ##
# ## COIs Information ##
# ## ##
# ########################
# COI - 1
coi_title: Dr.
coi_first_name: Kenneth
coi_last_name: Sembach
coi_institution: Johns Hopkins University
coi_country: USA
coi_phone: 410-516-1234
coi_email: sembach@pha.jhu.edu
# COI - 2 to N: Repeat above as necessary.
#
# ############################
# ## ##
# ## Proposal Information ##
# ## ##
# ############################
# -------------
# | Abstract |
# -------------
abstract_text:
This abstract contains no LaTex commands, and otherwise describes my program
perfectly. It was carried forward from my Phase 1 proposal and modified
slightly for use here.
# ----------------
# | Feasibility |
# ----------------
feasibility_text:
All of these observations are based on previous FUV observations,
so the flux levels are actually known. We have made extensive use
of the FUSE on-line simulator and ETC to verify count rates.
However, even with this, there are uncertainties in the expected
emission line widths. Assuming a "worst case" of unresolved
emission lines, however, indicates there are no safety concerns
with these targets.
# ------------------
# | Special Reqs. |
# ------------------
spec_req_text:
Some of the observations require specific aperture orientations to
place the long dimension of the FUSE apertures along particular SN
remnant filaments, within a 10 degree tolerance. A grid of three
aperture positions is planned, which should be closely grouped in time.
FESIMG is specified on the first pointing to provide a reference image
of the star field in the vicinity of the slit for future reference.
Although the SPATIAL requirement is not shown (because it is not a
driver for the program), it is conceivable that some spatial information
may be obtainable at O VI.
# ------------------
# | Support Info. |
# ------------------
support_info_text:
The target positions are faint supernova remnant filaments, which must
be acquired by blind offset from a nearby star (target 2), in order to
position the FUSE aperture correctly. Although the tolerance on the
requested roll angle is 10 degrees for these observations, once one of
the observations is scheduled, the others should be observed at as close
to the same roll angle as possible.
#
# 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: CYG-LOOP-P1A
# Numerical object class from listing in Appendix B.
object_class: 75
# 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:47:32.1
dec_j2000: +31:02:01.5
# 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: 1.2E-12
# FWHM of emission line in Angstroms; e.g., 0.5.
eline_fwhm: 0.5
# "Flux" per sq. arcsec. Extended sources only.
sb_lambda_ref: 6.0E-14
# Equiv. continuum fluxes at 950, 1050, and 1150 A; e.g., 1.2E-12.
flux_950:
flux_1050:
flux_1150:
# Flux accuracy: HIGH, MED, or LOW. See Phase 2 Instructions.
flux_accuracy: HIGH
# V magnitude in magnitudes; e.g., 12.5.
# If V magnitude is not applicable to your target, enter 99.
v_mag:
# Magnitude range (variable sources only). Example: 9.9-13.2.
v_range:
# Resolution element (for S/N calc.) in Angstroms; e.g., 0.05.
resolution_element: 0.1
# Total expected cts/sec, preferably from Exposure Time Calculator,
# Count Rate Tool or simulated spectrum.
expected_ct_rate: 55
# Channel assumption for S/N calculation. See Phase 2 Instructions.
# Valid entries are: LIF1, LIF2, SIC1, SIC2, or TOTAL.
sig_noise_chan: TOTAL
# Calculated S/N per specified resolution element.
sig_noise: 20
# NB: sig_noise: has been computed from the flux_lambda_ref above
# Spectral type (if appropriate). NO SPACES.
# Do NOT enter PC, PE, EC, or EE here.
spectral_type:
# 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: N
# Target priority within this program: 1 or 2 for science targets.
# Use 4 for offset stars.
object_prio: 1
# Phase zero point and period. See Phase 2 instructions.
# Only needed for EPHEM observations.
phase_zero:
phase_period:
# ###################################
# ## ##
# ## Obj 1 Obs 1 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: 2
# Instrument mode: HIST or TTAG.
instrument_mode: TTAG
# 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.
# SAFTSNP's: Enter 60 or leave blank.
obs_time_req: 8000
# Observation-level special requirements:
# HOLD, SNAP, SAFTSNP, MON, ROLL, EPHEM, SPATIAL, CONTIG,
# CVZ, COORD, FESIMG, FPSPLIT. See Phase 2 Instructions for
# full details.
# If you need to specify more than one special requirement,
# enter them all on one line with commas between them.
obs_spec_req: ROLL, FESIMG
# If ROLL spec. requirement was specified above, enter
# position angle and tolerance in decimal degrees.
# Allowed ROLL angles are: aperture_pa +/- pa_tolerance
# Example: 25.0 and 5.0.
aperture_pa: 135.
pa_tolerance: 10.
# 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: IN
#-----------------------------------------------------------
# Next Object: Example OFFSET star Object listing. (Note: no
# "observation" fields required.)
# ############################
# ## ##
# ## Object 2 Information ##
# ## ##
# ############################
object_number: 2
object_name: CYG-LOOP-P1A-OFF
object_class: 21
object_spec_req:
ra_j2000: 20:47:35.2
dec_j2000: +31:03:22.1
source_type: PC
lambda_ref: 1000.
flux_lambda_ref: 5.5E-12
eline_fwhm:
sb_lambda_ref:
flux_950: 1.1E-12
flux_1050: 1.05E-12
flux_1150: 1.0E-12
flux_accuracy: MED
v_mag: 12.2
v_range:
resolution_element:
expected_ct_rate:
sig_noise_chan:
sig_noise:
spectral_type: B4V
color_excess:
red_shift:
high_prop_motion: N
object_prio: 4
phase_zero:
phase_period:
# An object listing this as an offset target would specify `off_object_num'
# as "2" in the observation listing, as done above for target 1.
#-----------------------------------------------------------
# Next Object: Example Extragalactic Target and MON observation.
# ############################
# ## ##
# ## Object 3 Information ##
# ## ##
# ############################
object_number: 3
object_name: NGC4151
object_class: 84
object_spec_req:
ra_j2000: 14:47:35.2
dec_j2000: -21:03:22.1
source_type: EC
lambda_ref: 1000.
flux_lambda_ref: 3.0E-12
eline_fwhm:
sb_lambda_ref:
flux_950: 1.0E-13
flux_1050: 1.1E-13
flux_1150: 1.2E-13
flux_accuracy: HIGH
v_mag: 12.2
v_range:
resolution_element: 0.1
expected_ct_rate: 300
sig_noise_chan: TOTAL
sig_noise: 10.0
spectral_type:
color_excess: 0.03
red_shift: 1100
high_prop_motion: N
object_prio: 1
phase_zero:
phase_period:
# ###################################
# ## ##
# ## Obj 3 Obs Information ##
# ## ##
# ###################################
#
#
# This sets up nine 4000 sec observations separated by 14 +/- 2 days.
observation_num: 1 TO 9
obs_object_num: 3
off_object_num:
instrument_mode: TTAG
aperture_req: MDRS
obs_time_req: 4000
obs_spec_req: MON
#If ROLL spec. req.
aperture_pa:
pa_tolerance:
# If MON spec. req.
mon_t_sep: 14.0
mon_delta_tsep: 2.0
# If EPHEM spec. req.
phase_desired:
phase_delta:
# If FESIMG spec. req.
targ_pos:
#-----------------------------------------------------------
# Next Object: Bright, stellar object requiring HIST observation.
# ############################
# ## ##
# ## Object 4 Information ##
# ## ##
# ############################
object_number: 4
object_name: HD13245
object_class: 23
object_spec_req:
ra_j2000: 06:53:10.2
dec_j2000: -02:42:37.6
source_type: PC
lambda_ref: 1000.
flux_lambda_ref: 3.0E-11
eline_fwhm:
sb_lambda_ref:
flux_950: 2.9E-11
flux_1050: 3.1E-11
flux_1150: 3.3E-11
flux_accuracy: MED
v_mag: 8.2
v_range:
resolution_element: 0.033
expected_ct_rate: 2830
sig_noise_chan: LIF1
sig_noise: 30.0
spectral_type: B0II
color_excess: 0.13
red_shift:
high_prop_motion: N
object_prio: 1
phase_zero:
phase_period:
# ###################################
# ## ##
# ## Obj 4 Obs Information ##
# ## ##
# ###################################
#
#
observation_num: 1
obs_object_num: 4
off_object_num:
instrument_mode: HIST
aperture_req: HIRS
obs_time_req: 4000
obs_spec_req: FESIMG
aperture_pa:
pa_tolerance:
# If MON spec. req.
mon_t_sep:
mon_delta_tsep:
# If EPHEM spec. req.
phase_desired:
phase_delta:
# If FESIMG spec. req.
targ_pos: OUT
#-----------------------------------------------------------
#(End of examples.)
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 3
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