Plan of Record (August 2013)



Plan of Record

Telescope Resources

VLA - General Page

  • Subarrays: Subarrays are currently handled under Sessions. We would like to modify the way subarrays are handled. The subarray mechanism is currently a bit convoluted, and we will simplify it. If proposers plan to use subarrays for any part of their proposal, they should simply mark a checkbox labeled "Subarrays". It seems that the best place to put this checkbox would be under Observing Type(s) on the General Page. In addition, we need to remove the subarray-specific information from VLA Sessions, in order to abate user confusion. There are two items that need to be removed: 1) an "Add Subarray" button, and a "Subarray" column. Programmer's note: Work is minor - of order 1 day, and about 50% done, but there is a complication on supporting past proposals. What do we do when somebody tries to view an old proposal, which has this in the Session, now? Or, when an old proposal is copied and then edited. We need requirements for these two. (dsb: subarrays should be shown in sessions for old proposals; that is, how one views old proposals should not change. When old proposals are copied, however, we need to revert to the new system and remove sub-arrays from the session area. Basically do what we have done for old resources that are no longer available.)

VLA - Resources

  • GOST Update: GOST will not be incorporated into the PST this cycle. It will continue to be a necessary stand-alone program. GOST will handle all Resources that are mixed wideband and narrow band setups, or spectroscopic setups only. The backend: "General and Shared Risk Observing - Spectral Line" thus does not change as it only invokes GOST. Programmer's note: No work for GOST, of course. We should verify that there is absolutely nothing that needs to be done to the tool.
  • Backend "General and Shared Risk Observing - Wideband". This needs some changes:
    • For Receivers P and L band, it is a bit confusing to show 2x1 GHz in the "Baseband" selection. We should change the label of the selection possibilities: for P band the label should be "2x128 MHz (8-bit)"; for L-band the label should be "2x512 MHz (8-bit)". Programmer's note: Done
    • For C, X, and Ku bands, if 3-bit basebands are selected, one would not use 4 basebands. Thus (again to avoid confusion), it would be useful to change the label of the selection possibility (it is not necessary to change the center frequency - this is not currently allowed for users). For C and X band one would change the label to "2x2GHz (3-bit)", and for Ku band one would change the label to "3x2GHz (3-bit)". Programmer's note: Done
    • Default integration times should be: for A configuration 2 seconds; for D configuration at L, S, and C bands 5 seconds, all others 3 seconds; for C configuration at L, S, and C bands 5 seconds, all others 3 seconds; for Bconfiguration 3 seconds. If 3-bit samplers are selected, the default integration time should be 3 seconds. Programmer's note: Done
    • Data rates between 25 MB/s and 60 MB/s are general observing (not shared risk), but we require special justification for data rates in this range. If the data rate is in this range, we would like a text box pop-up which the user will have to describe the special justification. Resources should not be saved (and the proposal should fail validation) without this special justification. Data rates above 60 MB/s are Shared Risk. Integration times between 50 ms and 1s should be Shared Risk. See the table below. Programmer's note: Partly implemented, Dana has comments on formatting fixes in the pop-up text box. Estimate 1 day work.
    • The 4 band receiver selection should be un-grayed for Resident Shared Risk selections. It should remain grayed out for General and Shared Risk Observing. Programmer's note: Done

      ModeData RateIntegration TimeComment
      General Observing < 60 MB/s > 1 s Between 25-60 MB/s requires user to enter justification in text box
      Shared Risk Observing > 60 MB/s Between 50 ms and 1 s
      Resident Shared Risk Observing < 50 ms If user wants to use 4 band receiver

GBT - Resources

VLBA - Resources

  • Update VLBA constraints: No new resource changes for the VLBA.However, 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. Programmer's note: We believe this will be much easier to implement internally in the code, for this deadline. We will coordinate on what is best for the future, but for this cycle it will be difficult to implement as an imported file. For instance, this may fit into a more general overall validation scheme that works for GBT as well. Some testing and feedback will be needed on the validation and the warning messages that pop up when invalid HSA resources are requested. Estimate two weeks to implement and test.

