RPS - Remote Proposal Submission E-Mail Server Service, SAO General Description The RPS E-mail Service provides a facility for submitting Observation Request forms. It is an automated server that provides form verification, LaTeX output, and electronic submission. NOTE: Electronic submission of proposals is required. MISSIONS -------- The missions which are supported by Chandra are: CHANDRA - observation requests for the NRA cycle CHANDRA_RFO_NRA - request to observe a TOO approved at the CXC Peer Review CHANDRA_RFO_DDT - new out-of_cycle TOOs/Director's Discretionary Time CHANDRA_BUDGET - Chandra cost proposals Chandra Targets of Opportunity: ------------------------------- There are two types of TOOs: 1) CHANDRA_RFO_NRA: CXC Peer-reviewed TOOs Peer-reviewed TOOs are TOO proposals that were submitted and accepted as a result of the Chandra Call for Proposals (CfP). Since their scientific objectives have already been approved, we require only confirmation of a few details, a brief restatement of the scientific objectives (this because the probability is high that TOOs will get someone out of bed who does not happen to have your proposal on his/her bed table), along with a justification of the particular TOO "trigger". If the target details have not been specified, the user must supply the appropriate values (RA, Dec, instrument settings, etc.). The TOO observer is encouraged to use the 'Remarks' box to report any changes in observing instructions, any special observing instructions, instrument parameters, or other alerts that will aid in obtaining a successful observation. To submit an RFO (Request for Observation) of this type, please use the Peer-reviewed TOO version of RPS: . 2) CHANDRA_RFO_DDT: Chandra Director's Discretionary Time Modeled on the HST approach, up to 5% of the total Chandra observing time will be reserved for CXC Director's Discretionary Time (DDT) observations. This allocation of time shall include unanticipated, non-peer reviewed TOOs. For this option, set . Proposals for DDT should be confined to unique scientific opportunities for which the scientific return might be compromised by waiting to propose during the next Chandra Call for Proposals(CFP). Proposals which could reasonably go through the peer review process generally will not be favorably received. The request will be assessed by the CXC director in consultation with the NASA Project Scientist. A modest proprietary period (of up to 3 months) may be granted by the CXC Director on request. Funding may also be provided for such observations if deemed necessary to facilitate maximal scientific return, following a simple, ad-hoc review which will include NASA representatives. Chandra Budget Request ---------------------- RPS provides a facility for filling the Chandra Cost Proposal forms. Electronic submission of the cost proposal form is required. For this option, use . Section 1. INSTRUCTIONS ------------------------ All messages for the RPS E-mail server must be sent to: rps@head.cfa.harvard.edu Any questions or comments about RPS should be sent to: cxchelp@head.cfa.harvard.edu The E-mail server parses the incoming e-mail based on a very limited set of commands. The required command keywords are and (the server is not case-sensitive). The most commonly used command keywords, in addition to and , are and , where the value of 'x' is supplied by the user. The section below is a specific set of instructions to carry out the tasks most commonly required during the proposal process. The subsequent section lists the complete command syntax. The user should peruse section 2, in particular the use of the keyword. In all of the examples below, Chandra is specified for the project name. Section 1: Instructions to carry out specific tasks a. Blank Forms - Users may request an ASCII file (a blank form) containing "name:value" entries. Users may use any editor to supply the necessary values for the listed entries. To receive a blank form, send the following message to the server at the address listed above. Save the blank form to a file for editing. b. Help Documentation - Users may request an ASCII text file containing short descriptions of all of the fields in the proposal forms. To obtain this document, send the following message to the server. c. Form Verification - After the user enters all of the necessary values into the form, s/he can E-mail this file to the server for verification. Verification will identify required fields with missing values and incorrect values (declinations larger than 90 degrees, for example). The form will be sent back to the user indicating any errors detected. All error messages are preceded with a ^ to make it easier for users to search for them. To verify the form, e-mail the completed form to the server. The following commands should be at the top of the form. The following command should be at the end of the form. NOTE: On unix systems, one of the easiest ways to mail your form is to use the following command: > mail rps@head.cfa.harvard.edu < your_filename d. LaTeX Generation - For good quality output, the user can mail the form to the server with the LaTeX option specified. The E-mail server will return a LaTeX file that the user can process and print on their home machine. To obtain the LaTeX file, the following lines should be at the top of the completed form. Then send the form to the server. The following command should be at the end of the form. NOTE: If you would like to obtain a blank LaTeX form, insert the above lines at the top of a blank form and send it to the server. The other approach to obtaining blank LaTeX forms is to send the following commands to the server (no need to place them above a blank ASCII form): e. Electronic Submission - Once the user has verified the form, corrected any errors, and is pleased with the results, the user should submit the form to the mission's proposal database. The user should use the SUBMIT option. The SUBMIT option will perform a final verification (as a safety check). If no errors are found, the form will be e-mailed to the appropriate database address for that project. If errors were detected, the form is returned with the errors flagged. To submit, the following lines should be at the top of the completed form. Then send the form to the server. The following command should be at the end of the form. f. Electronic Submission of scientific or budget justifcation : After successful submission, the user is returned the LaTeX output to be processed to create the PDF file of the RPS form. This file should be saved for future reference. The science justification must be electronically submitted either using the UPLOAD function on the RPS WWW version or by using the following FTP procedures. 1. File naming conventions for Proposal PDF files. nnnnnnnn_flast_sj.pdf or nnnnnnnn_flast_color_sj.pdf where: nnnnnnnn = 8 digit proposal number f = initial of first name last = last name color = Optional! Use only if color figures are included in the science justification. sj = science justifcation (bj for budget justification) 2. FTP Example: >ftp cxc.harvard.edu Name: anonymous Password: ftp> cd /pub/rps ftp> bin ftp> put ftp> quit Note: Users will not be able to see what they have submitted through the FTP port. The permissions have been set so that the anonymous user can only "put" a file. Users do not have permission to overwrite existing files. If you have made an error that you discovered after submission, you can re-submit *PROVIDED* that you use a new name and that you contact the User Support Group through the HelpDesk link on the main Chandra WWW page (http://cxc.harvard.edu) or through email at cxchelp@cfa.harvard.edu . If you use LaTeX for your PDF scientific justification, we suggest you create a PDF file in one of two ways. 1) Use a latex installation which allows you to create PDF files directly from the .tex file (e.g. pdftex). Some installations of pdftex do not allow you to include postscript figures. In this case you might use method (2). 2) Use ps2pdf (preferably version 1.4) to convert a postscript file to PDF. latex file.tex dvips -Ppdf -G0 -o file.ps file.dvi ps2pdf14 file.ps file.pdf We suggest one of these methods because most proposal reviewers will be reading your Scientific Justification on a computer screen using a PDF viewer. By default, a document produced with LaTeX uses so-called cm fonts, which differ significantly from any of the standard Type1 fonts built-in to PDF. PDF uses low-resolution bitmap images of these fonts to display the document. It prints well, but shows degraded resolution on the screen. Section 2: RPS E-mail Syntax -------------------------------- The server uses a simple syntax of keywords and name-value pairs. Below is a description of the RPS server keywords. Beginning of message. The remainder of the mail message is processed until is found or end of mail message file is reached. This key word is always required. Specifies the project name. If this is the only line in the mail message, an empty form for the specified project will be returned. Otherwise, the contents of the mail message will be processed as the actual form. Specifies the option. Valid option keywords are HELP, LATEX, SUBMIT, and VERIFY. HELP option will return the help documentation for the specified project, LATEX option will return the specified form in LaTeX format, SUBMIT option will verify and submit the specified form, and VERIFY option will verify the specified form. VERIFY option is the default. Specifies the echo mode. If ON is specified, both user input and processed results are returned. Otherwise, only the processed results are returned. OFF is the default. Allows the user to specify any comments for their own use. It is useful for tracking multiple versions of a proposal. Comment fields are ignored by the verification system. Specifies the beginning of the cover portion of the form. Subsequent lines are processed as the cover. Specifies the beginning of the target portion of the form. Subsequent lines are processed as the target. Multiple targets may be specified by beginning each target with this keyword. End of message. The remainder of the mail message if any is ignored. This key word is always required.