This month saw the Covid-delayed LSST@Europe4 meeting, which was originally scheduled to take place in the summer of 2020. Continuing Covid restrictions limited in-person attendance at the Accademia Nazionale dei Lincei in Rome to one hundred participants, but there was also a substantial remote attendance. Naturally, the majority of the in-person attendees were from Italy, but there was a very strong showing from the UK, with talks given by Tom Collett, Steven Gough-Kelly, @Sugata Kaviraj, Ilin Lazar, @Chris Lintott, Steph Merritt, @Dan Ryczanowski, @Meg Schwamb , @Raphael Shirley , @Graham Smith , @Ken Smith, @Aprajita Verma , @Tom J Wilson , and myself, and with session organising/chairing duties undertaken by @Sugata Kaviraj , @Meg Schwamb , @Graham Smith , and@Aprajita Verma . Slides from the presentations are linked from the Abstracts page, while it is expected that session recordings will be made available in due course.

Much of the introductory material presented by the Rubin staff restated information from the Project and Community Workshop in August, but there were some notable updates. In particular, Bob Blum noted that Rubin Operations is now working with a planning date of October 2024 for the start of survey operations, with an uncertainty of +/- 3 months. This has consequences for the expected release dates for Data Preview 2 (commissioning data from LSSTCam) and Data Release 1 (based on the first six months of observations: DP2 is now expected in Jan - Aug 2025 and DR1 between Oct 2025 and May 2026. From now onwards, the Observatory will make monthly updates to its listing (on https://ls.st/dates) of the primary milestones in the project schedule; currently this list of milestones covers only the construction project (and is drawn automatically from its project tracking tools), but the plan is to include the key dates - e.g., data releases - from Operations in that list.

As well as background/update information from Rubin staff, the conference also included sessions from each of the Science Collaborations, as well as sessions on synergies with CTA, E_ELT, Euclid, Gaia, SKA, and X-ray missions, so there will be plenty of interesting material online for everyone to look at.

As part of LUSC Phase WP3.5, we have investigated how different observational effects such as sky brightness, seeing, and number of exposures can affect the photometric redshift (photo-z) distribution for LSST. The observation strategy for Rubin is to cover a large survey region before building up the depth. During the first few years of observation, therefore, it is expected that the inhomogeneity in depth due to e.g. varying weather condition is large. Effectively, one can regard each pointing as a ‘mini’ survey with different observational systematics and limiting magnitudes. This could potentially be a problem for weak lensing analysis because the signal is sensitive to the mean redshift of the tomographic bin, especially for the precision required by LSST.

In this investigation, we focus on the ‘gold’ sample from the first (Y1) and fifth year (Y5) data release, for which the simulated observation conditions for the Rubin Observatory (OpSim) as well as the DC2 DM catalogue are used. We split the sample into tomographic binning for lens sample between 0.1 in 0.2 ≤ z ≤ 1.2 according to Y1 and Y5 requirements respectively.

One of the main aims is to check whether the spatially varying observing conditions introduce fluctuations to the mean and scatter of each tomographic bins that are larger than the Rubin requirement. The photo-z is estimated using a template-fitting algorithm, BPZ_lite. We find that for the sample with reduced photo-z outliers, the shifts in the mean redshift and the scatter in each tomographic bin is consistent with the random noise of the sample, and comparable to the Rubin requirement.

Additionally, we also looked at the impact of spatially varying observational conditions in each band on the cModel magnitude, the magnitude error, colour, and galaxy over-density.

Plots (to right): (top) Variation of magnitude error, (middle) photo-z bias, and (bottom) photo-z scatter with i-band 5σ depth using the coaddM5 MAF map from OpSim for Y1 and Y5 data in the DC2 simulation.

I recently spent a week in Tucson (Arizona, photos at right) where I met and worked with the Rubin Observatory Science Quality and Reliability Engineering (SQuaRE) team, who are developing and operating the Rubin Science Platform. The targets of the trip were to work through various issues & questions we had as operators of the RSP in the UK Data Access Centre (DAC), to gain a better understanding of the various components of the system and the process used to manage, operate & make upgrades to deployments, to identify areas where contributions could be made back to the project and build a closer working relationship with the team.

Throughout the trip we had a daily meet-up with the team to discuss the ongoing work, with a few focus sessions being held for us to discuss matters specific to the UK DAC. Some of these ended up in debugging sessions to work through some problems we were facing, while one of the meetings consisted of a Q&A session where we went through a number of questions, some technical while some more general future plans-related.

Going into a bit more details regarding technical discussions that were had:

We went through the "Patch Thursday" meeting where the team made their weekly patches to all the instances of the RSP that they operate. This process mainly involved the use of ArgoCD, which automatically recognizes changes to the configuration files in Github that the deployments are based on, so the team goes through each of the services and synchronizes them, which automatically deletes/recreates the Kubernetes deployment for that service. There are some intricacies that were involved such as deleting user sessions from a database, and notifying users which I have documented and plan on exercising with the UK RSP as well.

Some of the open issues here in the UK DAC were covered and we have a clear plan on moving forward, in particular regarding making the RSP TAP service available, customizing the Firefly TAP service list as well as parts of the main home page, as well as the process of upgrading tokens & certificates (Vault / SSL) for a production deployment without downtime.

There were a few ideas that are worth mentioning which may be useful to the UK DEV teams:

• Use of Sup! Slack bot for providing update summaries before meetings.
  This helps keep meeting shorter as managers have an idea of progress/issues before the meeting, allowing the more pressing matters to be discussed during the meeting hours.

• Use of Commercial Cloud Services
  The Rubin SQuaRE team are very heavily invested into the use of Cloud Services (Google mostly). From discussions I had with the devs of the team and the team manager, the increase in velocity of development and minimization of operations costs and overall cost of solving issues which appear when using an in-house solution, or academic clouds which aren't as polished & easy to use is worth the extra costs, which aren't as high as it may seem if adjusting for hidden costs (cost of power, admins of cloud, etc..)

• Weekly releases
  As mentioned above the team does weekly releases and this type of agile development has many benefits, which would perhaps be beneficial for us to replicate.

• Quick daily stand ups
  Useful in agile development, and even more so in teams like the SQuaRE team which are split between remote & in-office developers.

Overall, this was a positive and productive trip, both in terms of improving our experience on how to best operate and maintain the RSP, but also in terms of building a relationship with the Rubin SQuaRE team which will be beneficial for future work on the Rubin project.