HSA Station PFB? DDC? Max No. DDC Subbands (IF Channels) Minimum DDC BW per Subband(MHz) Minimum DDC BW per Subband(MHz)
Y27 No Yes 4 16 128
VLBA Yes Yes 4 64 128
Gb Yes Yes 4 64 128
Eb Yes No      
Ar Yes No      
  • Aggregate Bit Rate: We still had a few 13B proposals which had 'blank' for the Aggregate Bit Rate. We thought we had fixed this, or at least put up a warning / error when it occurred. Proposal should not validate when the ABR is blank. Programmer's note: This is a bug, and has not been fixed, except that it is always caught at validation now. This could be quite time-consuming to track down and fix. How important is this to be fixed? (dsb: I do not think this is critical. It does not happen often so as long as we can trap it at validation we are okay.)
  • HSA and VLBA Checkboxes: Currently a user can save a resource where the HSA/VLBA checkbox is selected but no stations are selected. Or alternatively a resource can be saved where the HSA/VLBA checkbox is not selected but stations are selected. We should prevent the user from saving a resource for these cases with the following pop-up messages below. Programmer's note: We know what to do here, but no work done yet. Estimate 2 days work.
    • HSA selected with no stations: "The HSA checkbox cannot be selected without any HSA stations."
    • HSA not selected but stations are selected:"The HSA checkbox must be selected when HSA stations are selected."
    • VLBA selected with no stations: "The VLBA checkbox cannot be selected without any VLBA stations."
    • VLBA not selected but stations are selected:"The VLBA checkbox must be selected when VLBA stations are selected."

