Plan of Record (February 2015) 15B

Plan of Record

Telescope Resources

VLA - Resources

• Update P-band (EVL-2866)
  • General and Shared Risk Observing – Wideband:
    • Should no longer be marked as Shared Risk.
    • Default setting:
      • Subband: "16x16 MHz (8-bit)"
      • Total Bandwidth (GHz): "256 MHz"
      • Baseband Centers (GHz): 232, 248, 264, 280, 296, 312, 328, 344, 360, 376, 392, 408, 424, 440, 456, 472 MHz.
  • General and Shared Risk Observing – Spectral Line: P-band should not be selectable from the Receiver list.

GBT - Resources

• VEGAS Pulsar and Continuum Modes (EVL-2835): Users selecting Pulsar or Continuum modes with VEGAS are allowed to use between 1-8 Spectrometers (currently only 1 is allowed). The mapping of beams to number of spectrometers should be the same for the pulsar and continuum mode as it is for the spectral line mode 1.

• GBT Resource Validation (EVL-2836): The GBT Spectrometer, SpectralProcessor, and Zpectromter back-ends are no longer available. Currently a user can copy an old proposal that includes these backends and submit the proposal. We need to trap this at validation.

• Remove Zpectrometer (EVL-2837): Remove Zpectrometer backend from the GBT resource list in the PST.

• Add JPL Radar backend (EVL-2838). Add a new GBT back-end called "JPL Radar backend". So we will now have two radar backends. The JPL Radar backend will be a copy of the current radar backend. Below is the checkbox text for the new JPL Radar backend and an update for the text for the old Radar backend.
  • JPL Radar backend checkbox text: "I understand how to use this back end, and that the GBT staff will not provide any support in the use of this back end. I have permission to use this back end from Martin Slade at JPL."
  • Radar backend checkbox text: "I understand how to use this back end, and that the GBT staff will not provide any support in the use of this back end. I have permission to use this back end from Jean-Luc Margot at UCLA."

VLBA - Resources

• VLBA Resource Validation (EVL-2839): We get false validation errors when there are some true errors. When true errors are fixed the false errors disappear.

• VLBA HSA Efflelsberg Changes (EVL-2883): When selecting the HSA station "EB" make the following changes:
  • DDC System with 4 basebands: move from Shared Risk to General Observing.
  • DDC System with 8 basebands: move from RSRO to Shared Risk Observing.

GMVA - Resources

Technical Justification:

• Update VLA Technical Justification (EVL-2867):
  • For text box 1, add “radio” before “telescopes”. Add the url https://science.nrao.edu/facilities/vla/doc/manuals/oss/performance/comb-conf-mosaicing.
  • For item 2, remove the text “and note whether the proposed observations will be combined with other VLA configurations or other telescopes (list which configurations or telescopes)”, and remove the url https://science.nrao.edu/facilities/vla/doc/manuals/oss/performance/comb-conf-mosaicing.

Misc.

• Triggered Proposal Cues (EVL-2840): Add the following cue for Triggered proposals on the General page: "Required response window, with units:".

• Abstract Count (EVL-2841): We check the word count in two places: (1) on the General Page; and (2) during validation. It appears that we are using third party software on the client and server (Javascript and Java, respectively) and they are doing the counting differently. We want this to be consistent.

• Remove Legacy ID (EVL-2848): It would be nice to get rid of all mention of the Legacy IDs for VLA (VLBA still re quires them). By remove we mean to not show it on the cover page for everything except VLBA, GMVA, and VLBI.

• Automate min/max LST Calculation (EVL-2849): It would be nice to automate the min/max LST calculation, given sources in a session. It may not be possible in all cases, but we should do what we can.

• Technical Justification vs Session Constraints (EVL-2850): On the Sessions page a user can add info about session constraints. But this info is now being put on the Technical Justification page. Change title from "Constraints" to "Scheduling Constraints".

• Update PST Manual (EVL-2847): Use Plone.

• Remove Copied Screen Shots (EVL-2868): Old screenshots (exposure calculator or GOST) should be disallowed when a proposal is copied.

Reviews

• Improve Technical Review Import/Export File (EVL-2843): Two improvements:
  1. The proposal order in the exported file should be the same as in the UI.
  2. Format the cues such that each cue is on a separate line.
• TAC Meeting Page and Conflicts (EVL-2906): Change the behavior of conflicts on the TAC page. Currently, TAC members with only institutional conflicts (aka soft conflicts) can view the proposal but not the review info. We want to change this so TAC members with soft conflicts can see everything that other TAC members can see, including the review info.
• Technical Review Cues (EVL-2907): Change the default cue response of "ok" to "x" (ToneyMinter will provide the text).
• SRP Consensus Cue (EVL-2908): Add the default cue response "None" to the SRP consensus cue concerning technical considerations.

Current JIRA Backlog

