LOFAR2.0 Newsletter July 2021
Over the last couple of weeks, I had several discussions with astronomers on future instrumentation. It is great news that green light has been given for the construction of the SKA, which will provide new and unparalleled capabilities to the science community. At the same time, astronomers confirmed that LOFAR is a fantastic telescope now, and is becoming even better thanks to our efforts! When the SKA will become fully operational around 2029, LOFAR continues to be unique, with an angular resolution > 10x higher than that of the SKA, and accessing the largely unexplored spectral window below 50 MHz. Once more I realised how rewarding it is to contribute to LOFAR.
Please enjoy the highlights presented in this Newsletter. After a year of hard work, the holiday season is now kicking in. Many of you are going for a well-deserved leave. I wish you a very relaxing summertime in good health.
A LOFAR2.0 Science White Paper is being prepared to help advertise the project, its science goals, and to assist ILT partners with science text that they can use in their local funding drives. The document is being written collaboratively with inputs from dozens of LOFAR community scientists. A call for expressions of interest in LOFAR2.0 science will be released around September this year, following by a workshop on the capabilities of LOFAR2.0.
During the design of LOFAR2.0 lots of design choices are made at all hierarchy levels in the product tree. There are often several solutions that fulfill the requirements. In order to make decisions more explicit, a design document is written for each decision. Such a design decision document starts with the requirements, presents the options on the table and finally concludes with an analysis which leads to the design decision. The design document is reviewed by all people who “feel” an impact of the design decision on their part or are close to it. This can be technically or organizationally (time/budget). The advantages of design decision documents are threefold:
- The design decision can be traced back and the arguments for certain decisions are documented.
- More eyes on the design decision, which leads to a more broadly supported decision across the team because multiple people can share their view and input.
- During the project execution already part of the documentation is written which was normally written before a formal review or not at all.
In this way the same documentation is both relevant in the design phase and for the rest of the instruments lifetime. The argument of “but this is too much overhead” can be easily countered, because a design decision document is a very small and easy to write document. And to make our lives even easier: a single template brings writing a design decision back to “just fill in the blanks”.
In the Station project, the work is progressing largely along two parallel tracks now. On the one hand, there is a group of engineers who have been and still are very busy with completing the DTS test cabinet and preparing it for quantifying the available cooling capacity. On the other hand, other engineers are working on integrating subcomponents with the Lab Test Station LTS by executing test cases as written down in Polarion.
The first group, working on DTS and cooling, have made important progress. They have measured the impact of the intended sunroof (see Figure 1) on the cabinet temperature. From these measurements it can been concluded, though preliminary, that the sunroof of DTS blocks 600-900 Watts of influx heat for the whole cabinet. This may seem less than expected, but it makes a big difference for the necessary cooling capacity.
Further experiments for the LOFAR2.0 cabinet cooling will now proceed with the roof mounted, under the assumption that this type of roof will be installed on all Dutch stations by the time that we rollout LOFAR2.0 equipment. In the coming weeks we hope to get answers to the question what the realistic cooling capacity for a LOFAR2.0 station is, and to what level we can further optimize that to surpass the required capacity. Subrack cabinet temperature and airflow simulations have been made for this and these have already provided some insights for improvements in the air flow, to prevent too much mixing between the hot and the cold air. Now we will put that all to the test in real life circumstances, so we are eager for the results!
The other group of engineers have made progress in opening functionality of the LTS and using that to run predefined test cases from Polarion. A Python Jupyter notebook become available so that it has become a lot easier for users of the LTS to interact with the system. A command given by the notebook will go through a chain of components, either software, firmware, hardware, to create a response in hardware (see Figure 2). Several interfaces are crossed in this process, showing the design ideas at work, for real.
Gradually we are implementing more and more functionality as soon as it becomes available, through new firmware or otherwise. In this way, we test the functionality as early as we can in an integrated system. Being able to do that is a major achievement and highly important to prevent expensive fixes at a later stage, when such fixes becomes both, harder and more cumbersome, and thus much more expensive.
As a team, we have started to demonstrate the progress made in our three-week sprint cycle for our stakeholders at the program level. We are expanding that audience to all who are interested in our achievements and results. Also, we have added more preparation time and discussions to our sprints, specifically to look ahead at potential co-operation and planning issues for the next sprint. We have adapted JIRA to provide Polarion test-case-centric overviews of the work that has been planned over several work packages and therefore we can now much better monitor our progress and issues.
Last of all: to keep track of events happening in this project, please follow our news blog posts in Confluence, either through this link: https://support.astron.nl/confluence/display/L2M/DTS+NEWS or by joining the #lofar2-general Slack channel in the ASTRON slack workspace. Non-ASTRON readers may have to request permission to access our news blog.
Last Field tests completed!
During May, the Timing Distributor team performed a series of tests in the LOFAR operational system to verify the performance of the different hardware options considered for the upgrade. The tests were planned in coordination with the Telescope Operations group, and lasted 1 week. Different settings were tested with dedicated observations of astronomical sources. The White Rabbit equipment was installed in two stations (RS208 and RS307) during this period and removed at the end of the test campaign.
Among others, we tried daisy chain connections, in which White Rabbit switches are connected in series. This test is particularly important since it will be required for distant stations and in the concentrator node, the plan for the latter is to have one master and 2 sub-master White Rabbit switches. Connections via long, 60 km fibers were also done. Overall, the tests show that the quality of the signal was maintained in the different settings.
As previously mentioned, we have to deal with extreme long delivery times for our prototype boards and that we are still waiting for the delivery of most of the DTS hardware. All the PCBs for the new Sub-Rack, except for the RCU-H are now on order and ready for production as soon as the electronic parts are delivered. Expected delivery dates of the assembled boards are shown in the picture below:
The Time Distributor (TD) project is getting ready for the CDR phase and system- and technical details of the (White-Rabbit) equipment is now available for procurement. Procurement documentation for the Time Distributor is currently in preparation and request for quotations will be sent out in due time.
Tobia Carozzi (WP6 Lead) and LOFAR4SW team
UK902: LOFAR4SW testbed station
The LOFAR4SW project has the past year made significant progress towards preparing for LOFAR2.0. In particular, the project has accomplished the import milestone of commissioning a testbed prototype station called UK902. It is located at the Chilbolton Observatory in the United Kingdom, alongside the existing UK608 station. Building started August 2019 and first light was on the 19 September 2020. Although it does not use the LOFAR2.0 infrastructure – in fact it is only 4 LOFAR1.0 HBA tiles and half the nominal number RSPs (Remote Station Processing) – it has allowed the LOFAR4SW project to implement end-to-end testing of the main data reduction pipelines. Tests have also allowed the project to quantify back-end data reduction requirements.
Below left is a photo of UK902 and to the right the first light, dynamic spectrum from the station processed using the iLiSA S/W, the software package developed for LOFAR4SW operations in station stand-alone mode.
ASTRON is developing TMSS (Telescope Manager Specification System), which is a brand-new software application for the specification, administration, and scheduling of LOFAR observations. It will enable the required support for LOFAR2.0 use cases, while also streamlining LOFAR operations and improving the adaptability and maintainability of software for future extensions.
During the past two months, significant work has progressed on several fronts. Notably, support for beamformed observations and pipelines has been implemented, reporting has been enhanced, and dynamic scheduling has been further improved. The progress of the project can now be tracked online through the TMSS infographics, which were developed with the intent to keep our stakeholders informed about the up-to-date status of the implementations. Commissioning is ongoing and the first full observation including ingest of raw data and automatic cleanup from the CEP4 cluster has been performed successfully! Two current focus areas for further development are commissioning the beamformed observations and pipelines and integrating user administration and permissions. To support cycle 16 observations, further development will be realized in the areas of combined beamformed and imaging observations, ingest, responsive telescope, dynamic scheduling, transient buffer boards as well as commissioning the use cases with respect to specification and execution.
The project is working towards the release of the system in production by 1 September. TMSS will be presented to the LOFAR community at the Lofar Status Meeting on 14 July. Training sessions will be organised for users involved in supporting their projects. The second phase of the project has formally started on 21 June. TMSS-Phase2 will implement the support for more science use cases and realize further streamlining of the operational processes.
The changes introduced by LOFAR2.0, most notably the possibility to observe simultaneously with LBA and HBA, will allow for innovative calibration strategies. We require simulations of the upgraded instrument to study these new strategies and identify key software requirements to be prepared for the deployment of the hardware. Therefore, we developed the LoSiTo code to simulate LOFAR2.0 observations, including realistic models of all important systematic effects and the noise.
We simulated a full 8-h LBA plus HBA observation and calibrated the data, investigating the transfer of ionospheric calibration solutions from HBA to LBA as well as the joint calibration of both dipole instruments as future calibration strategies for LOFAR2.0. We find that the solution-transfer approach shows good convergence properties, but it is highly susceptible to the presence of uncorrected, non-ionospheric phase errors in HBA. In our analysis, jointly calibrating LBA and HBA allowed to determine the ionospheric parameters most accurately (see https://arxiv.org/abs/2105.04636).