Plan of Record (February 2014)
Plan of Record
VLA - Resources
- VLA Configurations (EVL-2427) : insert validation check that only proposals that have some resources requesting VLA configurations that will exist for the upcoming semester will pass validation unless the PI is a graduate student. Resolved:19/Dec/13 3:09 PM
- VLA L-band Default Frequencies (EVL-2469): use the following default frequencies: 1264 and 1776 MHz. Resolved:25/Nov/13 10:37 AM
GBT - Resources
- Spectral Processor: remove from resources.
- Spectrometer: remove from resources.
- VEGAS Updates. (EVL-2471) Resolved:09/Jan/14 10:21 AM
- VEGAS will be a normal backend - it will no longer be shared-risk.
- Updates to the VEGAS modes.
- Change the equation to calculate data rates to: Data rate (MB/sec) = (C * E * 16) / tint / (1024 * 1024), where C and E refer to the columns in the table and tint is the integration time specified by the user.
- Data rates faster than 32 MB/sec should not be allowed. If a user tries to save a VEGAS resource where one or more spectrometers have data rates higher than this threshold a pop up message should say:
"You have requested a data rate greater than 32 MB/sec for at least
one VEGAS spectrometer. The current implementation of VEGAS does
not allow any data rate faster then 32 MB/sec. Please consider
increasing your integration time or choosing a different spectrometer
mode in order to decrease your required data rate."
VLBA - Resources
GMVA - Resources
- Add the GBT to the GMVA Resources (EVL-2449): Add the GBT as a telescope station to the GMVA resources. Currently you have to include it in the textbox list with other instruments. Resolved:22/Nov/13 11:31 AM
- GMVA Constraints (EVL-2465): Disallow the requirement that at least one European station be selected if 7mm Rx is selected. Resolved:04/Dec/13 9:42 AM
- Session RMS Noise Field (EVL-2466): remove RMS Noise (mJy/beam) field in VLA and VLBA sessions.. Resolved:15/Jan/14 1:12 PM
- Technical Justification (EVL-2472): Resolved:19/Dec/13 3:09 PM
- Updates: add text to existing sections and add new sections for the VLA, VLBA, GMVA. Examples have been attached to the JIRA ticket.
- Print Preview/PDF Format (EVL-2467): some changes with the format This will require upgrading JasperReports
- Exposure calculator screen shot should be at the end of the technical justification not the end of the proposal.
- Fix the gap that exists between resources since we have added VEGAS.
- Sponsored Proposals (EVL-2450): Resolved:21/Nov/13 12:41 PM
- On the General Page add a field called "Sponsored Proposal" after the Proposal Type. Add a menu list with choices of "None" (the default) or "WVU". If a users selects "WVU" then the Proposal Type must be either Regular or DDT (this should be checked when saving the General Page). When WVU is selected this defines the proposal as a WVU Sponsored Proposal.
- Sponsored proposals will behave in the same way as other Regular and DDT NRAO proposals with the following exceptions.
- "Regular" sponsored proposals do not have to be submitted at the normal proposal deadline, but they should be submitted no later than one month before the TAC meeting covering the semester to which the proposals belong.
- Sponsored Proposals should be hidden from the Review Process. They should not appear on the My Reviews, Reviews Summary, Panel Reviews, or TAC Meeting pages.
- Below are the original comments from ToneyMinter.
Sponsored proposals will behave like regular NRAO proposals with the
1) The proposals do not have to be submitted at the normal proposal
2) "Regular" sponsored proposals should be submitted no later than one
month before the TAC meeting covering the semester to which the
3) The Science Review Panels and the Telescope Allocation Committee
will not be able to know about or view the proposals. This is to keep
these committees from biasing any "open skies" proposals that may have
been submitted by a PI on a sponsored proposal.
4) The sponsored proposal will be assigned to group A.
Any PI from an institution that has an agreement for sponsored
proposal time may designate the proposal as a sponsored proposal.
This is to be done in the PST at the time the proposal is written. A
field in the PST then marks this as a sponsored proposal and also
indicates which sponsor institution is involved.
The proposal is hidden from view for members of the Science Review Panels
and the Telescope Allocation Committee within the PST.
The sponsored proposals will be checked for source conflicts. A
conflict between a new sponsored proposal and an accepted and running
open skies proposal will result in the sponsored proposal's source
being denied. A conflict between a new sponsored proposal and a new
open skies proposal will result in the open skies proposal's source
The proposal is put in group A in the PHT. It is hidden from view in
the PHT during the TAC meeting. The allocated time for the sponsored
proposals shows up in carry-over/pre-allocated time in the LST
When the disposition letters are sent out for the open skies proposals
the title and abstract of the sponsored proposals will become public.
After the normal 12 month proprietary period the sponsored proposal's
data will become publicly available in the NRAO archive.
- Import all External Proposals into the PST (EVL-2429): We typically receive several externally reviewed proposals (e.g., FERMI, CHANDRA) for the GBT, VLA, and VLBA. We want to include these in the PST as we used to do for the global mm VLBI proposals. Resolved: 28/Jan/14 8:06 AM
- Only a PST Admin can create external proposals.
- We need one external proposal per telescope (e.g., GBT, VLA, or VLBA).
- Proposal Pages. We require all of the pages that are currently included in a normal GBT, VLA, or VLBA proposal (e.g, General, Authors, etc.) to exist for these external proposals.
- Proposal ID. For external proposals the Proposal ID should be an input field on the General page located before the title. The PST admin will input the proposal id as "XTEL/<complete external proposal identifier>" where X is for external and TEL is either GBT, VLA, or VLBA. The external proposal identifier is the code used by the external organization. This will include Chandra, Fermi, Hubble, etc.
- Total Time. For normal proposals the total time is calculated from the Session page. For external proposals create a new Total Time parameter and add an input field on the General page located after the Proposal ID.
- Scientific Justification. For external proposals there should be no page limits when uploading the scientific justification.
- Legacy Code. All proposals will have a Legacy Code "XBnnn", where B is the first letter of the PI's last name (e.g., Balser) and nnn is a number starting at 100 incremented so that Bnnn is unique; nnn in XCnnn (e.g., for PI Clark) will be a separate series. (This is a modification/extension of the Legacy Codes presently used for Global VLBI, e.g., GK47.) These legacy codes should be generated automatically, but a PST admin should be able to modify the code. This is necessary in some cases since the observing codes that are used are determined externally.
- Validation. When the PST admin submits the external proposal the validation code should only check that the initial input (see below) has been included.
- Procedures. It is desirable to include all external proposals (both accepted and rejected), but this will require significant effort. We anticipate two stages of input. An initial (minimum) input and a subsequent input. For all proposals we require only the initial input, whereas for accepted proposals we desire the additional information.
- Initial Input
- General Page
- Proposal ID (new input field)
- Total Time (new input field)
- Author's Page
- Scientific Justification
- Upload entire proposal (no page restriction)
- Subsequent Input
- Authors other than the PI
- Scientific category
- Resources and Sessions as appropriate for the telescope.
- DDT Proposals and Resources (EVL-2430): Most proposals are submitted, reviewed, and scheduled within the two semester time frame. Users are expected to use the PST for submitting such proposals for a given semesters between the call for proposals and the deadline (e.g., 8 July 2013 and 1 August 2013). The exception are DDT proposals. Since DDT proposals can be submitted at any time the resources that are available in the PST might not be valid. For example, the PST is currently setup for 14A resources from the 14A-CfP to 14B-CfP. But the resources available change with the semester endpoints. Historically we have dealt with this by having exceptions in the code when the DDT proposal type is selected. For example, if GBT W-band is a new receiver being offered in 14A but does not exist in 13B then this receiver is removed from the list for DDT proposals that are submitted before the deadline. But recently more significant changes in resources has occurred between semesters making this more difficult to program. We should discuss how to proceed. Muddle through expecting things to settle down; have multiple versions of the PST; incorporate the semester more directly into the PST; etc. Future Sprint: LongTerm
- Sort Column and Filter Settings (EVL-2468): The PST should remember the sort column and filter settings when leaving pages and logging out. This includes the following pages: My Proposals, Proposal Lists, My Reviews, Panel Reviews, and TAC Reviews. For example, if a user sorts in descending order on the proposal column and selects the VLA in the Telescope filter then these setting should be remembered. (See EVL-2355) There are two exceptions:
- When a new proposal is created the filters for the My Proposal page should be set to their default value of ALL, and the page should be in Edit mode for the proposal that was just created.
- When review pages are created during a new cycle (My Reviews, Panel Reviews, and TAC Reviews) the Filters and any check boxes should be set to their default values (ALL and not checked). Resolved: 19/Nov/13 11:28 AM
- Highlight Old Draft Proposals (EVL-2434): When old draft proposals are used for either DDT or Regular proposals they often cause problems since some components (especially resources) are sometimes no longer valid. So when the proposal is submitted there are problems. We want to highlight old drafts so the user knows that the draft should not be used. The date that defines a proposal is old should be when we make major changes that are released on the call for proposals. Resolved:16/Dec/13 5:32 PM
- Export the Approved hours/Disposition from the PHT to the PST (EVL-2447): After the director's review there should be a telescope-specific method to export the approved hours and the disposition from the PHT to the PST. Resolved:18/Oct/13 1:59 PM
- Print Dissertation Plan by Default (EVL-2553): When generating a pdf of a proposal where a dialog box is used to include items to print, select the Dissertation Plan by default for any reviews pages. Resolved:07/Jan/14 11:18 AM
- Resize Textboxes on the Panel Review Page (EVL-2554): In edit mode textboxes can be re-sized, but they are fixed in view mode. Make the PI & TAC Comments textbox a little larger and make the TAC Only Comments textbox a little smaller in the view mode. Resolved: 13/Feb/14 1:29 PM
- VLA Multi-configuation Flag (EVL-2555): Add the text "VLA Multi-config." to the Proposal Code column for the My Reviews, Panel Reviews, and TAC Meeting pages if the VLA proposal in question is requesting more than one array configuration. Resolved:09/Jan/14 10:27 AM
- Add Functionality to the Panels Review Page (EVL-2556): Add an export button called "Export Review Info". When this button is clicked an ASCII file will be produced with two lists. Each list will have the following column heading: Rank, Score, Proposal ID, Time, PI, and Title. The first list is a rank order list of all proposals in the SRP. The second list is a rand order list of the conflicts for each reviewer. Will be done on FY14-03
- LInks: update
- General Page:
- Add sponsored proposals.
- Changes to joint proposals.
- Remove Spectrometer and Spectral Processor
- Changes to VEGAS?
- External Tools
- Update GBT mapping planner
- Remove Spectral Advisor
- Comments from User Group Members: Need JIRA
- Include examples in the documentation.
- Are there limits to the amount of text that can be included?
- Session constraints versus Technical Justification info.
- Snapshot Proposals: The goal is to add a new type of DDT proposal called Snapshot. Current plan is to perform this manually for 14B for the GBT and see how things go. There may be significant PST work in the future but these requirements are TBD. Need JIRA
- GBT Resource Validation (EVL-2428): Requirements under development. Use the scheme from the GBT sensitivity calculator to provide more accurate and consistent resource validation. This requires additional effort from the GB staff to understand the mapping between the PST and Sensitivity Calculator. Future Sprint: LongTerm
- VLBA Resource Validation (EVL-2264): the method/logic of determining what different HSA stations can do has never been exactly right. (From deadline to deadline we have improved this.) We would like to implement a method which we think might be easier to program and to account for late-time changes. A matrix (table) from an external file with entries which define what is possible for each HSA station could be read and compared to full implementation at that station. Then the availability of that station with those parameters could be determined. If the logic/method were already coded, then a change would only be necessary to the file to update capabilities at that station. The table has entries for each station along with whether the PFB and/or the DDC modes are available, and, for the DDC, what the maximum number of subbands (IF channels) are, and the minimum and maxium bandwidths per subband. See example below. Future Sprint: LongTerm
- DDT/EPO (EVL-2115): Requirements under development. Add a new proposal category EPO for DDT proposals. We need to flesh out the requirements. For example, does the user make this decision or does NRAO? Future Sprint: LongTerm
- Import Sessions (EVL-1858): Add the capability of importing sessions the way that sources are imported. This is a bit tricky since Sessions depend on sources and resources. Also, the GBT behaves differently than does the VLA/VLBA/HSA. Future Sprint: LongTerm
- Joint Proposals (EVL-2432): Requirements under development. Currently proposing for joint proposals requires the user submit a separate proposal for each telescope. The only indication that the proposal is joint is the selection of a radio button. Ideally we want the user to be able to submit a single proposal. Future Sprint: LongTerm
- Student Support Page (EVL-2446): Last cycle we removed the SOS page from the PST to the Student Observing Support Submission Tool (SOSST). There also exist a Student Observing Support Query Tool (SOSQT) that is used by NRAO to process SOS data. There are some additional items that we delayed until this cycle. Future Sprint: LongTerm
- Interaction between PST and SOSQT
- SOSQT will query PST:
- Input: project ID and student name
- Output: proposal (PDF); thesis plan (PDF); linearized rank score (e.g., 0.38); priority (e.g., A); total requested time; total accepted time.
- SOSQT will push the following info back into the PST
- Submitted SOS information: SOS PI name; related awards (PDF); MIsc. expenses (student travel and computer hardware); student name; student monetary support; and student assignment.
- Accepted SOS information: SOS accepted (yes/no); accepted Misc. expenses (student travel and computer hardware); accepted student monetary support.
- Develop a mechanism for this action. Maybe a button that is pushed after the SOS meeting is completed.
- Potential Issues:
- Currently there are no plans to authenticate. Is this okay?
- Do we need to use global ID's for individuals?
- How does the SOSST/SOSQT fit into our collection of tools (PST, OPT, DSS, etc.) vis-a-vis maintenance, support, etc.
- Remove Print Preview Page: Do we need the print preview page? Will the PDF file suffice? The Print Preview page often has problems when odd characters are used. It would be useful to count how often this page is visited to gauge usage. Need JIRA
- Spectral Lines (EVL-2433): It would be useful to include spectral lines of interest for spectroscopy projects. Future Sprint: LongTerm
- Adding Users to Projects (EVL-2431): A variety of tools require access to the NRAO user database and may use the Central Authentication System (CAS) to authenticate a user. The starting point for most users is the proposal submission tool (PST). Once submitted, however, proposal information is read only. If accepted this proposal turns into a project whereby time is allocated on one or more NRAO telescopes. Any user that is part of the proposal is now also part of the project and will have access to a variety of tools (OPT, DSS, AAT, etc.) But projects may evolve whereby additional people may be added to the project. For example, a new graduate student may be added by one of the authors. This new person now requires access to the project that will include the proposal, data, observing preparation (OPT), scheduling (DSS), etc. Since submitted proposals are sacrosanct we need another mechanism to allow additional people to be added to projects. Future Sprint: LongTerm
- Add a field called "addedAuthors" to the proposal database that initially is blank but can be modified by the PI of the proposal. This should not change any proposal information but allow this new user access to view the proposal and have CAS authentication associated with this proposal.
- Related Proposals: There is a field on the General page called "Related Proposals" that should be modified. The title should be "Is this a Previously Submitted Proposal?". There should be two radio button: Yes and No (default). If Yes is selected then a menu should list all the user's proposals (by id) and only one should be allowed to be selected. When the General page is saved the selected proposal id should be shown. Need JIRA
- Technical Justification Examples: It would be useful to produce technical justification examples for users to view. Maybe put this in the PST documentation. Need JIRA
- Technical Justification: Modify UI such that reviewers are prompted for input. Need JIRA
- Improve UI for registration: Move to WDG Change the structure of inputs to be linear (not two column) using the following order: User Preferences, General Information, Email Addresses, Phone Numbers, Addresses, and Organizations & Affiliations. For Organizations & Affiliations allow the user two ways to find the organization: by search (the current method), and by direct selection (e.g., drop down menu). The method of direct selection should list the organizations by city in alphabetical order and list: city, country, organization name (e.g, see http://www.kitp.ucsb.edu/conference-reg-info). Both methods must have a mechanism where the user can select "Organization not listed" and a way to send us their institution info (as we currently do for the search method).
- Improve UI for adding institutions (EVL-2117): Move to WDG The interface for adding new institutions is clumsy and needs to be made more internally consistent. For example, it is not clear when adding the initial information actually creates a database entry.
- Mechanism to Handle DDT proposals: There is a tool that currently performs this function. Provide a UI method (button) so that a DDT proposal can be marked as public when it has been reviewed and selected for observing. Operationally we need to define a mechanism so that this happens routinely. We agreed this would happen on the PHT side and then be exported to PST.