ALMA Upgrade Study: The Evolution of ALMA Proposal and Observation Preparation

1. ALMA Upgrade Study: The Evolution of ALMA Proposal and Observation Preparation

2. Introduction to the ALMA-OT • Proposing to use ALMA is done using the ALMA Observing Tool • The same tool is later used to create detailed Scheduling Blocks (SBs) that will be executed to take data • The ALMA-OT provides a great deal more: • Automatic observing time feedback (incl. overheads) • Visualisation in both space and frequency (correlator) • Validation of proposals and SBs • Generation of summary sheets for both PIs and staff (reviewing) • Prompts for setups that require Technical Justification • Automatic generation of SBs for Approved proposals. • The OT is an intelligent tool - it encodes a model of the ALMA Observatory. • It is a Java desktop tool, with a server-side submission handler

3. Spatial Visualation

4. Spectral Visualiser

5. Time Estimates

6. It works, so why change? The ALMA-OT has been a very successful tool, supporting ~8400 proposals over the first six cycles, succeeding in reaching a wide community, and generally gets very positive comments. • However, we do get critical comments about the tool • Un-named user comment: “The OT is stale” • It is difficult to satisfy everyone…(paraphrased comments) • We get “why can’t it be like the (HST) APT?” • They get “Why can’t the APT be more like the ALMA OT?” • More crucially: OT was designed in 2002-05, technology of the time demanded a desktop application (google maps launched in 2005) • Starting now, default technology choice would be web • Java on the desktop is passé • (or is it: what about HST APT, Aladin??, …)

7. Key Issues 1 Obsolescence: • OT User interface based on “Swing” – 90s technology • Its looks “dated”, it is no longer supported • More modern options are available • Spectral visualisation uses custom software, the spatial view a third party library no longer supported. • Both have significant limitations and drawbacks and are now hard to support (e.g. support for wide fields not good) • In both cases better options now exist

8. Key Issues 2 Environment: • Changing and evolving requirements have taken some areas beyond original design boundaries, causing “technical debt” • Future ALMA options will make this even more important…widefield, new receivers, bandwidth, correlator changes, etc. Expectations: • With rise of tablets, smartphones & many, many online websites users expect something different. • Performance has become an issue, particularly with Large programmes.

9. Benefits • Improved User experience • More effective/efficient proposal/project preparation • Improved/more current/leaner code-base • Lower support costs • Ready for the 2020-2030 instrument improvements (better future-proofing) • Improved deployment options • Smoother/cheaper for support staff, simpler/more transparent for users

10. Possible Options • Re-implement as a web-based application • Moving much intensive processing to web-services • Keep OT as desktop, but with significant technology/user interface overhaul. • Both options: consider separate tools for: • Spatial visualisation (interaction with existing such as Aladin?) • Spectral/correlator setups • Sensitivity and observing time calculations

11. Key Challenges for moving to the Web The OT, even at Phase I, is not a simple proposal tool: • In effect it encodes a “model” of the ALMA Observatory, calibration strategy, policies, constraints, etc. • Time estimation includes SB generation (for realism), which can be cpu (and memory) intensive. • And time estimation is done frequently, everywhere – PDF generation, validation, technical evaluation (for justification requests) • Visualisation tools – a significant challenge. Designing and implementing this as a web application is a significant technology challenge.

12. Current OT

13. Possible New OT?

14. Aims of study • Consolidate key drivers for an upgraded ALMA OT • Liaise/consult with other similar projects • Analyse desktop vs web options (including hybrids) • Provisional technology recommendation • Identification of key risk areas • Investigate and prototype risk areas • Elaborate a conceptual design • Create costed development and management plan for detailed design and production of new system

15. Timescale and Deliverables • Kick off was July 2017 • Study to last 2 years Two main final deliverables: • Memo on the Proposed Design for the upgraded ALMA-OT, along with a prototyping report (T0+20m) • Cost and Timeline development plan (T0+22m) • Review at T0+23m, final reports T0+24m • Aim to put a project development request to November 2019 Board.

16. Prototyping • Phase 1: Vertical Prototype (baseline technology and framework, explore UI considerations) • Phase 2: Micro-services integration prototype(services architecture, performance, scalability, deployment models) • Phase 3: Visualization Candidates(complex visualisations e.g. Spatial and Spectral Visualiser) • Phase 4: Integration and Deployment(how would this fit with rest of ALMA Software)

17. Prototype screenshots

18. Opportunities Work by other observatories: • SKA, currently in design, likely to begin serious development late 2019. (Strong links – I am lead for design of related areas) • ESO, work in progress to upgrade its systems for the ELT • NRAO upgrades to PST etc. • Contacts with team strong. • TMT, GMT, CTA?? • A common tool is very ambitious and won’t be addressed, but common approaches may be hugely beneficial, and there is much potential for cross-project learning

19. Proposal Workshop “ESO will explore the option of organising a short (1-2 day) workshop to which relevant parties will be invited to participate.” Share experience with other large telescope projects and organisations VLT, ELT, NRAO and SKA, working on similar upgrades to their proposal systems. • Timescale – late Spring 2018 ?(T.B.C)