LOFAR2.0 Newsletter September 2019

Nico Ebbendorf

UniBoard² has been selected as the new LOFAR2.0 digital back-end. This board will replace the RSP and TBB boards which has been operational in the LOFAR system for the last ten years. Although the design of the UniBoard2 for LOFAR2.0 is not yet finalised, the procurement activities to select a manufacturer have started. The process follows the European procurement regulation and we expecting to finalise this process in Q1 2020.

Pieter Benthem

After the successful Preliminary Design Review (PDR), early February 2019, the LOFAR4SW project has moved to the detailed design phase. In parallel, the LOFAR4SW project team has worked hard to prepare towards the Mid Term Review (MTR), scheduled for 24 September 2019, Brussels. The MTR will focus on the first Periodic Report, both from a technical content as a financial point of view. All documentation has been provided within time, just before the summer holidays kicked in.

Next to the EC Project Officer, the LOFAR4SW project will be reviewed by an external reviewer, appointed by the EC. We look forward to nice and lively discussions and hope to receive constructive feedback on our documents and project.

After the MTR, we will use the opportunity to organise a team-meeting on 25 September in Brussels, evaluating the MTR, as well as preparing towards the two main upcoming events: the Users Workshop in Warsaw in November 2019 organised by our partners at CBK PAN (WP8) and the Detailed Design Review in January 2020 that will be hosted at ASTRON.

The LOFAR4SW design study addresses all conceptual and technical aspects required to upgrade the LOFAR radio telescope, system-wide, to take on a parallel role as a highly innovative new facility that enables large-scale monitoring projects generating unique data for the European (and worldwide) space weather research community, offering great potential for improved precision and advance warning of space weather events affecting crucial infrastructures on earth.

René Kaptijn

On 16 July 2019 the Radio Observatory accepted Cobalt2.0 and put it in production. The GPU cluster runs well and is fast and stable. We switched off COBALT1 on 18 September. COBALT1 had been running as fallback during the summer. On 24-25 September during the stop days we will connect COBALT2.0 fully to the network. Now that COBALT1 is switched off enough network space is free to connect all COBALT2.0 network interfaces. This will double the output bandwidth to CEP4 compared to COBALT1.

Next step is to define COBALT2.0 Phase 2.

René Kaptijn

In the last two months we mainly focussed on the activities to prepare for the Preliminary Design Review (PDR) of the station and timing distributor on 25-26 September 2019. We invited an external panel to review the preliminary design. The main deliverables for the PDR are:

• The Station System Requirements Specification
• The Requirements Traceability Document System – Station
• The Station Architectural Design Document
• The Timing Distributor System Requirements Specification
• The Requirements Traceability Document System – Timing Distributor
• The Timing Distributor Architectural Design Document
• The High-Level Power and Cost Analysis
• The Project Management plan
• The Risk Register

On 3 September all documentation was available for the panel to review and a kick-off telco was held. Below is the full PDR review schedule.

The development of the RCU2 in cooperation with INAF has started. From 11-13 September Paulus, Albert-Jan, Gijs and Boudewijn had a workshop at INAF in Medicina. The RCU2 requirements were discussed in detail and we agreed on the architecture for the new RCU2. We investigated the performance and component availability of all the filters in the current RCU in detail to determine if we can re-use them. The results of the workshop are compiled into a preliminary design document and a requirement document for RCU2.

Hans van der Marel

For the LOFAR2.0 program a Systems Engineering approach has been developed in order to have control over the technical processes to fulfil the upgrade of LOFAR to version 2.0, which may help to deliver the Stage 1 upgrade in time and within budget. For ASTRON it is a new approach and the people in the various teams are getting used to it and in general react positively. Key elements are requirements definition and traceability, functional decomposition, interface control and verification at all levels in the product tree. The LOFAR 2.0 program uses the Polarion software tool to manage all these items during the whole process, which appears to be invaluable.

Since it is a new approach, the processes are still being polished. However, without this approach it would be impossible to manage the complexity of the LOFAR 2.0 program, with various projects interacting and impacting each other. It is likely that in the future the Systems Engineering approach, or parts of it, will be used in other projects at ASTRON.

André Gunst

The system architecture work has focused on clarifying the interfaces in between sub-systems and filling in gaps, which were present in the Architectural Design Document (ADD) as presented during the system CDR. One of the main tasks to do so is extending the content of the ADD with sufficient details such that compliancy or non-compliancy with the requirements is shown. This already led to two additional chapters in the ADD. Filling them is still a major task ahead of us. Furthermore, an ADD template has been made ready to be filled in for the other sub-systems.

Marcel Loose

Telescope Manager (TM) is the subsystem that is responsible for managing astronomical data, from the proposal phase up to the moment that data are stored in the Long-Term Archive (LTA). Large parts of TM touch upon existing software and services, some of which need to be replaced in order to support DUPLLO survey capabilities, because they have literally become legacy. TM therefore has a strong dependency on the LOFAR Efficiency Improvement (LEI) project, which aims at replacing those bits and pieces.

At the moment, a lot of effort is put into gathering all the requirements for TM. Input needs to come from the top-level system requirements, but also from the Operational Concepts and Support Concept Description. At the same, we are trying to define a minimal set of TM-functions that are required to support the DUPLLO survey. By the end of the year TM should be ready for PDR.