Plan of Record (February 2013)



Plan of Record

Resources

VLA

  • Incorporate GOST and RCT into PST: Requirements Document
  • Minor Items: TBD by 1 Nov 2012.
    • sub-arrays?
    • phased array (this will not be offered this cycle).

GBT

  • Resource Changes:
    • MUSTANG: Change the Receiver name from "MUSTANG(90GHz)" to "MUSTANG-1.5". (The value in the PST table and the value "sent" to the GBPHT should remain the same - only change the label seen in the resources.) Also when this receiver is selected please change the text to
      • "MUSTANG-1.5 is a bolometer array with 64 feedhorn-coupled bolometer detectors operating with a 25 GHz bandwidth centered on 87.5 GHz. MUSTANG-1.5 is expected to be considerably more sensitive than MUSTANG and have a larger field of view. For Semester 2013B it will be operated in a shared risk mode. Please contact Brian Mason (bmason@nrao.edu) for more details and collaboration information."

VLBA

Misc.

  • Student Support Page: Instead of using the PST to apply for student observing support we want to use an external tool, which is currently used by ALMA, called 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. The requirements are listed below. There are two approaches: Plan A is the full set of requirements and Plan B includes the minimum requirements for this cycle.
    • Plan A (full requirements)
      1. Changes in the PST
        • Remove the SOS page and functionality but maintain the database fields for future use.
        • Confirm that both old and new proposals print properly after these changes.
        • The Student Support Page should not be copied when using the PST copy feature.
        • Remove validation info message about SOS proposals.
        • Update the documentation (we need to point to the current SOS page for details).
      2. Call for proposals and disposition emails
        • Include a short note in the call for proposals that SOS proposals are no longer submitted in the PST but are submitted in an external tool after the TAC meeting.
        • Include a short note in the disposition letter for only those proposals that are accepted and have PI's or CO-I's and a student who is attending an U.S. institution that they can apply for student observing support.
      3. 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.
    • Plan B (minimum requirements)
      1. Changes in the PST
        • Remove the SOS page and functionality but maintain the database fields for future use.
        • Confirm that both old and new proposals print properly after these changes.
        • The Student Support Page should not be copied when using the PST copy feature.
        • Remove validation info message about SOS proposals.
        • Update the documentation (we need to point to the current SOS page for details).
      2. Call for proposals and disposition emails
        • Include a short note in the call for proposals that SOS proposals are no longer submitted in the PST but are submitted in an external tool after the TAC meeting.
        • Include a short note in the disposition letter to all proposers that if your proposal was accepted (A,B, or C) and it includes PI's or CO-I's and a student who is attending an U.S. institution that they can apply for student observing support.
      3. Interaction between PST and SOSQT
        • None. Users will have to input/upload all information as they currently do for ALMA.
    • Potential Issues:
      1. Currently there are no plans to authenticate. Is this okay?
      2. Do we need to use global ID's for individuals?
      3. How does the SOSST/SOSQT fit into our collection of tools (PST, OPT, DSS, etc.) vis-a-vis maintenance, support, etc.

  • Source Lists:
    • Update Documentation: Each proposal must now provide a complete source list. Lists may include candidate sources for observation. The proposers should say how they will select from such a list at obs prep time. Lists may include calibrators, which must be suitably flagged as such. For VLBA proposals involving phase referencing, we will urge proposers to include their phase calibrators. We need to change the documentation to reflect these changes.
    • Add Calibration Flag: We need to add a flag (true/false) to indicate if the source is a calibrator. This requires a change in the UI and in the import/export format.
    • Call for Proposals: We need to made these changes clear in the call for proposals.

  • Triggered Proposals: Add infrastructure to incorporate user text that provides information about triggered proposals. This is the so-called "Triggering Criteria". Here are the details from JoanWrobel:
Validation:

If no text beyond the cues is entered, the proposal should fail
validation.

----------------------------------------------
Cues:

Target type (eg, SN Ibc):

Origin of trigger (eg, IAUC):

Trigger event description (eg, D < 50 Mpc):

Semester(s) and number of events (eg, 13B, 3):

----------------------------------------------
Documentation:

Target type. For example, Crab, SN Ia, LMXBs, short hard GRBs.

Origin of trigger, either a telescope or a publication. For example, Swift 
or IAU Circulars.

Trigger event description. Some obvious examples are a flux density or 
magnitude threshold, a distance threshold or a region of sky.

Semester(s) and number of events. State the semester(s) over which the 
proposal is to be active, as well as the expected number of events during 
the active semester(s).

