We live in strange times that we never experienced before. Things that were obvious a couple of months ago are now uncertain. At the same time, our daily work continues. I am deeply impressed by the flexibility and creativity of everyone in dealing with the situation. We have found new ways to collaborate and to keep in touch, and almost all LOFAR2.0 activities are continuing. The results of all hard work are presented in this new edition of the LOFAR2.0 Newsletter. Well done!!
Please keep in mind that this is not business as usual, and accept that some tasks will take more time. It is important that you stay safe and in good health because it is going to take a long time before we will be back to normal.
After 6 weeks of working at home, I am more or less getting used to it. At the same time, I am very much missing our face-to-face contacts. Take care of yourself and your family. I miss you!
Wim van Cappellen
Verification and compliance tracking
Within the systems engineering, process verification and compliance tracking are some key components in order to be sure that the system and its subsystems and components are fulfilling what we require them to do. During the development process, it will be necessary to verify most of the requirements more than once when progressing from the initial design until the final acceptance of the system or product. This way we check the design and make sure that we are on the right track.
Verification is nothing more than checking the design against the requirements, for the different phases of the development process. For LOFAR2.0, the requirements are in Polarion, test cases are linked to them and these are grouped for a certain event. For example, the requirements and tests that need a certain measurement setup can be grouped. Another example of an event is one of the formal reviews.
Polarion helps us a lot in automatic reporting on the result in a compliance table, even in the case that a test fails. Then the test can easily be redone, and the compliance table is automatically updated when the test is passed. In the figure below a small fragment of such a compliance table is shown as an example, with the requirements in the first column, the test cases and their results in the second column and issues because of failed tests in the third column.
Currently, we are busy to design the interface in between LOFAR2.0 and the Science Data Center. To disentangle both a lot of discussions have already been held between representatives of SDC, TMSS, LOFAR2.0 and the science support of the Radio Observatory. The results of those discussions are captured in the document “Architectural Design of SDC and LOFAR2.0 Interaction”. As always, the devil is in the details, but we are well underway with the exorcism of it. For the split the following 10 architectural design principles are used, which overlap partly because you cannot overstate some of these principles (and 10 is just a nice number):
- Functions are clustered together which fit naturally together, such that the number of dependencies and interfaces between LOFAR2.0 and SDC are minimised.
- Functions are clustered together which are physically in the proximity of each other.
- Functions are clustered together if they share common functionality.
- A system should be as independent as possible on the solution of other systems.
- Each piece of information or data point has one source, meaning that other systems requiring that information retrieve this from that source. This is also known as the "Single Source of Truth" principle meaning that every data element is mastered (or edited) only in one place. All linkages to such a data element shall be done by reference only.
- Use low coupling, high cohesion as much as possible, meaning that systems depend as little as possible on each other (low coupling) and that the elements within a system belong closely together.
- Create as few dependencies as possible (cannot be stated enough).
- Have the right information available at the right abstraction level. This means on one hand that detailed information should not be unnecessary moved up to a high abstraction level, while on the other hand the mandate to take decisions should be delegated to the lower abstraction levels, if possible. This is also known as the layers architectural pattern.
- Minimise information movement from one system to another system.
- Keep it as simple as possible.
Instead of the LOFAR room at the ASTRON building, we are using a virtual office called Sococo. In this virtual office, we work, have social chats, and run our daily Station team standup and coffee meetings. During the day we keep our virtual headset icon in Sococo open so that we can hear it if somebody speaks in the room. This is especially nice for shared coffee breaks and ad hoc questions and collaboration. It is also possible to meet and greet in another room or to remain quiet, almost just like in the real world.
In the new LOFAR2.0 Station, we want to use as many industry-supported interfaces and protocols as possible, instead of custom ones. One interesting candidate that we are exploring for that is OPC-UA, which is an advanced standardized protocol for monitor and control interfaces. We have done some early prototyping by implementing OPC-UA servers on a Raspberry Pi, on an existing LOFAR1-station Linux server, and on a micro-controller. Intern Thijs Snijder has achieved the latter as part of his graduation project. These prototypes have shown the versatility and availability of well-developed OPC-UA libraries. Therefore, we have started the process of formalising that OPC-UA will be the default interface in LOFAR2.0 station.
One of the early milestones in the project is the delivery of a lab test station. This is, basically, the first version of a LOFAR2.0 receiver and data processing chain build in the lab. It will subsequently remain in use as early integration testbed, which is very important to discover if hardware and software designs and implementations work as they are intended to. The system engineering process for LOFAR2.0 supports this by providing proper test cases and descriptions for the lab test station to the project.
Telescope Manager (TM) is still in low-power mode. The necessary discussions on interfaces with TMSS have mostly taken place, though, despite the corona crisis. The discussion on the split between the LOFAR2.0 system and SDC is also slowly converging, which is good for TM. TM will probably remain in hibernation until after the summer holidays.
While the hardware development for LOFAR2.0 is in full swing, steps for ordering the new boards have also been running on the background. For the tendering of the Uniboards2, a European procurement procedure needed to be followed. This procedure started in October last year with a call on Tenderned, an EU procurement website, for the assembly of the ASTRON Uniboards2. The call included a clear description of the tendering process that ASTRON followed, the procurement request such as production volume, planning etc. and, of course, a detailed requirement document of the complete Uniboard2 assembly. Quotations were rated for two main subjects, quality and price. Entry for sending in quotations finished by the end of January. By that date, we had received only one quotation. Very likely, companies could not comply with the high-quality standard that we require for this complex board and/or found the order to risk for their company. Fortunately, the quotation that we received is from the company Neways Leeuwarden B.V. who has been involved with the development and production of the Uniboards before. The selection comity was happy to conclude that the quotation from Neways was fully compliant and fulfils all our requirements including the total price of the project.
In the coming weeks, we will work out more details about the order with the ASTRON procurement office and developers together with Neways. Our planning is to start the prototype production soon, followed by four pre-production modules in Q2-2021 and a start of all the LOFAR2.0 Uniboard2 a year later.
On March 30 and 31 LOFAR4SW achieved an important milestone: the Detailed Design Review (DDR), originally planned to be a face to face meeting at ASTRON. However, when the strict Corona measurements were announced, the meeting was changed into a videoconference.
The review focused on the design of the HBA dual-beam tile and the simultaneous observing software. Despite the strange circumstances of the review; not only being at home but for many of us having also children running around, the efficiency of the meeting was not affected. Our team is happy with the constructive and open discussions that took place during the two days of the review.
The LOFAR4SW team is grateful of the dedication showed by the review panel: André Gunst (ASTRON), David Prinsloo (ASTRON), Menno Norden (ASTRON), Hans van der Marel (ASTRON), Mark Oude Alink (University of Twente), Federico Perini (INAF), and Henrik Olofsson (Onsala Space Observatory).
At the end of the meeting the panel provided initial feedback, and a report was delivered a couple of weeks later. The panel expressed their appreciation to the amount of work done and understood the complex landscape of the LOFAR4SW, which timeline is not aligned to the LOFAR2.0 program but it’s still dependent of it for some aspects. The report contains a series of recommendations that will help our team to improve our design and plan for the next major milestone that is the critical design review in 2021.
After the DDR, the team is taking the time to assess the impact of Covid-19 in the planning. With staff being prevented to work in the labs in the different partner institutions, we realised the initial planning needs to be revised. After a first discussion at the beginning of April, the project will make a major decision regarding the timeline at the beginning of May, we envisage a request for a no-cost extension to the EC, for an amount of time to be defined.
As a measure to help the internal project communication, LOFAR4SW has now a Slack workspace, with channels dedicated to the different work packages. We aim to move away from heavy email traffic and smooth the exchange of information within the team.
COBALT2.0 phase 2
Since the last newsletter, phase 2 of COBALT2.0 has started implementing new functionality. At the time of writing, the team has completed three sprints and is currently working on the fourth. The first sprint was taken up by an intensive, but highly successful knowledge transfer process. We are now finalizing the first addition to the COBALT2.0 code, which we expect to fully test, commission and roll-out in the next couple of weeks. This will include a minor update to the DAL and associated Interface Control Documents.
The first deliverable will add the ability to redigitize beamformed data products to lower their bit depth, allowing the formation of more tied-array beams within the bandwidth limit to our storage cluster. In the course of this work, we explored the relative error introduced, which turned out to be minor except when clipping, as shown in the image.
Finally, we welcomed a new member to our team, Steven van der Vlugt, who has started to familiarise himself with LOFAR and the COBALT2.0 system. Even in these challenging times, we've been able to make good progress, and remain on schedule. Phase 2 of the COBALT2.0 project will run until May 2021 in three 3-month intervals and will focus on several functional improvements to the correlator and beamformer system in LOFAR.
TMSS (Telescope Manager Specification System) will be a brand-new software application for the specification, administration, and scheduling of LOFAR observations. Its realisation is crucial, as 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. This is being realised by a team of software engineers and telescope scientists who are very committed to make the project a success. TMSS is an important component of the Telescope Manager of LOFAR2.0, the system that will control all aspects of the telescope, including proposal handling, observation execution, and system monitoring.
By the end of 2020, TMSS will deliver with high priority the software components for executing the LOFAR2.0 Survey Use Cases. By doing that, the project will implement also other LOFAR Science Use Cases, which will ensure a healthy continuation of the Cycle observing programs also before the start of the LOFAR2.0 surveys.
The TMSS project started in January 2020. During its first quarter, it implemented the system foundations in terms of telescope model and database. In the second quarter (currently in progress), the system will be fully capable to perform the survey observations and pipelines, with the required handling of and feedback on system resources, and will implement also dynamic scheduling. The following cycles will deliver support for the other planned use cases and responsive telescope functionality.
During the sprint review on 21 April, the system was already able to perform a survey-type LOFAR observation. The figure shows the team of happy TMSS team members and stakeholders framed within the most relevant screenshots of the TMSS system taken during the successful observation. This is a very important milestone for the project and the first of several more expected in the next months.
Deepest LBA Image of the Boötes field
Wendy Williams, Huub Rottgering
With a modified version of the ddf-pipeline used to perform direction-dependent calibration and imaging for the HBA surveys data, we have produced the deepest LBA image to date. This image of the famous extragalactic Boötes field was produced from 56 hrs of observations over a bandwidth of 34--75 MHz, and reaches a noise level of < ~0.8 mJy/bm at a resolution of 20 arcsec (see the accompanying noise map). While some artefacts remain around bright sources, the noise continues to go down with increasing integration time. The source catalogue contains ~2000 radio sources between 2 mJy and 20 Jy, and can already shed light on the nature of the radio spectra of star-forming galaxies and AGN.
We are continuing to push the limits of the LBA system as well as the software we use for calibration and imaging. Further work in understanding and correcting for all the systematic effects in LBA data is ongoing both in Leiden and Hamburg.