Concerns: There were two main concerns: (1) that the software will be too tightly integrated with ALMA and this will not allow us flexibility; and (2) that the requirement to accommodate N > 1 telescopes will break this model. Some felt that it was unlikely that we would directly be tied to ALMA software. To handle N > 1 telescopes in the software we have to identify areas that are strongly telescope dependent.
PST Model: There are typically two extreme models: (1) the user does not need to know much about the telescope to submit a proposal; and (2) the user needs to know the technical details. We are committed to accommodate (1) for at least straight forward projects and therefore the software has to be more sophisticated than the current PST.
ALMA Time Allocation Process: We briefly discussed the ALMA review process. They currently have a panel based system but they all meet face-to-face and do not have telecons. Because of the large price tag they plan to change their review process. We suspect that the OT is not used directly in the review process but data are exported to other tools.
PHT Requirements: We may be missing some of the necessary requirements that are done with the PHT (e.g., preparing pressure plots). Some of these details are in the document but they need to be fleshed out. We should carefully check that we are not missing anything.
External Joint Proposals: We need to capture information from proposals accepted by external TACs. For example, we need to know the propriety time in the archive and cannot do this easily if there is no proposal information in the database. We discussed the history of this with the PST which included software that was implemented to allow the scheduler to import these data manually, and a proposal to use an XML file to pass data between observatories. The first method failed since it was too much effort for the schedulers, whereas the second method was rejected by the external observatories. We agreed that this needs to be set as a policy, implemented, and then executed.
OPT Requirements: There was concern that the project to develop new TTA software needs to be tightly coupled to the project to develop new observing tools (e.g., new OPT), but that the latter was not in place yet. This could be driven by the SRDP effort which has a lot of momentum.
Project Process: We briefly discussed the process moving forward. A committee will be formed to discuss and complete the software requirements. This will then be handed over to DMS to implement. We need to involve the external folks at some point. Some felt it was important to converge at some level internally first and then to solicit external feedback. It was suggested that we probe the ALMA folks during the proposal tool workshop this summer about generating SBs from proposal info.
The SSA group will read over the document again in more detail, discuss it amongst themselves, and then produce a list of comments. We will discuss these next Friday.
DanaBalser will draft milestones/timeline as input for LewisBall for the charge to the committee.