Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents


Note about suggestions -

Please make content-based edits in a non black color (unique, if possible).


PHT Summary

VLA and VLBA

The PHT for the VLA and VLBA provide provides versioning on the full set of proposals/sessions associated with a Semester call. This versioning allows enables the telescope schedulers to iteratively work on "modified sessions" according to the based on recommendations of the SRP or TAC. This modification includes manual assignment of (preliminary) scheduling priorities, manual modification of sessions, and manual modification of temporal attributes. From At the VLA, there is access to the Prioritizor which will algorithmically determine and assign the Prioritizer algorithmically determines and assigns preliminary scheduling priorities to sessions.  The VLBA does not have an algorithm with which to bulk process scheduling priorities. The proposals are processed together such that a final version is provided downstream.


The pressure plot must be configured ahead of the versions and modification of these details prior to these modifications (e.g., the start and stop dates of a VLA configuration) is not possible and generally cannot be adjusted on the fly generally. One There exists a single pressure plot exists for all versions in the sense that it is not possible , making it impossible to version the pressure plot itself. If a modification is made to the maintenance schedule, the previous configuration of the pressure plot is lost. Thus the ability to compare There is only one time model for all versions; . Consequently, comparing differences to reserved time definitions (time not associated with the current proposals) is not possible feasible without external tools (e.g., taking a screen shotscreenshot). It is not possible to dynamically inspect the pressure plot against the list of proposals, select selectively apply a number of proposals to selectively apply to the pressure plot at a time, or recover a pressure plot without any proposal pressure without restarting the process.

GBT

The GBT PHT allows the modification of sessions supports session modifications and the production creation of pressure plots. This modification includes These modifications include the manual assignment of (preliminary) scheduling priorities, manual modification of sessions, and manual modification of as well as manual adjustments to sessions and their temporal attributes. The Unlike other systems, the GBT PHT does not employ utilize an algorithm to prioritize tasks in bulk prioritize its algorithms. The All proposals are processed together such that , resulting in a final version is provided downstream. The GBT PHT does not use downstream, but without employing versioning.

One A single pressure plot exists is generated for all proposals, and there is not it lacks versioning capabilities. If a modification is changes are made to the maintenance schedule, the previous configuration of the pressure plot is lost. Thus the ability cannot be retrieved. Consequently, it is impossible to compare differences to with reserved time definitions (time not associated linked with the current proposals) is not possible without using external tools (e.g., such as taking a screen shot). It is not possible to  recover screenshot. Additionally, it is not feasible to restore a pressure plot without any that has no proposal pressure without restarting the entire process. It does provide Despite these limitations, the GBT PHT offers superior inspection capabilities compared to the PHT systems of the VLA and VLBA however in that it is possible to identify ; it allows users to pinpoint the specific session affecting impacting a point on part of the pressure plot.

The Furthermore, the GBT PHT also provides a "calendar" view , which produces a day to day breakdown of the pressure. This allows that offers a daily breakdown of scheduling pressures. This feature facilitates the easy inspection and adjustment of projects with fixed date dates and monitoring projects schedules, as well as the maintenance scheduleplans. 

It's important to note that Note the GBT PHT has includes broader features not in scope for that are not incorporated into the TTA Tools.

Current TTA Tools Requirements

From System Description, Section 3.6.1 for the PPR Proposal Process

  1. Production of a "Telescope Model of Available Time", which contains the information about pre-allocated time (maintenance, test time, carryover, Sponsored time). This pre-allocated time should be able to be imported.
  2. Algorithm to generate preliminary priorities
  3. Manual intervention after algorithmic determinations
  4. Production of Facility Report and Proposal Summary
  5. The ability to create and modify the Proposal Disposition and Allocation Disposition(s) before, during, and after the TAC.
  6. Ability to enter Comments for the PI and Internal Comments via the UI or file upload.
  7. Prevention of modification of the Proposal Disposition Comments for the PI after disposition letters are sent.

For the OSR Proposal Process and for a Proposal Process that supports the Auxiliary Committee, the requirements (5) and (6) apply, except for the phrase "before, during, and after the TAC".


Identified Requirements

Along with the current requirements, we identify the following from the current facility PHTs as critical to the workflow of the schedulers. 

Further Requirements Identified In-Flight

Allocation Disposition:

Ability
  • The ability to modify an Allocation Disposition and its dependents (e.g., Observation Specification Dispositions, Science Targets, Allocation Disposition State).
  • Interactive inspection of Allocation Dispositions and
its
  • their dependents.
  • Versioning of the Allocation Disposition
such that a prior
  • to allow recovery of a previously saved state
can be recovered
  • .
      Modification prohibited
        • Versioning per Allocation Dispositions
      • Prohibition of modifications after a specified point (e.g., after Disposition Letters are sent).
      • Output of Approved Allocation Dispositions
      to
      • into Disposition Letters.
      • Output of Allocation Dispositions for Proposal Summaries for the TAC and/or Directors Review (or the equivalent appropriate Proposal Process destination).

      Available Time Model:

      • Construction of an Available Time Model
      per
      • for each facility per facet per
      Solicitation
      • solicitation, where a facet could be an Array Configuration.
      • Flexible configuration of Available Time Models to
      support
      • accommodate on-the-fly changes, such as to execution periods and pre-allocated time.
        • For processes that support DDT-like proposals, the pre-allocated time should reflect the most up-to-date assessment that is desirable (e.g., daily pressure plot)
      Construction
      • Development of Pressure Plots and Calendar Plots.
      • Interactive inspection of Pressure Plots and Calendar Plots.
      • Versioning of Available Time Model(s) that is independent from versioning of Allocation Disposition.
      • Output of Available Time Model data to construct Facility
      Report
      • Reports for TAC and/or Directors Review (or the equivalent appropriate Proposal Process destination).

      We assert that these aspects are required necessary for the PPR Proposal Process. We believe they are consistent align with the needs requirements of an OSR Proposal Process. For a Proposal Process that supports supporting an Auxiliary Committee, a subset of these features should be identified.



      Additional Requirements for System Description (5.16.24)

      Allocation Disposition:

      • The ability to modify an Allocation Disposition and its dependents (e.g., Observation Specification Dispositions, Effective Science Targets, Allocation Disposition State).
      • Interactive inspection of Allocation Dispositions and their dependents.
      • Versioning per Allocation Disposition to allow recovery of a previously saved state and comparisons between versions.
      • Prohibition of modifications after a specified point (e.g., after Disposition Letters are sent).

      Available Time Model:

      • Construction of one or more Available Time Models per Facility per Solicitation, which includes Facility specific information, pre-allocated time, and other constraints on the available time (e.g., weather).
      • Flexible configuration of Available Time Models to accommodate on-the-fly changes, such as to execution period and reserved time (e.g., carry-over, maintenance, sponsored).
      • Production of Pressure Plots and Calendar Plots with and without pressure from the Solicitation's Allocation Dispositions.
      • Interactive inspection of Pressure Plots and Calendar Plots.
      • Versioning of Available Time Model(s) that is independent from versioning of Allocation Dispositions.
      • Comparison between saved versions.