TTA Tools: Friday, 11 am MT, 1 pm ET, 17 August 2018


CV-331/SO-280/GB-bsm, 331 Hub Audio 434-817-6286


  • Action Items from 10 August 2018
    • Use Cases (All)
    • Future Meeting Doodle Poll (Dana)
    • Updated Memo (Dana)
  • Details of the Allocation Request (All)
  • AOB


Attending: DanaBalser, JeffKern, AmyMioduszewski, StephanWitz, RyanLynch

  • Action Items from 10 August 2018
    • Use Cases. Nobody produced any use cases. We agreed to read through the current list of use cases and flag any that might cause problems. DanaBalser will generate a wiki page that organizes information for the committee.
    • Future Meeting Doodle Poll. DanaBalser sent around a Doodle pool.
    • Updated Memo. DanaBalser has started to update the memo.
  • Details of the Allocation Request. We discussed some of the details of an allocation request. We started by specifying the information that should reside in the top level Proposal.
    • Proposal. The Proposal should contain the title, author list, abstract, scientific objective (or justification), thesis project, related proposals, re-submission, proposal ID, state (and model), DDT or semester, and science review panel (SRP). Related proposal are proposals that are connected to the current proposal, whereas re-submission indicates that this proposal was submitted previously (along with the proposal ID). We felt that we needed to know if the proposal was a DDT at this stage since DDTs are handled differently, and we could not think of a case where a proposal would be submitted that would want to request DDT and regular time; or at least that this should not be allowed. We had a tangent discussion about copying a proposal. This was deemed as useful to users but has caused problems in the past due to validating that the proposal is valid (e.g., changing resources). Most felt that this was not an essential requirement though useful; we agreed to revisit this topic later.
    • Allocation Request. The Allocation Request should specify the data products needed. These should be tied to the Program and there should be a one-to-many mapping. For example, in the multi-configuration VLA Allocation Request there are three data products (or Programs): A-configuration image, B-configuration image, and the combined image. Some details.
      • Request Purpose. What is the goal and what data products are needed.
      • Request Type. This is tied to one and only one telescope. The HSA and GMVA should be considered as a telescope. Joint proposals would have different Allocation Requests (e.g., HST would be separate). In the future this may also include computing or correlator resources; hence request type instead of request telescope.
      • Allocation Type. Either open-sky or Sponsored time.
      • Allocation Justification. Essentially the technical justification.
      • Allocation Flags. This would include Triggered and Large. It would be useful to also capture the observing period (multiple semesters or multiple configurations), cadence per source, timing considerations (e.g., monitoring).
  • Action Items:
    1. All will read through the list of Use Cases in the initial requirements document draft and flag any that might cause an issue with our current structure for discussion.
    2. DanaBalser will generate a wiki page for this committee.

-- DanaBalser - 2018-08-16
Topic revision: r3 - 2018-08-17, 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