• EVL-2003 PST: show 'version' somewhere
• EVL-2600 PST: User changing affiliation results in bad data state
• EVL-2202 PST: Print Preview Error
• EVL-2467 PST: Print Preview/PDF Format
• EVL-2576 PST: VLA Configurations in Review Cycles: add "Any"
• EVL-1986 PST: "/nrao-2.0" in the code
• EVL-2089 PST: sources imported from the PST have wrong coordinates
• EVL-2560 Update addressCountry table in PST
• EVL-2537 Pulsar support in PST, OPT, and model2script
• EVL-2200 PST: Problems uploading large source lists
• EVL-2123 PST: Import Modified Sessions from PHT to PST
• EVL-2025 PST: Duplicate Proposal Identifiers
• EVL-2561 Expand addressCountry table in PST
• EVL-1987 PST: we need a MOTD function
• EVL-2584 PST: Re-write the Sessions section
• EVL-2616 PST: deleting an attached file in Technical Justification loses changes in other boxes
• EVL-2624 PST: split GBT resource report into two reports
• EVL-2646 PST: Investigate enhanced format for Release Notes and update releast notes
• EVL-1988 PST: tomcat 'guessed user' feature
• EVL-2811 PST: problems changing passwords on webtest
• EVL-2814 PST: Issues with Review Tabs
• EVL-2815 PST: getScienceReviewerFromUser can return wrong reviewer cycle

Current JIRA Long Term

• EVL-2702 PST: Related Proposals
• EVL-2703 PST: Improve Emails
• EVL-2698 PST: Verify Image File Type for Attached Images
• EVL-2699 PST: Calculate and Display Data Rate/Volume
• EVL-2700 PST: Technical Justification Examples
• EVL-2701 PST: Snapshot Proposals
• EVL-2009 PST: make it build with maven
• EVL-1858 PST: import sessions from text file into PST
• EVL-2446 PST: Add Student Support Data to the PST from External Tools
• EVL-2428 PST: GBT Resource Validation
• EVL-2115 PST: DDT/EPO
• EVL-2433 PST: Add Spectral Lines
• EVL-1861 PST: PST doesn't use groups properly
• EVL-2431 PST: Adding Users to Projects
• EVL-2432 PST: Joint Proposals
• EVL-2430 PST: DDT Proposals and Resources
• EVL-2244 PST: change password field confusion
• EVL-1989 PST: old bug reporting system
• EVL-2020 PST: backend, frontend, expiration date

Added to JIRA Long Term

• Overhaul Permission Systems (EVL-2842). There are problems in dealing with the review pages because of the permission system. For example, old reviewers can see view current proposals.
• Sponsored Proposal and Science Category (EVL-2844): When we move into the assigning reviews cycle all sponsored proposals get a assigned a scientific category. This causes confusion when vetting the scientific categories.
• Proposal Changes during Review (EVL-2845). When we are in the Accepting Reviews phase the PST handles changes in reviewers. That is, reviewers can be added or removed and the PST deals with this (most of the time) okay. We want to add two new requirements when in Accepting Reviews:
  1. Allow a PST-admin to add or remove a proposal from the review process.
  2. Allow a PST-admin to change a science category.
• Proposal Submission Constraints (EVL-2846): Regular, Large, and Triggered proposals are typically considered only after the call for proposals (CfP) until the deadline, but users may submit them at any time. This is rare but can cause problems since the resources selected may not be available for the requested semester and the updated PST software is not in place until after the CfP. Therefore it may be useful to allow users to craft a proposal at anytime but not allow them to submit the proposal unless it is within the CfP period. Must allow DDT and Sponsored proposals. We need to allow a CfP date in the review cycles.
• Re-submit Feature (EVL-2851): "It would be greatly preferable to have a 'resubmit' feature that allows submission without prior withdrawal and proposal ID reassignment. Reasons: 1. Multiple e-mails to all Co-Is can be irritating. 2. It is not possible to mark all of the related proposals because their proposal IDs will change after submission. So for joint proposals, they cannot be indicated as linked. 3. Simple convenience - especially close to the deadline, traffic increases, so anything that requires a long series of interactions with the web service becomes more challenging."
• Import/Export Resources (EVL-2852) "I've been trying to configure my VEGAS setup, and originally had 6 spectrometers active, then I realized I needed a 7th (to target RRLs at higher resolution). Changing from 6 to 7 spectrometers erased all of the information in the cells. Re-filling the cells is tedious and error-prone; either VEGAS configurations should be savable to disk (which would be very helpful for sharing with colleagues!) or at least they should not be erased when making small changes. I mention this specifically for VEGAS, but of course it should apply to all spectral configuration tools for EVLA and GBT, and I imagine would have to given that they all exist within the same framework of the OPT."
• External Proposal Import (EVL-2853): How best to import external proposal data? Currently this is done with the PST UI manually. BarryClark suggested that we use an XML standard that can be edited and imported into the PST. Software would be written to take whatever format the external organization provides (e.g., excel, csv) and ports this to our XML standard. The XML file can be edited if necessary and then imported into the PST.

Documentation Updates

• Add descriptive examples of providing sensitivity from science goals.
• Update GBT Resources (new radar backend)