General link to the FUSE Public Web page is http://fuse.pha.jhu.edu. From there you can get to the following resources (some at the top level, some under the "Observing with FUSE" heading):
The submission of Phase 2 Guest Investigator (GI) Proposals for Cycle 1 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 as a GI, you 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 for the first cycle. 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 being designed to handle many aspects of scheduling in an automated fashion. However, in an attempt to simplify the process, we have decided to handle certain aspects of planning in a less automated manner, in particular, those situations that we anticipate will be 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. While other options, such as a web-based form with a graphical user interface, are being discussed for possible future implementation, we do not plan to support this for the first cycle submissions.
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 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 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.
Upon submission, your program is parsed, processed, and ingested into our 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.
The primary FUSE scheduling tool is called Spike. Spike first performs Long Range Planning, placing targets into weekly bins based on target visibility and other selectable suitability functions. Spike then supports Short Term Scheduling of the targets in each bin, actually timelining detailed activities (slews, acquisitions, observations, etc.) on an orbit-by-orbit basis. The results of Short Term Scheduling are periodically formatted and delivered to the Mission Operations Team as "Mission Planning Schedules"; the MOT uses this information for so-called `pass planning' and implementation on the spacecraft. An iterative procedure is used to keep Long Range and Short Term Schedules in sync, and a feedback loop from FUSE Science Data Processing will provide information on the status of all observations actually carried out with the spacecraft.
3.1 Phase 2 Template Files
3. General Phase 2 Considerations
To provide GIs with a starting point for their Phase 2 work, we will provide a partially filled-out "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. However, 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.
Text Blocks:
The Phase 2 template file is a "flat" 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 even 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 allotment.
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 be adding 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. Additional information is requested in Phase 2, however, so you will still have some work to do.
However, 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). 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 B-G Andersson, the FUSE Guest Investigator Liaison Officer (e-mail: bg@pha.jhu.edu).
GI program target lists are built for an assumed one-year cycle of observations. Since the FUSE satellite has yet to be launched, there are a number of uncertainties about observing efficiencies and operations. 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.
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 accurate information on source fluxes and an estimate of the TOTAL expected 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.
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 work hard to 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.
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; also called "address-stream mode") and histogram mode (HIST; also called "spectral imaging mode"). 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 about 1200 cts/s TTAG mode will normally be used, and for higher rates, HIST mode will be the normal mode. There is some gray area in this decision, however. For instance a 1500-2500 ct/s object can (in principle) be observed in TTAG if scheduled when appropriate memory and downlink are available, but it will require careful coordination and planning (and extra work on our part). 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 one or the other of these instrument modes if it is important to the science requirements of the program. Text description in the Feasibility or Support Information sections should provide justification.
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 spacecraft motion 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 intend to minimize these effects (<5 km/s smearing) by scheduling a "4-pack" of HIST exposures per 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 3.6 MB of memory usage for each HIST exposure). This binning, in conjunction with a worst case Doppler smearing of 5 km/s, would lower the peak resolution from 30,000 to 27,000 (i.e from 10 km/s to 11.2 km/s).
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. The Spike scheduling tool will assess and implement observing at the exposure level.
3.6 S/N and Fixed-pattern Noise Considerations
The FUSE flight detectors are still in the process of characterization at this time. However, laboratory testing has already indicated that there is considerable variation of the fixed-pattern noise (FPN) in different parts of the detectors. In addition, the actual achievable S/N will be strongly dependent on the stability of the instrument once it is on-orbit. We remain confident that the value of "S/N = 30" advertised in the NRA is achievable in general, but there may be certain portions of the detectors where extra effort may be required.
Two techniques have been discussed that, in principle, would improve the achievable S/N considerably. These are called "focal plane splits" and "X-offsets." FP-splits involve the displacement of the Focal plane Arrays (FPAs) between individual exposures on a target, which moves the position of the spectrum on the detector in the dispersion direction. Subsequent processing of the individual spectra into a single result reduces the affects of FPN, and in certain cases may permit considerably higher S/N results than our advertised 30:1. Although operationally complex, we are working on defining a "default" strategy for FP-splits that will simplify (and standardize) the implementation. X-offsets accomplish much of the same effect as FP-splits, but at a fraction of the operational complexity. X-offsets use the LWRS (30 arcsec) aperture, and separate exposures are taken with the source positioned at different X-offset (X is the dispersion axis) positions in this large aperture. No FPA motions are necessary. On the down side, such spectra will have wider, brighter airglow lines and possibly somewhat higher scattered light (not a problem for most bright sources).
The need for FP-splits or X-offsets is, unfortunately, still somewhat subjective and the operational implementation is still uncertain. What we have decided to do is allow the user to specify one of two Special Requirements at the "observation" level that will tell us what you think should be done on a given observation. We will do our best to comply, but based on current conditions at the time of scheduling FUSE mission planners will adjust as needed. Our initial strategy will be (assuming "operational" implementation is satisfactory) to schedule FP-splits (or X-offsets) on each observation where it is requested and to do nothing additional where it is not requested. At such time that we determine the operational impacts are small enough, we may "default" to doing FP-splits even where they were not requested, simply because the data quality will be better. (This includes changing X-offsets in LWRS to FP-splits in MDRS where necessary.) Thus, you should NOT place FPSPLIT on all of your observations at this time just to "improve the data quality" -- this will happen automatically if it is feasible! Rather, use the special requirements FPSPLIT or XOFF in those cases where your assessment (albeit based on incomplete knowledge) is that it will make a difference to the science! (Note: "operational impacts" also includes the possible additional burden on Science Data Processing, which is still being assessed.) We will define "default" FP-split and X-offset implementations (number of steps, step sizes, etc.), and so no further information is needed from the user in Phase 2. Again, the need for these special requirements should be addressed in the Special Requirements text block.
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 largely informational and provide more of a "heads-up" rather than having a functional role. These are also described below. In some instances, more than one SR may apply; all appropriate SRs should be listed, separated by commas.
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) are defined with the following options on the `object_spec_req' keyword: TOO, MOVE, NIGHT, HIRES. Very briefly, the meaning of each of these is:
Observation-specific SRs are defined with the following options on the `obs_spec_req' keyword: SNAP, SAFTSNP, HOLD, ROLL, MON, EPHEM, FPSPLIT, XOFF, SPATIAL, CONTIG, FESIMG. 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 4.4 of the FUSE Observer's Guide. Here we simply concentrate on those issues that directly affect your Phase 2 submission. These issues boil down to answering the following two questions for each of your targets:
(The first question is really only important for helping you answer the second question. In Phase 2, the only direct acquisition-related information you provide is information on any offset stars.)
To jump right to the bottom line, a) if you do not require the use of the HIRS aperture, you can assume (at least pre-launch) that no PEAK-UP is required to acquire your target. Also, b) if your target is either bright visually (i.e., can be seen and centroided by the FES) and/or has sufficient FUV flux across the FUSE range that it can be centered in the aperture of choice (say F > 4E-14 ergs/cm^2-s-Å across the FUSE range), then you should not need an offset star. (Conversely, we can say that use of the HIRS aperture REQUIRES either sufficient FUV target flux for a PEAK-UP, or the use of a nearby offset star with sufficient FUV flux for a PEAK-UP.) While certain exceptions to these general statements exist,* answering these questions goes a long ways toward clarifying whether your program has potential acquisition problems or not, and in particular whether you need to specify any offset stars in Phase 2. You can (and should) enter any specific comments about acquisitions or acquisition difficulties in the "Support Info" text block in Phase 2. The remainder of this section, in conjunction with section 4.4 of the Observer's Guide, embellishes on these general statements.
Target acquisitions have several important drivers, including:
As a user, you can have input on the first two of these, but not the third. We must assume certain things about performance until after launch and in-orbit checkout.
FUSE contains four mirrors and four separate focal plane assemblies (FPAs), which must be properly aligned for optimal performance. This is accomplished through use of the FUV PEAK-UP procedure mentioned above. FUV PEAK-UPs accomplish two things: they align the four separate channels, AND they center a target properly in the selected aperture. (If either one or both of these things is needed, an FUV PEAK-UP is required.) We will assume, based on instrument specifications and ground testing to date, that the stability of the alignments of these components on orbit will be such that a) PEAK-UP will always be required for placing a point source in the HIRS aperture, and b) PEAK-UP will NOT be needed for use of MDRS or LWRS apertures.
In the limit where the telescope point spread function (PSF) is nominal and the pointing jitter is at or near the specifications (i.e., the situation we expect pre-mission), the resolution achieved through the MDRS aperture should be at worst 10% less than through the HIRS aperture. (e.g., 11 km/s resolution instead of 10 km/s). Also, recall that the HIRS aperture only passes about 65% of the light from a point source. Hence, the HIRS aperture should be considered only for certain situations. If you have a nice, bright FUV point continuum source (so PEAK-UP will be easy) and you want the best possible spectral resolution, then HIRS is a good choice. If your source is too faint for a confident PEAK-UP and you really need the HIRS aperture, you MUST supply an offset star with reasonable FUV fluxes near your target (within about 2 degrees, but the closer the better). If no good offset stars are available, you need to switch to the MDRS aperture and take a small hit on your achievable spectral resolution.
For point source targets with V magnitudes in the range [8 - 14??] we should be able to make use of the `FES Target Acq' mode (see FUSE Observer's Guide). In this mode, an FES centroid box is used to locate the target accurately relative to guide stars. We then have confidence that the target can be placed in the MDRS or LWRS apertures without need of further centroiding. For point sources visually fainter than this (or interestingly, BRIGHTER than this up to about V = 3), we expect to locate preplanned guide stars surrounding the target and use the relative target/guide star positions to place the target into the selected aperture (called FES Guide Star Acq). Hence, coordinates relative to nearby HST guide stars are particularly important for targets such as these. (The V = 3 - 8 stars will saturate in the FES, preventing good centroids. This is why a Guide Star Acq will be required for sources in this range.)
For visually brighter stars, scattering in the FES may preclude direct acquisition of guide stars in the field. However, we will not know whether this is a real problem until in-orbit tests are done. If such a target is to be observed in the HIRS aperture (and hence needs a PEAK-UP) but is faint in the FUV, an offset star (with sufficient FUV flux for a PEAK-UP) should be specified in Phase 2. To acquire such a source into one of the other apertures may require use of an offset field adjacent to the source (but with the target out of the FES field of view). FUSE mission planners can select these offset fields if and when needed.
Acquisition of point emission line sources in the HIRS aperture will also require an offset star in Cycle 1. While it is conceivable that some emission-line sources will have sufficient flux distributed across the FUSE wavelength range to allow a successful PEAK-UP, we need to have confidence that acquisitions will occur autonomously. Until demonstrated otherwise, assume such targets require an offset star for FUV PEAK-UP in the HIRS aperture.
Extended sources only require offset stars when the HIRS aperture is being used or if the aperture placement on the extended target needs to be done with precision (say at the 1 arcsec level). Otherwise a good target coordinate relative to surrounding guide stars will be sufficient for acquisition.
As a final note about target acquisitions, you should highlight any known situations where your target is in a confused field or may otherwise be a difficult acquisition for FUSE. It is in your best interest to make us aware of these cases so we can plan your observations accordingly. Because some target acquisition issues are dependent (at least in detail) on results of in-orbit testing, you will be kept apprised of any significant changes or differences from these pre-launch scenarios.
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. 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 type of acquisition (see discussion above). 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 plan to utilize the HST Guide Star Catalog to choose FUSE guide stars, this catalog is a good default source for your coordinates when possible.
It is also the user's responsibility to check their objects for significant proper motion, and if necessary correct the coordinate to the J2000 equinox (i.e., roughly the mid-point of the expected FUSE mission). Since peak-up 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 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 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.)
li_title: (All optional, unless 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: (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 at some point. 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. Offset targets should only be needed in specialized cases, where the primary target is too faint or extended for a direct "peak-up" acquisition. (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, NIGHT, HIRES. (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. In general, the most accurate coordinates available should be provided whenever possible. However, 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 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. 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. 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 and calculation of `peak-up' acquisition times when necessary. (See discussion in section 3.8 for more detailed information.) 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 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 PC type 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.
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 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: (Required)This should be the expected signal-to-noise per specified resolution element at the reference wavelength given 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 type and luminosity
class for all stellar classes.
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 will probably not be used directly for mission planning, but
will be available for reference if needed and 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. 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). 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 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,601, and would be specified 50601.) 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 keywords 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.
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 1200 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 will 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 1 are ROLL, MON, HOLD, EPHEM, SNAP, SAFTSNP, FPSPLIT, XOFF, SPATIAL, CONTIG, and FESIMG. (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.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.)
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 (say 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.
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 also specify a filter if desired. The keywords are:
targ_pos: Legal values are IN or OUT, specifying the target
position relative to the aperture. (Default will be "IN.")
fes_filter: Allowed values are ND, COL, NONE, or DEF(ault).
ND indicates a "neutral density" filter that attenuates the FOV by 6 magnitudes, so should only be used for very bright sources. COL indicates whichever "color" filter is available in the FES that is active at the time of the observation. NO switching of FESes to get a particular color filter (V or R) is supported. NONE actually indicates a "clear" filter that passes the whole visible region. DEF indicates "use the default" which is whatever has been using in guiding (i.e., no filter switch).
A Final Word About Filling Out Target 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!
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 (see below).
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 SOMEWHERE IN THE SUBJECT LINE OF E-MAIL TO THIS ACCOUNT, which will help in proper tracking of your submission 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 Mission Planning Team who will get back to you as soon as possible. The official contacts for Guest Investigators are: B-G Andersson, FUSE GI Liaison Officer (e-mail: bg@pha.jhu.edu), and for moving targets Hal Weaver (e-mail: weaver@pha.jhu.edu).
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 ##
# ## ##
# #########################################
#
#
# 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-xxxx
pi_fax: 410-516-8260
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-xxxx
li_fax: 410-338-xxxx
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-xxxx
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 1 Information ##
# ## ##
# ############################
#
# Note: You should shorten or remove comments at right to avoid line
# wraps in you electronic submission. (Many "mailers" seem to do this,
# and it gives the Parser program problems!)
#
object_number: 1 # 1-99
object_name: CYG-LOOP-P1A # From Phase 1 when possible.
object_class: 75 # See Appendix B.
object_spec_req: # MOVE, TOO, NIGHT, HIRES
ra_j2000: 20:47:32.1 # e.g. 20:31:45.22
dec_j2000: +31:02:01.5 # e.g. +31:02:01.5
source_type: EE # PC, PE, EC, EE
lambda_ref: 1032. # e.g. 1032.
flux_lambda_ref: 1.2E-12 # e.g. 1.2E-12
eline_fwhm: 0.5 # in Angstroms, e.g. 0.5
sb_lambda_ref: 6.0E-14 # "flux" per sq. arcsec.
flux_950: # Equiv. Cont. Flux at 950 A
flux_1050: # Equiv. Cont. Flux at 1050 A
flux_1150: # Equiv. Cont. Flux at 1150 A
# Flux Format as above.
flux_accuracy: HIGH # HIGH, MED, LOW.
v_mag: # mag, e.g. 12.5
v_range: # mag range, e.g. 9.9-13.2
resolution_element: 0.1 # in Angstroms, e.g. 0.033.
expected_ct_rate: 55 # cts/s, pref. from ETC or sim.
sig_noise: 20 # per specified res. element.
spectral_type: # No spaces please.
color_excess: 0.08 # mag, e.g. 0.10.
red_shift: # Z format or km/s.
high_prop_motion: N # Y if you applied a PM
# correction to above coordinate.
object_prio: 1 # 1, 2, 3, or 4.
phase_zero: # Only for Ephem. targets.
phase_period: # Only for Ephem. targets.
# ###################################
# ## ##
# ## Obj 1 Obs 1 Information ##
# ## ##
# ###################################
#
#
observation_num: 1 # 1-99, or `1 to N' if MON.
obs_object_num: 1 # From Object listing
off_object_num: 2 # Offset Target Number
instrument_mode: TTAG # HIST, TTAG
aperture_req: HIRS # HIRS, MDRS, LWRS
obs_time_req: 8000 # sec per obs, e.g. 4000
# NOTE: "per obs." for MON.
obs_spec_req: ROLL, FESIMG # ROLL, SNAP, SAFTSNP, MON, EPHEM,
# HOLD, FPSPLIT, XOFF, SPATIAL,
# CONTIG, and/or FESIMG.
#If ROLL spec. req.
aperture_pa: 135. # angle in degrees, e.g. 135.0
pa_tolerance: 10. # angle in degrees, e.g. 10.0
# If MON spec. req.
mon_t_sep: # days, e.g. 21.00
mon_delta_tsep: # days, e.g. 2.50
# If EPHEM spec. req.
phase_desired: # e.g. 0.5
phase_delta: # e.g. 0.05
# If FESIMG spec. req.
targ_pos: IN # IN or OUT
fes_filter: NONE # ND, COL, NONE, or DEFault.
#-----------------------------------------------------------
# Next Object: Example OFFSET star Object listing. (Note: no
# "observation" fields required.)
# ############################
# ## ##
# ## Object 2 Information ##
# ## ##
# ############################
object_number: 2 # 1-99
object_name: CYG-LOOP-P1A-OFF # From Phase 1 when possible.
object_class: 21 # See Appendix B.
object_spec_req: # MOVE, TOO, NIGHT, HIRES
ra_j2000: 20:47:35.2 # e.g. 20:31:45.22
dec_j2000: +31:03:22.1 # e.g. +31:02:01.5
source_type: PC # PC, PE, EC, EE
lambda_ref: 1000. # e.g. 1032.
flux_lambda_ref: 5.5E-12 # e.g. 1.2E-12
eline_fwhm: # in Angstroms, e.g. 0.5
sb_lambda_ref: # "flux" per sq. arcsec.
flux_950: 1.1E-12 # Equiv. Cont. Flux at 950 A
flux_1050: 1.05E-12 # Equiv. Cont. Flux at 1050 A
flux_1150: 1.0E-12 # Equiv. Cont. Flux at 1150 A
# Flux format as above.
flux_accuracy: MED # HIGH, MED, LOW.
v_mag: 12.2 # mag, e.g. 12.5
v_range: # mag range, e.g. 9.9-13.2
resolution_element: # in Angstroms, e.g. 0.033.
expected_ct_rate: # cts/s, pref. from ETC or sim.
sig_noise: # per specified res. element.
spectral_type: B4V # No spaces please.
color_excess: # mag, e.g. 0.10.
red_shift: # Z format or km/s.
high_prop_motion: N # Y if you applied a PM
# correction to above coordinate.
object_prio: 4 # 1, 2, 3, or 4.
phase_zero: # Only for Ephem. targets.
phase_period: # Only for Ephem. targets.
# 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 # 1-99
object_name: NGC4151 # See separate document.
object_class: 84 # See Appendix B.
object_spec_req: # MOVE, TOO, NIGHT, HIRES
ra_j2000: 14:47:35.2 # e.g. 20:31:45.22
dec_j2000: -21:03:22.1 # e.g. +31:02:01.5
source_type: EC # PC, PE, EC, EE
lambda_ref: 1000. # e.g. 1032.
flux_lambda_ref: 3.0E-12 # e.g. 1.2E-12
eline_fwhm: # in Angstroms, e.g. 0.5
sb_lambda_ref: # "flux" per sq. arcsec.
flux_950: 1.0E-13 # Equiv. Cont. Flux at 950 A
flux_1050: 1.1E-13 # Equiv. Cont. Flux at 1050 A
flux_1150: 1.2E-13 # Equiv. Cont. Flux at 1150 A
# Flux format as above.
flux_accuracy: HIGH # HIGH, MED, LOW.
v_mag: 12.2 # mag, e.g. 12.5
v_range: # mag range, e.g. 9.9-13.2
resolution_element: 0.1 # in Angstroms, e.g. 0.033.
expected_ct_rate: 300 # cts/s, pref. from ETC or sim.
sig_noise: 10.0 # per specified res. element.
spectral_type: # No spaces please.
color_excess: 0.03 # mag, e.g. 0.10.
red_shift: 1100 # Z format or km/s.
high_prop_motion: N # Y if you applied a PM
# correction to above coordinate.
object_prio: 1 # 1, 2, 3, or 4.
phase_zero: # Only for Ephem. targets.
phase_period: # Only for Ephem. targets.
# ###################################
# ## ##
# ## Obj 3 Obs Information ##
# ## ##
# ###################################
#
#
# This sets up 9-2000 sec observations separated by 14 +/- 2 days.
observation_num: 2 TO 10 # 1-99, or `1 TO N' if MON.
obs_object_num: 3 # 1-99
off_object_num: # Offset target number, if needed.
instrument_mode: TTAG # HIST, TTAG
aperture_req: MDRS # HIRS, MDRS, LWRS
obs_time_req: 2000 # sec per obs, e.g. 4000
# NOTE: per obs. for MON.
obs_spec_req: MON # ROLL, SAFTSNP, SNAP, MON, EPHEM,
# HOLD, FPSPLIT, XOFF, SPATIAL,
# CONTIG, and/or FESIMG.
#If ROLL spec. req.
aperture_pa: # angle in degrees, e.g. 135.0
pa_tolerance: # angle in degrees, e.g. 10.0
# If MON spec. req.
mon_t_sep: 14.0 # days, e.g. 21.00
mon_delta_tsep: 2.0 # days, e.g. 2.50
# If EPHEM spec. req.
phase_desired: # e.g. 0.5
phase_delta: # e.g. 0.05
# If FESIMG spec. req.
targ_pos: # IN or OUT
fes_filter: # ND, COL, or NONE.
#-----------------------------------------------------------
# Next Object: Bright, stellar object requiring HIST observation.
# ############################
# ## ##
# ## Object 4 Information ##
# ## ##
# ############################
object_number: 4 # 1-99
object_name: HD13245 # From Phase 1 when possible.
object_class: 23 # See Appendix B.
object_spec_req: HIRES # MOVE, TOO, NIGHT, HIRES
ra_j2000: 06:53:10.2 # e.g. 20:31:45.22
dec_j2000: -02:42:37.6 # e.g. +31:02:01.5
source_type: PC # PC, PE, EC, EE
lambda_ref: 1000. # e.g. 1032.
flux_lambda_ref: 3.0E-11 # e.g. 1.2E-12
eline_fwhm: # in Angstroms, e.g. 0.5
sb_lambda_ref: # "flux" per sq. arcsec.
flux_950: 2.9E-11 # Equiv. Cont. Flux at 950 A
flux_1050: 3.1E-11 # Equiv. Cont. Flux at 1050 A
flux_1150: 3.3E-11 # Equiv. Cont. Flux at 1150 A
flux_accuracy: MED # HIGH, MED, LOW.
v_mag: 8.2 # mag, e.g. 12.5
v_range: # mag range, e.g. 9.9-13.2
resolution_element: 0.033 # in Angstroms, e.g. 0.033.
expected_ct_rate: 2830 # cts/s, pref. from ETC or sim.
sig_noise: 30.0 # per specified res. element.
spectral_type: B0II # No spaces please.
color_excess: 0.13 # mag, e.g. 0.10.
red_shift: # Z format or km/s.
high_prop_motion: N # Y if you applied a PM
# correction to above coordinate.
object_prio: 1 # 1, 2, 3, or 4.
phase_zero: # Only for Ephem. targets.
phase_period: # Only for Ephem. targets.
# ###################################
# ## ##
# ## Obj 4 Obs Information ##
# ## ##
# ###################################
#
#
observation_num: 11 # 1-99, or `1 TO N' if MON.
obs_object_num: 4 # 1-99
off_object_num: # Offset target number, if needed.
instrument_mode: HIST # HIST, TTAG
aperture_req: HIRS # HIRS, MDRS, LWRS
obs_time_req: 4000 # sec per obs, e.g. 4000
# NOTE: per obs. for MON.
obs_spec_req: FESIMG # ROLL, SNAP, SAFTSNP, MON, EPHEM,
# HOLD, FPSPLIT, XOFF, SPATIAL,
# CONTIG, and/or FESIMG.
#If ROLL spec. req.
aperture_pa: # angle in degrees, e.g. 135.0
pa_tolerance: # angle in degrees, e.g. 10.0
# If MON spec. req.
mon_t_sep: # days, e.g. 21.00
mon_delta_tsep: # days, e.g. 2.50
# If EPHEM spec. req.
phase_desired: # e.g. 0.5
phase_delta: # e.g. 0.05
# If FESIMG spec. req.
targ_pos: OUT # IN or OUT
fes_filter: COL # ND, COL, or NONE.
#-----------------------------------------------------------
#(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 1
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: Observations of less than 2000 seconds (including SAFTSNPs)
are computed at 2000 seconds.
This message occurs if you specify an observing time of less than 2000
seconds in the Phase 2 keyword obs_time_req. Because you
will be charged one full orbit (2000 seconds) for any short
observations (due to overheads), you should take this into account when comparing your
total observing time to your allocation.
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.)
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). We cannot guarantee that S/N > 30
will be available at full resolution in Cycle 1. Verify that your S/N calculation
is realistic and everything should be OK. 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 1734.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 >1200 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.
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 <2000 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.
Error: The object in this observation is too faint to be
peaked up in the HIRS aperture. You must either
specify an offset star or change to the MDRS aperture.
Object: 5 Observation: 6
What you should do: If the HIRS 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 MDRS.
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: 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: Should only occur for a severe typo in one of your
coordinates that drives it out of range. Fix the typo.
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.