Misc.

  • Add Technical Justification page: To help improve the technical review process the technical justification information will be separated from the Scientific Justification page. Add a new page called "Technical Justification" located after the Scientific Justification. The page contents will be telescope dependent but have the same basic structure. It will consist of a series of "cues" or "headings" with free-format text boxes to be completed by the user. All fields are required; that is, the proposal should not validate if any one of the fields is empty. Links to relevant online documentation will be included for each cue. Programmer's note: About 75% implemented. Still need to put in the validation checks on the required fields. Still need to put them in the final printed PDF (is this needed - for both proposers and SRP/TAC printouts? [dsb: yes, I think so.]). Downloading a file you've uploaded does not work (is this needed? [dsb: I don't think so as long as you can view it and upload again.]). Still need to implement display of the Technical Justification in the Reviews tab, but this doesn't need to be done before the CfP - just by the deadline (or a week or so after, when technical reviewers are assigned). Remaining work (pre-CfP) is estimated at 1 day for validation, a few days for the Reviews tab part, unknown for printed PDF (1-2 weeks?).

Common to all telescopes will be the following text:


TECHNICAL JUSTIFICATION

Use this page to specify how the technical set-up requested under "Resources" enables the scientific goals to be met. Input is required for all fields. If a field is not relevant for your proposal then enter "NA" into the textbox.

Here are the telescope dependent cues/textboxes:

VLA


Explain reason for the array configuration(s) requested:
https://science.nrao.edu/facilities/vla/docs/manuals/oss2014a/performance/resolution
<text box>

Note whether the targets will be nighttime or daytime sources for
the configurations proposed, and whether there will be any potential
scheduling issues:
https://science.nrao.edu/facilities/vla/proposing/configpropdeadlines
<text box>

Explain choice of receiver(s) requested:
https://science.nrao.edu/facilities/vla/docs/manuals/oss2014a/performance/bands
<text box>

Describe correlator set-up(s) requested:
https://science.nrao.edu/facilities/vla/docs/manuals/oss2014a/performance/correlator
<text box>

Sensitivity required to achieve the science goal; include frequency
or velocity width assumed:
https://science.nrao.edu/facilities/vla/docs/manuals/oss2014a/performance/sensitivity
<text box>

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:
https://science.nrao.edu/facilities/vla/calibration-and-tools/exposure
https://science.nrao.edu/facilities/vla/proposing/overhead
https://science.nrao.edu/facilities/vla/docs/manuals/oss2014a/performance/limitations/confusing
https://science.nrao.edu/facilities/vla/docs/manuals/oss2014a/performance/rfi
<text box>+<upload of exposure calculator graphic(s)>

Correlator dump time, data rate, and total volume of raw data expected:
https://science.nrao.edu/facilities/vla/docs/manuals/oss2014a/performance/tim-res
<text box>

Is the imaging expected to be sensitivity limited, dynamic range limited,
or both? Describe any potential imaging issues expected (e.g., due to
wide fractional bandwidths, ionosphere, nearby strong sources, complex
source structure, etc.):
<URL TBD>
<text box>

Note any potential problems with RFI in the proposed observations:
https://science.nrao.edu/facilities/vla/docs/manuals/oss2014a/performance/rfi
<text box>

Note any other special technical considerations with either the
set-up or the data processing:
<URL TBD>
<text box>

VLBA


Explain reasons for the stations requested; specify minimum number
acceptable, and note which stations are optional and/or required:
https://science.nrao.edu/facilities/vlba/docs/manuals/oss2014a/ang-res
<text box>

Explain choice of receiver(s) requested and whether or not dual
polarization is needed for each receiver:
https://science.nrao.edu/facilities/vlba/docs/manuals/oss2014a/bands-perf
<text box>

Scheduling issues:
Weather constraints: specify weather (suitable for a given frequency band,
not necessarily at the observing frequency) at the requested stations:
<URL TBD>
<text box>

Date constraints: specify preferred dates, or excluded dates, and/or if
a series of observations with specified spacings:
<URL TBD>
<text box>

Specify minimum length of scheduling blocks (blocks of observing time, which
may be different than sessions) that can be observed and a start-time range
in Pt_LST; note that shorter blocks are, in general, easier to schedule;
If 24-hr blocks are required, indicate whether or not break-points may be
installed in the schedule to allow different start times:
https://science.nrao.edu/facilities/vlba/schedules/dynamicguide
http://www.aoc.nrao.edu/software/sched/index.html
<text box>

Describe correlator set-up requested (in particular, note whether
pulsar gates, multiple field centers, etc., are required; in these cases,
also note the expected correlation slow-down factor):
https://science.nrao.edu/facilities/vlba/docs/manuals/oss2014a/correlator
<text box>

Sensitivity required to achieve the science goal; include frequency
or velocity width assumed: <text box>

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:
https://science.nrao.edu/facilities/vlba/docs/manuals/oss2014a/bsln-sens ,
https://science.nrao.edu/facilities/vlba/docs/manuals/oss2014a/bands-perf
http://www.evlbi.org/cgi-bin/EVNcalc.pl
<text box>+<upload of exposure calculator graphic(s)>

Is the imaging expected to be sensitivity limited, dynamic range
limited, or both? Describe any potential imaging issues expected (e.g., due to
ionosphere, nearby strong sources, complex source structure, etc.):
http://www.cv.nrao.edu/vlbabook/ search for "Practical VLBI Imaging" by C. Walker
<text box>

Will phase referencing be required: Y/N <radio button to enable text box>
If Y: Specify calibrators to be used and their expected flux densities,
or whether extra time (on the VLBA or the VLA) will be required to find calibrators:
https://science.nrao.edu/facilities/vlba/docs/manuals/oss2014a/bsln-sens
http://www.vlba.nrao.edu/astro/calib/
<text box>

Are these polarization observations: Y/N <radio button to enable text box>
If Y: Will VLA observations be needed to determine the EVPA of the
calibrators, and if so, within how many days of the VLBA observations:
https://science.nrao.edu/facilities/vlba/docs/manuals/oss2014a/spec-tech/polar
<text box>

Are these HSA observations: Y/N <radio button to enable text box>
If Y: Justify why the HSA is needed to achieve this science, and verify
that all stations can sample/record the same observing mode:
https://science.nrao.edu/facilities/vlba/docs/manuals/oss2014a/prop-prep/vlba-plus
<text box>

Note any other special technical considerations with either the
set-up or the data processing:
<URL TBD> https://science.nrao.edu/facilities/vlba/schedules/dynamicguide ?
<text box>

GBT


For each resource briefly justify the observing mode and all values used
in determining the required observing time (e.g. frequency switching or
position switching, bandwidth, spectral resolution, polarization, etc.).
Include all inputs and results for the GBT sensitivity calculator. If the
sensitivity calculator is not used then provide all equations, with each
term defined, along with the values used. If a specific documented
instrument sensitivity is used then provide the reference for the value used.
<text box>

For any session that uses mapping present all inputs and results from the
GBT mapping planner. If the mapping planner is not used then provide all
equations, with each term defined, along with the values used. The
sensitivity calculator observing time results are for a sensitivity per
beam. To calculate time per pixel simply divide the time per beam by the
number of pixels per beam.
<text box>

For each session, briefly discuss the potential impact of RFI and how it would
be handled during the observations and during data reduction.
<text box>

For each session, discuss the amount of overhead time needed and how that
value was derived (e.g. receiver change time, slew time, time for pointing
and focusing, time for AutoOOF, calibration observations, etc.).
<text box>

If your proposal contains novell observing or data reduction techniques
please provide details on the techniques to be used.
<text box>

Pulsar proposals should list the information such as the spin period,
dispersion measure, binary period, average flux, etc. for any known pulsar.
<text box>

GMVA

Explain reasons for the stations requested; note if there are stations which
are optional and/or required: 
http://www3.mpifr-bonn.mpg.de/div/vlbi/globalmm/tech.html
[text box]

Explain choice of receiver(s) requested and whether or not dual 
polarization is needed for each receiver: 
http://www3.mpifr-bonn.mpg.de/div/vlbi/globalmm/tech.html
[text box]

Scheduling issues:
    Session constraints: specify preferred GMVA sessions:
    http://www3.mpifr-bonn.mpg.de/div/vlbi/globalmm/sessions.html
    [text box]

Describe correlator set-up requested (in particular, note whether
pulsar gates, multiple field centers, etc., are required; in these cases,
also note the expected correlation slow-down factor): 
http://www3.mpifr-bonn.mpg.de/div/vlbi/globalmm/tech.html
[text box]

Sensitivity required to achieve the science goal: 
[text box]

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: 
http://www3.mpifr-bonn.mpg.de/div/vlbi/globalmm/sensi.html
http://www.evlbi.org/cgi-bin/EVNcalc.pl
[text box]

Is the imaging expected to be sensitivity limited, dynamic range
limited, or both?  Describe any potential imaging issues expected (e.g., due to
ionosphere, nearby strong sources, complex source structure, etc.):
http://www.cv.nrao.edu/vlbabook/ search for "Practical VLBI Imaging"  by C. Walker
[text box]

Will phase referencing be required: Y/N 
If Y: Specify calibrators to be used and their expected flux densities,
or whether extra time (on the VLBA or the VLA) will be required to find calibrators: 
[text box]

Are these polarization observations: Y/N 
If Y: Will VLA observations be needed to determine the EVPA of the
calibrators, and if so, within how many days of the VLBA observations:
[text box]

Note any other special technical considerations with either the
set-up or the data processing: 
[text box]

  • Remove examples in the Cues for Triggered Proposals: For Triggered Proposals there are cues in the textbox for the Trigger Criteria. In parentheses are examples. Please remove the examples (see below). Programmer's note: Done and tested.

Target type: 
Origin of trigger: 
Trigger event description: 
Semester(s) and number of events:

  • Sorting Proposals: On the My Proposal page there is a summary view of all proposals for the user in question. There are several columns that can be sorted (e.g., name, P.I., etc.), and different filters (e.g., telescope) to the left. Not included is the creation date. The current configuration sometimes causes problems when new proposals are added they are not always visible in a given view. To improve the situation we want to make the changes below. Programmer's note: Done except for item 3, where we are waiting for guidance.
    1. Add a note at the top of the table that says: "Problem finding your proposal? Try sorting a column by clicking on the column header or by changing the filters to the left."
    2. Add a column called "Create Date" that lists the creation date. This should be sortable.
    3. We will explore different ways of sorting the table to identify a default.
  • Add option to exclude source list from pdf: Since the source lists can be quite large an option should be added when printing that can exclude the source list. Programmer's note: Done and tested.
  • 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.Programmer's note: This is the code that Ashish provided. Rick has the code, but needs to understand what needs to be checked in. Will require testing.
  • Update default email addresses: At the start of the PST user database we did not demand that users specify default institutions or email addresses. As a result there were many users without defaults which causes problems downstream. Rick L. recently wrote a script to fix this for institutions where a user had only one institution but no defaults. It would be useful to extend this to email addresses. (See EVL-2151) Rick ran a query and found only 1 user (Shea Brown) that did not have a default email. He will update that user in the application and close the ticket. Programmer's note: Mostly done - trivial amount of time to finish up.
  • Remind users about profile updates: Often users will not update their profile information which makes contact more difficult, causes login issues if passwords are forgotten, and degrades metrics. Add the following note at the top of the Dashboard, before "Telescope News". Programmer's note: Easy to change - small amount of time.

User Accounts (in bold)

Please remember to update your user profile, especially if you have moved to a new institution.  Do not create a new account. (last sentence in red.)

  • Add Global mm VLBI (GMVA) Proposals: Add GMVA proposals into the PST. This is an agreement we have had for the GMVA folks for several cycles. As such, it should probably be raised in priority if we have the resources to do it. I will try to write the requirements for a new instrument, which should have its own resources, but other than that should resemble the VLBA instrument. This seems to be the cleanest way to do things.Programmer's note: This is all fairly straightforward, since it is already implemented for the VLBA, and these are relatively minor changes to what we have. Estimate 1 week.
    • All sections of the GMVA proposal should be the same or similar to VLBA proposals, except the Resources section, although there are minor things which should be marked as GMVA rather than VLBA/VLA/GBT (for example the proposal ID should be marked GMVA/14A-xxx). Selection filters which occur in many places in the PST should also allow GMVA as a filter selection (this may not be a minor thing in coding). Programmer's note: This is easy conceptually, but may be difficult to find all of the places in the code where there are selections (or if-then-else statements) related to telescope type. We are not sure how much time this will take - we probably need a couple of days to look at the code and make a more concrete estimate.
    • The Resources section of the GMVA proposals has several components (as does the VLBA Resources). Changes from VLBA Resources are given below. The first thing, though, is the title of the page. It should say "GMVA Resources".
      • The first line of inputs (Order, Name, Wavelength, Processor, Observing Mode, Session) should be the same as for VLBA Resources, except the "Observing Mode" column can be removed. Order, Name, and Session refer to multiple Resources (and what Session asks for a given Resource) and these can be the same as for VLBA Resources. Wavelength should be a drop-down menu as currently, but for GMVA only two wavelengths should be available in the menu (7 mm and 3 mm). Processor should also have a drop-down menu as currently, but currently there should be only two possible entries: Bonn and Socorro-DiFX. (This may change in the future.)
      • The set of input columns (Stations, Observing Parameters, Correlation Parameters, Special Features) should be modified:
        • Stations should still have the VLBA checkbox, but there are only eight VLBA stations that have a 3mm receiver, so Hn and Sc should be removed from the list of stations. The HSA and VLA rows should be removed. An additional set of stations should be marked "European" (with a checkbox) and the stations (each of which should have a checkbox) should be Pv, Pb, Eb, On, Yb, and Mh. Finally, for stations, we should have a text box (like the current one labeled "Geodetic") but the label should be "Other Stations". Users can then enter codes for other stations in that text box.
        • For Observing Parameters, there should be currently only one selection: It is the same as for the VLBA "PFB System". (We may have to add other Observing Parameters in the future.)
        • For Correlation Parameters, this column can be directly copied from the VLBA Resources.
        • For Special Features, only one checkbox should currently be available "Full Polarization". (We should keep the capability to add other items in the Special Features list.)
    • The Sessions section can be made exactly like the VLBA one.
    • General, Authors, Scientific Justification, Sources, Pages can also be made like the VLBA ones.

Reviews

(Programmer's note: Punting on Reviews section for now, we will go back over this in a couple of weeks when we're further along with what is needed for CfP and deadline.

  • Joint Proposals (9 Aug):We need a mechanism to specify and display joint proposals on the My Reviews page, the Panel Reviews page, and the TAC Meeting page. The question is how best to do display Joint proposals? The only information we currently have is that the proposal is joint with x telescope. So we do not really know what proposals are connected without reading them. So the best we can do is indicate that a proposal is joint. Add two features in the table view of the My Reviews page, the Panel Reviews page, and the TAC Meeting page: (1) a check box under options to filter on Joint proposals. For example, like the Student Support check box in the Proposal List page. (2) Add text in the first column (which is Proposal Code) that specifies if the proposal is joint. For example, in the Panel Review page:

VLA/13B-188
PI: Heino Falcke
Type: Triggered
Joint: GBT
Hours: 42.00
Thesis: No

  • Add PI and Title on review page (9 Aug) :It was suggested to list the proposal PI and title on the review page.

  • Add Mark Complete button (9 Aug) :Currently on the Reviews Summary page the PST admin. can mark all the proposals for a given reviewer as "closed". We want to add similar functionality except instead of closed we want to be able to "complete" all reviews for a given reviewer.

  • Change how Conflicts are Assigned (9 Aug) :When automatically accessing if a reviewer has a conflict we check if the reviewer is at the same institution as one of the authors. There are two ways to get a person's affiliation. The first is via the person_organization table where the person.defaultOrganization_id is specified as a pointer to the default organization. The second is via person.affiliation, which is a text field. Currently, person.affiliation is used in determining reviewer conflicts. We want to change this to use the person_organization table and the person.defaultOrganization_id

  • Add default consensus-comment cue for recommended time (13 Sep) : Say "Recommended time: The SRP recommends no alteration to the proposed time request."

  • Archive Finalized SRP Consensus Review (13 Sep) :When the SRP chair finalizes the review the SRP consensus review for each proposal should be saved in the database. The PST admins should be able to modify the text that will eventually be sent to the proposers but the original version should be saved.

  • Normalize Review Stage should be executed per SRP (13 Sep) :Currently when moving to the Normalize Reviews stage all SRPs have to be completed (both science and technical) before moving to this stage. We have to change this such that each SRP can move to the Normalize Reviews stage independently.

  • Linear normalized rank (30 Sept):It would be useful if the order when sorting by the linear normalized rank is the same for the PST and PHT. Currently they handle ties differently.

  • Filter to include the GBT and VLA for HSA Proposals (9 Oct): Add two filters on the TAC page called "GBT/VLBA" and "VLA/VLBA". The "GBT/VLBA" filter will include all GBT proposals plus all VLBA proposals that have the GBT included as an HSA station. The "VLA/VLBA" filter will include all VLA proposals plusall VLBA proposals that have the VLA included as an HSA station.

  • Allow users to see their disposition letters (12 Nov):It would be useful to users to be able to see their disposition letters. Presumably this requires this information has been imported from the PHT. Where do we reveal this information? New page attached to the proposal?

  • Import Data from PHT to PST (no deadline):We want to import the modified sessions,the total accepted time (presumably derived from the modified sessions), the priority, and the disposition letters. There may other data fields. (See EVL-2123)

  • UI access to the public and allocated hours fields (no deadline):Editable (restricted) access to the public and allocated_hours fields is required, so somebody like Joan can get that information into the system for non-PHT (DDT) proposals. There is an interim solution available, but in the future we probably want this done in the PHT and propagated to the PST.

Documentation Updates

  • Add Technical Justification section.
  • Add GMVA proposals.
  • Update VLA resources.
  • Update VLBA resources.
  • Update GBT resources (VEGAS).
  • Update Sources page: changed calibrator flag from true/false to Yy/Nn; both should work.
  • Update documentation on author pages. Currently says: "If the search for an author in the NRAO User Database is not successful please fill out the form and we will contact this author and ask them to register." We removed the form and forces users to register before the add authors.
  • Update links.
  • Update observing types.

Background Tasks

  • VLA Configurations: 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.
  • Improve UI for registration: 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).Programmer's note: We do not think we have the time to implement this - it can be added to the backlog and attempted for 14B.

  • GBT Resource Validation: (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 Proposals: 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.

  • Import all External Proposals into the PST: We typically receive several externally reviewed proposals (e.g., FERMI, CHANDRA). It would be very useful to include these proposals in the PST. There is currently a method that is used to import global mm VLBI (GMVA) proposals. We want to extend this method to import all external proposals. We also want to expand the current method to include the total time, resources, and sessions. The native proposal ID should be retained and abbreviated forms available for observing.Programmer's note: There is still enough uncertainty on this item that we don't believe we will be able to implement it for 14A. For instance, we don't know enough about what is needed in the Resources and Sessions areas.
    • Implementation requirements:
      • All external proposals will now have the Proposal Code "X/<complete external proposal identifier>" (X for external), where the external proposal identifier is the code used by the external organization. This will include Global VLBI, Chandra, and Fermi with others (ALMA?) to be added later in the same series.
      • 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.
      • Resources and Sessions (including the total time) should be added to the current method of adding external proposals.
    • Operational impact
      • All NRAO telescopes will use the Legacy Code for observing if possible.
      • This creates an increased load entering proposals so additional resources are required. These external proposals, however, do not have to be entered before our normal deadline.
      • We require that all authors be registered at my.nrao.edu and we will do our best effort to enter all authors to the proposal.
  • Mechanism to Handle DDT proposals: Requirements require more details.) 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.

  • DDT/EPO: (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? (See EVL-2115)

  • Student Support Page: (One option is to move these external tools to a tab within the PST infrastructure.) 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.

  • Improve UI for 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. (See EVL-2117)

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

  • Joint Proposals: 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.

Relevant Bug Fixes

  • EVL-2025 Duplicate Proposal Identifiers
  • EVL-2197 Problem with reviewer conflict assignment
  • EVL-2199 Aggregate bit rate in VLBA resources is not always set properly
  • EVL-2202 Print Preview Error
  • EVL-2208 Problems with the emails that are sent due to reviewer conflicts
  • EVL-2220 Admin changing user profile resets permissions
  • EVL-2223 VLA sessions with multiple configurations
  • EVL-2224 Classification as Scientific Reviewer dependent on order of addition to Scientific / TAC Pools
  • EVL-2225 Proposal review textbox displays text when empty
  • EVL-2227 Problems with the SRP chair panels conflict status when the science category is changed

-- DanaBalser - 2013-02-14

Topic attachments
I Attachment Action Size Date Who Comment
VEGAS-PST-requirments-v4.odtodt VEGAS-PST-requirments-v4.odt manage 15 K 2013-05-30 - 14:34 DanaBalser VEGAS PST Requirements V4
VEGAS-PST-requirments.odtodt VEGAS-PST-requirments.odt manage 14 K 2013-05-02 - 10:48 DanaBalser VEGAS PST Requirements
VEGAS-new-modes.odsods VEGAS-new-modes.ods manage 100 K 2013-05-02 - 10:48 DanaBalser VEGAS New Modes table
VEGAS-spectrometer-modes.odsods VEGAS-spectrometer-modes.ods manage 12 K 2013-05-30 - 14:34 DanaBalser VEGAS Spectrometer Modes
This topic: Software > ProposalSubmissionTool > PSTPoRAug2013
Topic revision: 2013-08-12, 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