Plan of Record (August 2014)

Plan of Record

Telescope Resources

VLA - Resources

  • VLA WIDAR/ECSO Backend (EVL-2690): Remove from drop-down selection of VLA Backend "VLA WIDAR/ECSO". Check that previously submitted proposals are not effected and that copying old proposals with this resource are trapped.

  • VLA Wideband Backend (EVL-2690): In some cases the Baseband/Total Bandwidth are incorrect. For example, look at VLA-14B-053, VLA-14B-115, and VLA-14B-228. The Basebands/Total Bandwdith reads 3x2 GHz (3-bit) with total bandwidth of 8 GHz. But it should read 4x2 GHz (3-bit) with total bandwidth of 8 GHz.

GBT - Resources

  • VEGAS backend (EVL-2692):
    • Currently you can edit all fields to create any bogus VEGAS setup you desire. Once you select a mode you should only be able to enter rest frequencies and integration times.

  • Add ARGUS Receiver (EVL-2693):
    • Use "ARGUS (75--116 GHz)" as the receiver name.
    • Only VEGAS and DCR backends should be listed when ARGUS is selected.
    • Add the following text and check box when ARGUS is selected: "I have pre-approval from the instrument PI to use ARGUS, and I understand that the GBT staff does not provide any support for this instrument. " If the check box is not clicked then a popup message should appear with the following text (just like for the Zpectrometer): "Please check if you have pre-approval from the instrument PI to use ARGUS."
    • With VEGAS there are four different beam selections. Selections 1-3 will behave just like the KFPA (except the validation of frequencies will be different; that is, any frequency must be between 75 and 116 GHz).
      1. One beam with up to 4 VEGAS spectrometers. The user can select either 1, 2, 3, or 4 spectrometers. If more than one spectrometer is selected then the user can input different frequency sets for each spectrometer.
      2. Two beams with up to 4 VEGAS spectrometers per beam. The user can select either 2, 4, 6, or 8 spectrometers. The spectrometers are paired so the user can only input 1, 2, 3, or 4 different frequency sets.
      3. Four beams with up to 2 VEGAS spectrometers per beam. The user can select either 4 or 8 spectrometers. The spectrometers are in groups of 4 so the user can only input 1 or 2 different frequency sets.
      4. 16 beams with 1 VEGAS spectrometer for each beam. The user can only select 8 spectrometers and input 1 frequency set. There are 8 VEGAS spectrometers supporting dual polarization, so 16 channels in total. With ARGUS, 8 of channels will be hard-wired, while the other 8 could be configurable as done currently in the system.

VLBA - Resources

  • VLBA Resources: use table to constrain options (EVL-2264): Start work on using a table to define the various constraints to VLBA resources. This will not be completed this semester.

  • Update VLBA resources to include Shared Risk observing mode, and change Eb and VL requirements (EVL-2706):
I.   Change Standard Observing Mode so that we have:
          Standard/Shared Risk
          VLBA RSRO
II. Then, when HSA is selected:
         1.   If PFB System is selected
             a.   If VLA-27 is selected; there should be a pop-up and it should
                 say "Selecting PFB with Y27 means the proposal is RSRO; please
                 select 'VLBA RSRO' under 'Observing Mode' and specify in comment
                 field".   Do not leave VLA-Y27 marked as selected.

Modify this to:
a. If VLA-27 is selected: there should be a pop-up and it should
say "Selecting PFB with Y27 means the proposal is Shared Risk".
Leave VLA-Y27 marked as selected. Name of Resource should have

"Shared Risk" appended and Observing Mode in the pdf or print
preview should be marked "Shared Risk".

         2.   If DDC System is selected, and 4 baseband channels are selected
             a.   Allow Eb to be selected; there should be a   pop-up and it should 
                 say "Selecting DDC-4 with Eb means the proposal is Shared Risk"
                 Leave Eb selected.   Name of resource should have "Shared Risk" appended
                 and Observing Mode in the pdf or print preview should be marked "Shared Risk". 
             b.   Ar should still not be allowed to be selected.   The current popup 
                 when Ar selection is tried is still ok.
         3.   If   DDC System is selected and 8 baseband channels are selected
             a.   If either Eb or VLA-Y27 is selected; there should be a pop-up and it should say
                 "Selecting DDC-8 with Eb or Y27   means the proposal is RSRO; please
                 select 'VLBA RSRO' under 'Observing Mode' and specify in comment
                 field".   Do not leave Eb or VLA-Y27 marked as selected. 

Modify this to:
a. If Eb is selected: there should be a pop-up and it should say "Selecting

DDC-8 with Eb means the proposal is RSRO; please select 'VLBA RSRO' under
'Observing Mode' and specify in comment field". Do not leave Eb marked as

b. If VLA-Y27 is selected: there should be a pop-up and it should say

"Selecting DDC-8 with Y27 means the proposal is Shared Risk". Leave VLA-Y27
as selected. Name of Resource should have "Shared Risk" appended and
Observing Mode in the pdf or print preview should be marked "Shared Risk".

         4.   Sometimes when HSA is selected and something is changed on on the 
             "Observing Parameters" column, things don't get reset.   An example is:
               Set DDC System, with 4 channels, select HSA.   GBT and VLA-Y27 are checked.
               Now change Bandwidth to 64 MHz and Baseband Channels to 8.   No messages
               are given, yet VLA-27 remains checked (which is incorrect; see 3a above).
             Another example is;
               Set DDC System, with 4 channels, set bandwidth to 8 MHz.   Select HSA.
               VLA-Y27 gets selected, but if VLA-Y27 and anything smaller than 16 MHz
               should give the pop-up "Bandwidth less than 16 MHz with VLA-Y27 is strongly 
               discouraged, and is shared risk."   The name of the Resources gets changed,
               "Shared Risk" gets appended, which is good, but Observing Mode in pdf or
               Print Preview is still Standard, which is not.            
             Probably if *anything* is changed on the Observing Parameters page, HSA
             should be unmarked (unmarking any stations for the HSA).   This is the normal
             action when Observing System is changed from DDC to PFB or vice-versa.
III. Let's make the Y1 selection like everything else, if possible.   Right now if one
      is looking at Observing Mode "Standard", Y1 is greyed out, i.e. it cannot be 
      selected.   Let's:
         1.   Make the Y1 box selectable.   If Observing Mode is Standard/Shared Risk, there
             should be a pop-up which says "Selecting Y1 means the proposal is RSRO; please
             select 'VLBA RSRO' under 'Observing Mode' and then Y1 is selectable"   Do not
             leave Y1 as selected.
  • VLBA Calculation/Warning Checks (EVL-2694):
    • If the bandwidth per spectral channel is > 0.5 MHz (Bandwidth/number of spectral points/BBC) raise a pop-up warning. Do not validate.
    • If the output data rate (how to calculate is coming) is > 10 MB/s, raise a pop-up warning.

GMVA - Resources

Technical Justification

  • Technical Justification page can be edited for submitted proposals (screen shots) (EVL-2613): When a user submits a proposal the "save" button on the technical justification page disappears so the user cannot make changes (similar to other pages). But you can modify the Exposure Calculator screen shots. So we need to also remove or disable all upload and delete buttons as well.

  • Updates to Technical Justification Page (EVL-2695):

---> VLA

o Add a new textbox with text: 
Are the data to be combined with those from other configurations or telescopes, if so, please specify:

o Separate the Sensitivity/Integration time question into two questions (as we had before ? we will have to help divide text, etc.) 
Give the sensitivity required to achieve the science goal; include frequency or velocity width assumed.

Give the required on-source integration time to achieve the required
sensitivity, and total time including overhead; include considerations
such as source confusion in compact configurations, RFI in the
geostationary satellite belt, self-noise for strong sources; if the
overhead assumed is different from that given by the exposure
calculator, please explain:

Please upload exposure calculator graphic(s). Multiple files should be
uploaded if there are multiple resources. Use the "Save" button on the
tool to save a pdf file which can then be uploaded using the
browse/upload buttons to the right.

o Need to add more/better text for the imaging question, to make proposers think about what they actually need to do. We will provide the text.
Use this space to tell the technical reviewer what imaging problems you
might expect to see, due, e.g. to wide fractional bandwidths, ionosphere, nearby
strong sources, complex source structure, etc.  Please also let us know how
you plan to ameliorate these imaging problems.  This might include using
particular kinds of software and computing resources, either at NRAO or
your home institiution.  Other information that might be useful to the reviewer
are whether the target can be self-calibrated, whether or not the images will
be dynamic range limited, etc.

o In Data Volume question, add text for user to provide total volume based on Total Time (not On-Source Time) (and per Resource if possible). We can provide specific text.
Note correlator dump time, data rate, and total volume of all raw data
expected (not just the on-source fraction); for data rates in excess
of 25 MB/s, please provide additional justification for why this data
rate is required (for simple experiments, the data rates are
calculated for each correlator setup in the GOST tool and for
wide-band observations, the PST gives the rate when a Resource is set

---> VLBA
o Separate the Sensitivity/Integration time question into two questions (as we had before ? we will have to help divide text, etc.)
Sensitivity required to achieve the science goal.  Include frequency or 
velocity width assumed, for non-imaging experiments, justify the baseline 

Required on-source integration time to achieve the required sensitivity, and 
total time including overhead; include considerations such as uv-coverage 
needed for precision imaging, recording rate, etc., and assume the minimum 
acceptable number of stations in calculating the required integration time; 
please also verify that the time request on the cover page is consistent with 
that specified here:

Please upload exposure calculator graphic(s). Multiple files should be uploaded 
if there are multiple resources. Use your favorite utility (e.g., xv or gimp 
[linux]; grab or Command+Shift+4 [Mac]) to make a png file of the EVN exposure 
calculator graphic which can then be uploaded using the browse/upload buttons 
to the right.

o Give stronger/extra text on justification of requested bit rate.
Requested recording bit rate text:
Clearly justify the requested recording bit date.  Note that stating the bit 
rate is needed for sensitivity is not sufficient, since bit rate can be traded 
for length of observation (i.e., you can halve the bit rate and double the time 
on source for the same sensitivity).

o New textbox with a question on flux calibration ? i.e. how well is flux calibration needed ? Will provide text.
Flux calibration:
How accurate does your flux calibration need to be?  Specify extra calibration 
steps to be taken, beyond the a priori flux calibration, if very precise flux 
calibration need is needed.

--->  GBT.
o  New textbox with text: 
Date and times of any fixed time observations (e.g. superior conjunction, perihelion, closest approach to Earth, etc.)


  • Print Preview/PDF Format (EVL-2467):
    • 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 for the GBT since we have added VEGAS.
    • If possible, move calculator images to after the cover sheet; also make them print from “Print Preview” (both VLA and VLBA).
    • Others (Claire)?

  • Modify the Print All Functionality (EVL-2696). A “Print All” makes a monolithic pdf file. A one file per proposal option should be implemented.

  • Disposition Letters (EVL-2697): Disposition letters are now stored in the PST and may be viewed on the My Proposals page but not the Proposal List page. But PST admins would like to see these thus we need to make the disposition letters visible on the Proposal List page.


Discuss on 10 July 2014.

  • Joint/Sponsored Proposal Updates for Review Pages (EVL-2782): Make sure the addition of Swift (Joint) and SHAO/NYCAD/Other (sponsored) behave properly during the review process. The new joint proposal should be included for the pages that list info or filter on joint proposals. The sponsored proposals should not be included in the review process (other than to determine the amount of total time available or source conflicts.

  • Technical Review Page Modification (EVL-2785): The technical reviewer has a textbox to insert their technical review. Add cues to this textbox. Currently there are tags associated for each textbox which are displayed on the pdf file. Use the text for these tags as the cues. This will make it easy to compare the cues with the technical information in the pdf. Add "Okay" as default text after each cue. Here is an example for the VLA:

Combined Telescopes: okay

Array Configuration: okay

Scheduling Restrictions: okay

Receivers Requested: okay

Correlator Setup: okay

Mosaic Requirements: okay

Sensitivity: okay

Integration Time: okay

Dump Time: okay

Imaging Considerations: okay

Polarimetric Considerations: okay

RFI Considerations: okay

Other: okay

  • View Previous Semesters in Review Pages (EVL-2783): It is often necessary to view information from previous review cycles. For example, look at old Panel Review pages. Currently only the current semester is available. This should probably be restricted to PST admins.

  • Printing Options in the Review Pages (EVL-2784): In the Panel Reviews and TAC Meeting page there is a icon to print the proposal. Please add the following two options:
    1. Print a proposal that excludes the source lists.
    2. Print source list at one per line, with only name, ra, dec.

  • Modify the Print All Functionality (EVL-2696): A “Print All” makes a monolithic pdf file. A one file per proposal option should be implemented. The print all functionality is on the Proposal List and My Reviews Page.

Documentation Updates

  • General Page.
    • DONE Update Sponsored Proposals section.
    • DONE Define all of the observing types. Define "OTF Mapping".
  • Authors.
    • DONE Better information about updating author info, especially when copying a proposal.
    • DONE Emphasize that thesis plan should be kept up-to-date. It is important in the SRP discussion.
  • Resource Page.
    • DONE Update VLA
    • DONE Update VLBA
    • DONE Update GBT (No changes necessary.)
  • Technical Justification.
    • DONE Stress in the PST and Technical Justification that proposers should be thorough, detailed, and clear, despite typing text into little boxes. Note that LaTex should not be used here.
  • Sessions page.
    • DONE Update section 2.3.7 to make it clear that sessions here are used to help schedule and prioritize the telescope. See text in the CfP.
    • DONE The info about LST ranges on the sessions page is not consistent with documentation. Note that for scheduling purposes it is assumed that the LST range is used uniformly.

Long Term

  • External Proposal Import. Needs Discussion. 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.

  • Proposal Submission Constraints. Needs Discussion. 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.

  • Calculate and Display Data Rate/Volume (EVL-2699). Calculate Data Rate/Volume, and put (at least) Volume on cover sheet in top right-hand-side box (for multiple Resources, the total Volume is the sum of volumes for all Resources. Possibly could also be reported in Session Source/Resource Pair table.). For Resources that require GOST, currently the user would have to take the data rate calculated by GOST and input it into the PST (somewhere).

  • Verify Image File Type for Attached Images (EVL-2698). For attached images (GOST or VLA or EVN exposure calculator) we need to verify the image file type, and raise a flag to users when the length of attached image is zero (this can cause problems with creating a pdf of the entire proposal).

  • Technical Justification Examples (EVL-2700): It would be useful to produce technical justification examples for users to view. Maybe put this in the PST documentation.

  • Snapshot Proposals (EVL-2701): Requirements under development. 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.

  • 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.

  • 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?

  • 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.

  • 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.

  • 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.
    • Interaction between PST and SOSQT
      1. 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.
      2. 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:
      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.

  • Spectral Lines (EVL-2433): It would be useful to include spectral lines of interest for spectroscopy projects.

  • 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.
    • 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 (EVL-2702): 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.

  • Flag Test Emails (EVL-2703): It would be good to flag emails that are generated by webtest. For example, include in the subject line that this has been generated by webtest.

  • Author Reordering Issue (EVL-2796): The ”up/down” options on the Author's page only move an author one step at a time, which can be extremely tedious in long lists of authors. (Also, manually entering large author lists can be cumbersome to do manually.)

  • Sponsored Proposal and Science Category: Needs discussion. 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. 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.

  • Improve Technical Review Import/Export File: 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.

Long Term Items from Soccoro:

  • It would be nice to get rid of all mention of the Legacy IDs for VLA (VLBA still requires them).
  • We need to think about plonifying the PST “Manual”. What are the implications of, for example, in-line Help ? Should we re-institute fly-over help in the PST? Can you search in Plone? One very useful thing about a pdf is the ability to search the entire document. Of course one can search the web page after putting things in Plone, or at least Firefox can.
  • It would be nice to have the most recent proposals listed on top in the PST, rather than the oldest, in the left-hand panel tree view (i.e. default sorting to be newest to oldest). The default order is to sort alphabetically by prop id. This was requested by our reviewers to be consistent with some of the review pages (which are fixed). The user can, of course, change the default by clicking the various column headers. The new order should persist except when a new proposal is created in which case the order is by descending creation date so that the newly created proposal will be visible and on top. This was requested by several users. OK; this was a request by a user.
  • We really need to fix sessions. Users are confused by the relationship between sources, resources, and sessions. See
  • 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.

User Comments and Suggestions

  • Comments from User Group Members on the Technical Justification Page:
    • Include examples in the documentation.
    • Are there limits to the amount of text that can be included?
    • Session constraints versus Technical Justification info.

  • Comments from Helpdesk:
    • Re-submit feature. "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. "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."

-- DanaBalser - 2014-03-27
Topic revision: r37 - 2014-08-19, 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