Notes for February 2010
- Should we demand that if an affiliation, email, etc. is input that at least one of them is the default?
Proposed Changes to the Proposal Submission Tool (DanaBalser)
Currently the proposal submission tool (PST) produces a list of source groups, resource groups (or resources), and sessions that are associated with a source group/resource group pair. A source group consists of one or more sources while a resource group consists of one or more resource. About 40% of users do not specify source/resource/session information properly. That is, they have inconsistencies in their proposal that prevents a schedule from being generated directly. Clearly we need the user to perform this task with some quality control on NRAO's part. This can either be done properly in the PST or later on with some other software. Here we consider a model that minimizes the work done in the PST.
Below we list the different pages:
The current General Information page should suffice
The current Author page of the PST should suffice.
Text including figures, tables, and references that provide scientific justification for the proposal. Currently the scientific justification includes a technical justification that is not always easy to separate from the document. This information would be split off into a separate section (see below).
The current Source page, including the current upgrades, should suffice.
A list of resources that includes all the available receivers (e.g., L-band) and backends (e.g., Spectromter, WIDAR, etc.). For example, this could be a checkbox list of items that the user selects. This list should be configurable by each site. The main purpose for this page is to associate the relevant hardware that will be used with the proposal.
A short paragraph that describes the technical details. This must
include the following (examples are for the GBT):
- Observing modes (e.g., position switching).
- Backend modes (e.g., Spectrometer with 8 spectral windows x 2 polarizations; 50 MHz bandwidth, 9-level sampling).
- Integration times (e.g., Total time (ON+OFF) of 10 hrs assuming an rms = 12 mK; Tsys=30 K, velocity resolution = 1 km/s at 9 GHz; and assumed weather plus observing mode and backend mode from above).
- Estimate of overhead times (e.g., 20% overhead for pointing, calibration, and slew time).
- List of LST range, receiver, frequency range, and time, along with any constraints (see Table). This information is primarily for the PSC.
In the past there have been many problems with the technical justification with information being incorrect or incomplete (at least this is true for the GBT proposals). The current PST has this information spread out in several sections (scientific justification, resources page, sessions page). By putting this information in one place it should help the technical referees. The main problem is in assessing the integration times. A good sensitivity calculator could provide 1-4.
For the PSC we require at least an estimate of how the proposed observing time will be distributed in LST and frequency (and in some cases by receiver). Currently the sources/resources/sessions provides this information but the specific details of the observing need not be determined at the proposal stage. Software to help the user produce the above table might improve the accuracy of this information. For example, BarryClark
has suggest a program to take the source list to generate such a table.