Make sure that the session constraints state, for each trigger, the 
required response window, plus the number and separation of any followup 
observations.

  • Proposal Author Info: Currently, when a user creates a proposal and adds authors only part of the author profile data is included in the proposal database. Since author profiles evolve in time we wish to capture the entire profile when the author is added and store this information in the proposal database. N.B., Ashish is currently working on this item.

  • DDT/EPO: 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? TBD by 1 Nov 2012.

  • Registration: When selecting an affiliation two buttons are presented. One is "default" and the other is unlabeled, and the latter is the one that is important. We should discuss if we want to redesign this interface, but at the very least we should clean up this issue. We should also look at the interface that allows users to get a new password as there are issues with email address.

  • Adding Institutions: 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.

  • Institutions: We need to make sure all users have a default institution. It would be straightforward to crawl the database to find users that have no default institution. If such a user has only a single institution, what to do is easy - just make that institution their default. If they have more than one (or none), we need to decide what to do.

Reviews

  • Conflicts: Currently on the My Reviews page the instructions for science reviews part (c) say: "they are a former student or advisor of the reviewer". Please change this to: "they are a recent (< 5 years) student or advisor of the reviewer"
  • Proposal Counter for TAC Page:When looking at the proposal summary on the TAC page it would be useful to list the number of proposals displayed.
  • NRAO-vetted Science Category: On the Review Page the individual science reviews have a title that includes the proposer-suggested science category. Instead, they should be labelled with the NRAO-vetted science category. For example, see VLA/13A-461.
  • Finalize Reviews Button: It would be useful to add a button that would allow a reviewer to automatically "complete" all reviews so they do not have to perform this manually (about 5 clicks per proposal). This action should do a sanity check on the reviews and let the user know of incomplete reviews before the review is deemed "complete". We should add this functionality on both the My Reviews page and the Panel Reviews page. TAC Meeting page?
  • Import Modified Sessions from PHT to PST: Currently sessions are modified in the PHT and include the total allocated time by the TAC. We want to import this information back into the PST. This would allow users to see how the TAC has modified their proposal and allow metrics tools to easily determine the proposed versus allocated time.

Documentation Updates

  • Call for Proposals:
    • New policy on source list for VLA/VLBA.
    • New format for source list import/export that includes a calibration flag.
    • Setup time must now be included for the GBT in HSA proposals.
  • PST in-line:
    • New policy on source list for VLA/VLBA.
    • New format for source list import/export that includes a calibration flag.
    • Setup time must now be included for the GBT in HSA proposals. (Should we add this?)
    • PST Release Notes.
  • Help TeX File:
    • New policy on source list for VLA/VLBA.
    • New format for source list import/export that includes a calibration flag.
    • VLA Resource section update.
    • VLBA Resource section update.
    • GBT Resource section update.
    • Student Observing Support update.
    • General Page update (Triggered Proposals).
    • Setup time must now be included for the GBT in HSA proposals.

Background Tasks

  • Resource Validation: A scheme from the GBT sensitivity calculator is used 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.

  • Global mm VLBI (GMVA) Proposals: Add GMVA proposals into the PST.

  • External Proposals: We typically receive several externally reviewed proposals (e.g., FERMI, CHANDRA). It is very useful to include these proposals in the PST. There is currently a method that is used to import global VLBI proposals.
    • We require a tool (if it does not currently exist) that allows a PST admin. to import all such external proposals.
    • For global VLBI proposals in the PST we do not include the total time, resources, or sessions. It would be useful to include this information.
    • We should retain the native ID for external proposals and abbreviated forms should be available for observing.

  • Spectral Lines: It would be useful to include spectral lines of interest for spectroscopy projects.

  • Import Sessions: 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.

  • Adding Users to Projects: 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.
    • 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.

-- DanaBalser - 2012-08-17

Topic attachments
I Attachment Action Size DateSorted ascending Who Comment
vla.resources.pdfpdf vla.resources.pdf manage 33 K 2012-10-30 - 15:30 DanaBalser VLA Resources V1
vlba.redo.pdfpdf vlba.redo.pdf manage 33 K 2012-12-04 - 16:01 DanaBalser Modifications to VLBA resources
vlba.resources.pdfpdf vlba.resources.pdf manage 37 K 2012-12-04 - 16:01 DanaBalser VLBA Resources
This topic: Software > ProposalSubmissionTool > PSTPoRFeb2013
Topic revision: 2012-12-20, DanaBalser
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback