To: FUSE Science Team (Co-Is, Program Leads, Other interested parties) From: Bill Blair Re: FUSE Phase 2 Re-submission Information Date: Apr. 2, 1998 Within the next day or so, everyone who has submitted a FUSE Cycle 1 Phase 2 proposal will receive a message from us regarding the status of each individual program. We ask that you review the requested changes carefully and revise your proposals for re-submission over the next couple of weeks. We realize this is not much time, but we need to wrap up Phase 2 PI team submissions prior to the GI proposal submission cycle, which begins in earnest in early May, so we really need your cooperation. /-----------------------------------------------------\ | PLEASE NOTE: Cycle 1 Phase 2 resubmission | | deadline is FRIDAY, April 17, 1998. | | | | IF YOU HAVEN'T SUBMITTED ANY PHASE 2 INFO YET, | | PLEASE CONSIDER THIS YOUR DEADLINE TO DO SO!! | \-----------------------------------------------------/ Below we provide an Addendum to the earlier Phase 2 Submission Instructions document. This Addendum contains important clarifications about some issues, and detailed discussion about the changes that are required for this resubmission. Please read it carefully, and refer to it if you have questions in making your revisions. If other issues arise, DO NOT SEND QUESTIONS TO THE PHASE 2 SUBMISSION ACCOUNTS!! Rather, direct questions to myself or to Alice Berman; wpb@pha.jhu.edu or aberman@pha.jhu.edu At the end of this e-mail are three appendices that can be used for quick reference: Appendix A: Checklist for Phase 2 Re-submissions Appendix B: Summary of New Special Requirements Appendix C: Phase 2 Re-submission Instructions --------------------------------------------------------------------------- FUSE PI Team Phase 2 Instructions Addendum William P. Blair Apr. 2, 1998 --------------------------------------------------------------------------- 1. Introduction There have been a number of changes and updates in FUSE development since the Phase 2 instructions were baselined (Dec. 5, 1997). This document clarifies several aspects of Phase 2 submissions that were uncertain at that time and discusses additional information needed for properly filling out the Phase 2 inputs for the PI team programs for Cycle 1. We will shortly be returning Phase 2 proposals to the PI team (with individual comments on each proposal) for revision. Please read the information below carefully and adjust your Phase 2 inputs as necessary prior to re-submission. 2. Program Co-Investigators and Data Rights First, a bit of terminology. A "program Co-I" is a person listed on a given submitted program as a Co-investigator. A "team Co-I (or FUSE associate)" will refer to one of the 23 official FUSE science team Co-I's or recognized team associates (Gry and Willis). The initial Phase 2 inputs raised some questions, since a number of names and collaborators showed up as program "Lead-Is" or "Co-Is" on these PI team programs for the first time. Let us clarify a few things for everyone involved: - The presence of a "Lead Investigator" makes that person the primary point of contact for the program. (We will include the PI on any mission planning related e-mail as a courtesy, but decision-making responsibility is delegated to the LI.) - The PI (or LI if there is one) will be the primary person with data rights during the proprietary period. This person will have responsibility to retrieve the data for that program from the archive and disseminate it to any Co-Is on the proposal who need it. (Different arrangements may be made for large projects and/or for official FUSE team Co-Is, pending on-going discussions, but this will apply to all medium and instrument/ops team programs.) Access to the archive for other Co-Is on the proposal will be granted only at the specific request of the PI or LI. - The last point makes this point possible: for each program, it is left to the discretion of that program's PI, in consultation with the rest of his/her team or working group, to list whomever they wish as Co-Is on the program. However, being listed as a program Co-I does NOT guarantee direct access to the archive and to the data for that program during the proprietary period. Data access for these people is through the program PI (or LI). We will support a policy where access for additional people TO A GIVEN PROGRAM'S DATA can be requested, but access to the entire PI data set will not be made available to program Co-Is. - Given that each of the "PI team" programs, including the medium size team projects and instrument/ops team programs, are all accounted out of the "PI team" pot of observing time, it is important that we have clear accountability. It is also important to have people who are directly involved and knowledgeable about the FUSE instrument and it's operation on each program. Toward that end, we REQUIRE at least one official team Co-I, FUSE associate, or directly involved Instrument/Ops Team member be listed on each program. By doing so, this person "sanctions" the program as belonging to the PI team and provides this measure of accountability. If your initial submission did not include at least one FUSE team Co-I or associate, as described above, please find one willing to be on your program and add them as a program Co-I. Please make any necessary adjustments to listed personnel based on these clarified guidelines prior to resubmission. 3. Bright Targets, Brightness Limits, and SAFTSNP Usage We have stated a "Brightness limit" of 1.0 E-10 ergs/cm^2-s-A 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 A resolution element and scales linearly with line width. THESE FLUX LIMITS STILL APPLY, but information on the real FUSE detectors allows us to be somewhat less stringent in our rules for when the SAFTSNP special requirement needs to be placed on a target. First let us clarify as much as possible the meaning of the "flux_accuracy" keyword in Phase 2, because the initial submissions were all over the map. - A HIGH flag should indicate that the supplied flux is expected to be accurate at the 30% level, including any expected source variability. - A MED flag should indicate that the fluxes supplied should be good to better than a factor of two. - A LOW flag should indicate predicted fluxes that could be in error by more than a factor of two. 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, etc. The SAFTSNP special requirement 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 want to get SAFTSNPs on all those targets for which they are required right up front in your Phase 2 submissions remove them from targets where they are NOT needed, and have you all do this in a way that is consistent across all programs. This requires that you pay attention to the following strategy for when SAFTSNPs are needed. We will apply the following criteria for assessing the need to take precautionary measures (SAFTSNPs) for the beginning of cycle 1: - Any targets with estimated fluxes above the brightness limit (either by your assessment or ours) should have a SAFTSNP observation specified and will be placed on "HOLD" until development of on-orbit procedures for observing bright sources. (HOLD is a new special requirement that either you or we can specify--see below.) - Targets with a HIGH flux accuracy but fluxes below the brightness limit may be observed without a SAFTSNP observation. - Targets with a MED flux accuracy with flux estimates within a factor of two of the brightness limit (i.e. flux anywhere in the FUSE range >5.0 E-11 ergs/cm^2-s-A or the equivalent) should specify a SAFTSNP observation. MED targets with peak fluxes below 5.0 E-11 do not require the SAFTSNPs. - Targets with a LOW flux accuracy and flux estimates within a factor of three of the brightness limit (i.e. flux anywhere in the FUSE range >3.3 E-11 ergs/cm^2-s-A or the equivalent) should specify a SAFTSNP observation. LOW targets with fluxes below 3.3 E-11 do not require the use of SAFTSNP, although in cases of extreme uncertainty, the user should still apply it if there is any issue about safety. (Include discussion in the feasibility text block.) Please note that, as with the SNAP special requirement, 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 on SAFTSNP observations because a default value will be inserted by FUSE MP at a later time. PLEASE FOLLOW THESE RULES FOR YOUR REVISED PHASE 2 SUBMISSIONS to ensure proper program accounting!!! All specified observations, including any SAFTSNPs at 2 ksec each, have to be less than or equal to your program's allocation. 4. Acquisitions Target acquisition strategies (including when and how to perform FUV peak-ups, offset star usage, etc.) have been substantially clarified since the original Phase 2 Instructions were released. First let us define some terminology for acquisition cases. These target acq. cases are provided primarily for your information: we do NOT require you to specify acq. cases in Phase 2. However, for any target for which you think if matters, you can use the below terminology in your Feasibility or Support Information text blocks to describe possible acquisition strategies and we will understand what you mean. Briefly, the different acquisition types are as follows: 1.FUV Peak-up: The standard acq. mode in cases where channel alignment and/or careful centering of the target in the slit are required. (Assumes target is bright enough in FUV for this to work.) 2.FES Target Acq: Target is sufficiently bright visually to be seen and centroided by the FES. Assumes no channel alignment is needed. 3.FES Target Acq plus FUV Peak-up: Target is sufficiently bright visually to be seen and centroided by the FES, and most of the positional uncertainty is removed by the FES Target Acq. Additionally, source is bright enough to permit a Peak-up (for optimum centering in the narrow slit, for instance). 4.FES Guide Star Acq: Target is too faint or diffuse to be centroided directly, but its position is well known with respect to the selected guide stars. FES acquires guide stars and assumes the target position is known. 5.Blind Offset from within FES FOV: Used in certain cases where a separate offset target is identified for use in the acquisition process. Offset targets of this type are expected to be very close to the target position, and certainly within the FES FOV. An FES Target Acq is done on the offset star, but then the "target" position is placed in the selected aperture. 6.Target to Slit: This refers to an acq mode whereby the target is positioned directly into an aperture with no further refinement in position. (To be used mainly with the LWRS aperture where target centering is not an issue.) 7.Bright Star Type 1: An acq mode whereby the ND filter must be in place to attenuate a very bright (V<2) target. However, once the target is in the slit, the ND is removed and guide stars are acquired. 8.Bright Star Type 2: An acq mode whereby the ND filter must be in place to attenuate a very bright (V<2) target, and remains in place during the observation, with guiding done on the spillover light from the slit. (This is a placeholder; it is uncertain whether this mode will actually work.) 9.Moving, Planet: Needed to acquire a moving target with accurately known position and trajectory. 10.Moving, Comet: Needed to acquire a moving target with accurate trajectory, but absolute position at time of observation is uncertain. AN IMPORTANT NOTE ABOUT OFFSET STARS: There are really two types of offset stars: those needed for FUV Peak-up (either target centering or channel alignment), and those needed in a situation like acq. case 5 above (an "optical" offset star in the FES FOV). This was not very clear in the original Phase 2 Instructions: ANY "OFFSET" STARS THAT YOU PUT IN THE PHASE 2 TARGET LISTINGS SHOULD BE THERE BECAUSE THEY ARE NEEDED FOR FUV PEAK-UP. The "other" kind of offset star (which is needed very infrequently) should simply be specified in the "Support Information" text block. PEAK-UP Assumptions and Usage: We have seen a number of inconsistencies on the initial Phase 2 submissions regarding the choice of aperture, the source fluxes, and/or the use of offset stars. In this section, we clarify when and where you should assume a peak-up is needed, what the flux levels should be for a successful peak-up, and when an offset star is really needed. We will not know everything we would like to about when Peak-ups are required until well into IOC. For instance, issues about the stability of the channel alignment with time or with thermal conditions, whether channel alignments or peak-ups are required in the MDRS, slit, etc., are things that cannot be specified with certainty at this time. Hence, for pre-mission purposes we need to make certain assumptions about when FUV Peak-ups might be needed. In addition, the flux limit stated previously for performing a peak-up, namely 2.0 E-14 ergs/cm^2-s-A, is probably too faint, and is certainly too simple-minded, to apply blindly for something as important as target acquisitions. Peak-ups are done in the individual channels, and to ensure a good peak-up we need to set the time to get a S/N=10 per step in the least sensitive channel. So for instance, using the on-line Count Rate Tool and inputting sources with the indicated "flat spectrum source", we see the following: Peakup dwell time to reach S/N=10 (in seconds)* Flux SiC1 SiC2 LiF1 LiF2 -------- ------ ------ ------ ------ 1.0E-14 743.27 760.30 170.29 197.56 2.0E-14 224.29 229.03 58.83 67.20 <--(Old stated limit.) 4.0E-14 75.31 76.74 22.84 25.70 <--(New limit to use.) 6.0E-14 42.02 42.76 13.76 15.38 (See below.) 8.0E-14 28.44 28.92 9.77 10.88 1.0E-13 21.28 21.63 7.56 8.39 5.0E-13 3.31 3.36 1.34 1.48 *Assumes flat spectrum source at indicated flux level, HIRS slit, a dark rate of 1.0 counts cm-2 s-1, and 10.00 kR of airglow (Ver. 1.2 of count rate tool). I make the following observations: - Our advertised limit of 2.0E-14 results in very long dwell times per step, such that it may not even be possible to complete a peak-up in a single orbit (depending on how many steps are used in the peak-up and how conservative we choose to be in padding the time on faint sources). - These estimates assume a flat spectrum source; many real stars people have nominally chosen as offset stars are dropping like stones into the FUV, and this needs to be taken into account. - The dwell time is a very steep function at the lowest allowed fluxes. - Finally, because of the last point, uncertainties in the fluxes at short wavelengths could potentially cause failures in the peak-ups in the SiC channels, which means that we should encourage people to "be conservative" (i.e. use brighter stars whenever possible and/or we may need to use longer dwell times than calculated for faint targets). We thus provide the following assumptions and guidelines for use in the revised Phase 2 submissions: 1. Assume peak-ups will be required, both for channel alignment and for target centering, whenever a point source is to be placed in the HIRS aperture. 2. Assume peak-ups will NOT be required for the MDRS aperture. If target centering in the MDRS is a concern to you, you CAN request a peak-up and/or supply an offset star (for faint sources), but you do not have to. 3. Assume peak-ups will never be required for the LWRS aperture. 4. Assume an average flux of across a given channel of 4.0E-14 ergs/cm^2-s-A to be the minimum required for a good peak-up source. This applies both to an object to be peaked-up on, or a supplied offset star. I note that you can check the peak-up dwell times yourself for any sources of interest using the on-line Count Rate Tool (Ver. 1.2); the dwell times are listed at the bottom of the output. Note that we are assuming that peak-ups are only needed for sources being placed in the narrow aperture (HIRS). If your source is too faint for a good peak-up and you really need the HIRS aperture for some reason, 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, or if you don't absolutely need the HIRS aperture, switch to the MDRS aperture. No offset star or peak-up should be necessary in MDRS. A WORD ABOUT APERTURE SELECTION: In the limit where the telescope PSF is as expected and the pointing jitter is at or near the specs (i.e. the situation we expect pre-mission), the resolution achieved through the MDRS aperture should be very nearly the same as through the HIRS aperture. (Best guess is at worst a 10% effect in resolution for the regions with the "best" performance, and less elsewhere.) Hence, I recommend the following: FOR FAINT TARGETS REQUIRING PEAK-UP ACQs OR OFFSET STARS IN HIRS, SELECT THE MDRS APERTURE INSTEAD (whenever resolution requirements allow). This will relieve the need for offset stars in many cases and also minimize the need for FUV peak-ups with uncomforatbly large dwell times! I was surprised by the number of people requesting HIRS, especially on faint sources (or sources dropping quickly into the FUV). Remember that the HIRS aperture is expected to miss about 35% of the flux from a point source, so your exposure times will be longer on faint sources. I realize this is another one of those "We won't know until we are on orbit" issues, but I recommend simplifying your life by assuming MDRS and "no offset star" whenever these assumptions are consistent with your science. If conditions on orbit are significantly different from what was advertised we will have to revisit these issues for everyone anyway. (This general issue pertains to the X-offset discussion below as well: Except for broader airglow lines, we expect relatively small impacts on the spectral resolution from placing a point source in the LWRS aperture, so long as pointing is stable and the PSF is good.) There are still good reasons to use the HIRS aperture in some cases. If you need to isolate your target from a nearby source, or if you have a bright source where the peak-up times are short and the light loss is not a problem, GO AHEAD. Just don't use it as a "default" on faint sources because you think you have to in order to get good resolution. 5. New Keywords for Handling Fixed Pattern Noise Mitigation (FPSPLIT, XOFF, YOFF) The Science team meeting in February raised our consciousness considerably about the possible general need for some form of Fixed Pattern Noise (FPN) mitigation techniques. Three techniques have been discussed: Focal Plane splits, X-offsets, and Y-offsets. These are briefly described below. - FP-splits involve the displacement of the 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 ease this problem. - X-offsets accomplish much of the same effect of FP-splits, but at a fraction of the operational complexity. X-offsets use the LWRS (30") aperture, and separate exposures are taken with the source positioned at different X-offset 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 bright sources). - Y-offsets would involve moving a target perpendicular to the dispersion, to different offsets within any of the three primary apertures. (This mode is included for completeness, but is expected to be much less effective at FPN mitigation over most of the spectral range because of the large Y-height of the spectrum due to astigmatism. You should NOT use this in Phase 2 at this time.) Please refer to a separate e-mail from Bill Oegerle, dated 3/31/98, for more detailed information. The need for FP-splits or X-offsets is, unfortunately, still somewhat subjective. Based on the presentation by Jerry Kriss at the team meeting in February, it seems that three of the four detector segments will readily provide S/N >= 30 WITHOUT ANY MITIGATION OF FPN, while the fourth segment may only provide 15-20 without "help." What we have decided to do is allow the user to specify one of three new Special Requirements at the "observation" level, that will tell us what you think should be done on a given observation. The three new special requirements (with hopefully obvious meanings) are: FPSLIT, XOFF, YOFF. (Again, YOFF is shown for completeness and should not be used in cycle 1.) Recall that XOFF implies the LWRS aperture to be set as well, and FPSPLIT will only be allowed for HIRS and MDRS apertures. As with other Phase 2 keywords, these new keywords allow you to tell us what you think is best for a given observation. We will do our best to comply, based on current conditions at the time of scheduling, but FUSE MP reserves the right to adjust as needed. Effectively, 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.) /------------------------------------------------------------------\ | Hence, you should NOT place FPSPLIT on all of your observations | | at this time just to "improve the data quality"!! | \------------------------------------------------------------------/ This will happen if it is feasible. Rather, use 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 stepsa step sizes, etc.), and so no further information is needed from the user in Phase 2. 6. Other Special Requirements Recent work on laboratory data indicates that the background could be about 2 times higher on the daylit side of the orbit than at night, mainly due to increased scattered light. This allows us to clarify the use of the NIGHT special requirement. Since you can set the background rates in the on-line tools, you should be able to assess the effects of this kind of an increased background rate on your faintest targets. Only use the NIGHT special requirement when it is necessary, because it will affect both the schedulability and on-orbit efficiency. New HOLD Special Requirement: A number of you requested that a particular target be placed on "HOLD" pending certain additional information. You now have the capability to specify this directly by using the new HOLD special requirement. For technical reasons, we ask that you specify this at the "observation" level even if it applies to a "target" in your Phase 2 input. You do NOT have to specify HOLD where it will be done automatically (i.e., the follow-up observations after a SNAP or SAFTSNP are automatically on HOLD until inspection of the initial SNAP or SAFTSNP). Also, FUSE MP can invoke the HOLD special requirement as needed on particular observations if needed. HOLDs on SNAP follow-up observations are only released upon feedback from the user, while HOLDs on SAFTSNP follow-ups need coordinated action and approval from BOTH the user and FUSE MP. 7. Target Priorities The Phase 2 submissions to date are coming with with about 2/3rds of the time designated Priority 1 and 1/3rd as priority 2. You may recall we were striving for about equal amounts of time in these two priority groups. This is NOT a big deal, and I realize there are situations and cases where it doesn't make sense to split hairs. In fairness to everyone I request that you review your priority assignments prior to re-submission and do your best to comply with the desired breakdown by priority. -------------------------------------------------------------------------- Appendix A: Checklist for Phase 2 Re-submissions 1. Review feasibility text to give full, clear explanations of flux estimates and extrapolations. 2. Review flux accuracies (target keyword `flux_accuracy') in accordance with new definitions in Section 2 and revise if necessary. 3. Review observations and flux estimates as to whether SAFTSNP obs are needed. Add or delete as necessary in accordance with rules in Section 3. Ensure total observing time remains equal to or below your program allocation. 4. Insert additional text in Support Info section regarding acquisition and/or offset star details (if necessary). 5. Review target fluxes with respect to science aperture used and need for peak-ups (Section 4). If flux is too low for peak-up, find an offset star or change to MDRS. 6. Review offset stars and their fluxes. If fluxes of offset stars are too low, find different offset stars or change science aperture to MDRS and remove offset star. 7. Review target priority assignments; strive for a balance between pri. 1 and pri. 2 (using approx. half of your allocation) unless special arrangements have been made otherwise. 8. Specify whether any observations require the FPSPLIT or XOFF special requirement and add where necessary (Refer to Section 5). Insert explanatory text in Special Requirements text section. 9. Indicate whether any targets need a HOLD special requirement. Add explanatory text to the Special Requirements text block. (Refer to Section 6.) 10. Re-assess need for NIGHT special requirement on the faintest targets. 11. Address any individual, program-specific queries that will be sent separately. -------------------------------------------------------------------------- Appendix B: Summary of New Special Requirements (All to be applied at the Observation Level; Use keyword `obs_spec_req:') obs_spec_req: HOLD # For observations of any target not yet # ready for scheduling. Examples: too bright, # needs ephemeris info, needs coordinated obs. # with another satellite, etc. obs_spec_req: FPSPLIT # Request FP-split sequence on an observation. obs_spec_req: XOFF # Request X-offset observation in 30 arcsec # aperture. Possible future use: obs_spec_req: YOFF # Request Y-offset observation in any of three # primary apertures. Also, note usage of SAFTSNP. Like SNAPs, SAFTSNPs are specified as separate observations from the "science" observation, viz. obs_spec_req: SAFTSNP obs_time_req: # Leave this blank; a default value will be used! -------------------------------------------------------------------------- Appendix C: Phase 2 Re-submission Instructions Procedures for Re-submission will exactly parallel your initial submissions. To assist you in the proper generation of your Phase 2 resubmissions, the two electronic submission accounts here at JHU are still 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 any syntax errors with your 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 help in proper tracking of your submission on our end. Within a day (any hopefully much less than a day in most cases) you will receive an e-mail containing an "error log" (from a run of our "parser" on your proposal), and a "formatted" ascii version of your proposal for your reference. Our checking program is being updated to include the changes discussed in the body of this Addendum, and will be available shortly. The formatted proposal is to allow you to more easily check the content of your target list and observation specifications. Text blocks will be shown in straight ascii text format at the beginning, but more importantly your keyword entries from the Phase 2 template will be shown in a 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. 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. /-----------------------------------------------------\ | DO NOT submit partial Phase 2 files just to beat the | | deadline!!!! We would rather receive COMPLETE | | Phase 2's late than receive partial Phase 2's | | on time!! As a reminder, the resubmission | | deadline is FRIDAY, April 17, 1998. | \-----------------------------------------------------/ If questions arise, DO NOT SEND QUESTIONS TO THE PHASE 2 SUBMISSION ACCOUNTS!! Rather, direct questions to Bill Blair or to Alice Berman; wpb@pha.jhu.edu or aberman@pha.jhu.edu ------------------------------------------------------------------------------