BoM/MO JEDI informal catchup, 29 May, 2020

Present: Chiara Piccolo, Stefano Migliorini, David Simonin, Peter Steinle, Fiona Smith, Andy Smith, Jin Lee

Broad outline of NG-OPS and NG-DA - Chiara

• NG-OPS is the name of the project; the actual software will be called JOPA (JEDI Observation Processing Application)
• After or with PS45 any further development of OPS will freeze
• Timeline and plans for NG-OPS
  • first phase finishing in early 2023
    • Aim for like-for-like: implement within JEDI all the processing currently available in OPS (inc 1D-Var)
    • Plan is to implement the software in operations in the first PS after the next HPC upgrade
    • Code required a year in advance of implementation (for testing etc) so needs to be ready by early 2022
  • second phase
    • New science will be added
    • Modularity and flexibility improvements
• Timeline and plans for NG-DA
  • Exploration began two years ago, but project officially started in April, and the plans are still immature with dates of implementation not fixed
  • Current proposal is for a system available to test with LFRic in Sep 2023; this will be 3D-Var
  • Again, the aim is to replicate capability, with hybrid 4D-Var. However, there is no TL/AD for LFRic, so interim approach using an ensemble method is being developed with Craig Bishop.
• There's a load of work to do
  • Partners are most welcome to take on part of the work
  • Workpackages in NG-DA require significant effort and often are big chunks of work that are hard to tackle in parallel whereas different workpackages in NG-OPS can progress more or less independently of others; so it's better for BOM to work on NG-OPS
• Will require concentration of effort and time - e.g. learning JEDI system and C++;
  • Chiara suggested that for each workpackage it's more efficient for BOM to devote 1 FTE instead of 2 x 1/2 FTE. The Met Office are not interested in contributions of <0.5 FTE.
  • David added that you can expect a minimum 2 month spin up, so even with 0.5 FTE you would only expect a couple of months of productive contribution
• Priority is the global for implementation, although technical requirements for observations such as GeoCloud and Radar that are only used in LAMS will of course be developed.
• Re UM Partnership and JEDI Academy, the intention is still to hold an Academy + Code Sprint in late 2020
  • Pointed out unlikely to be able to travel, so will need to discuss with Met Office and JCSDA how we can proceed
  • Also need Met Office to discuss how partner involvement works with JCSDA. They clearly still haven't thought about this much, but then they haven't even finalised their own legal agreements yet!

NG-OPS - David

• Workpackage 1 (WP1) is for the general infrastructure and writing kernels (basic generic processes, e.g. interpolation, column extraction, selection)
• WP2 is for processing different classes of observations and developing forward operators etc. These are split into sub-packages (based on organisational groupings within the Met Office - formerly SA, but now called "ASSO" and incorporating DA Methods):
  • Radiance observations led by Chawn Harlow
  • AMVs, scatterometer and GPS-RO led by Mary Forsythe
  • "Surface" (=="conventional", presumably) led by David Simonin
  • Products (e.g. cloud products) led by Roger Saunders and/or Heather Lawrence
• WP3 is about testing and parallel suite preparation - will be spun up later.
• Timeline:
  • By Apr 2022 have all the observation types in JEDI
  • By early 2023 aim to have this operational
• UKMO would be more than happy for BOM to take on work in any of these areas
  • Need to liaise with the package owners to work out where it is best to contribute
  • e.g. we could take on a particular observation type

NG-DA - Stefano

• NG-DA officially started in April; timeline still subject to change.
• By April 2021, Marek Wlasak is aiming to implement UKMO background error covariance model within SABER
  • parameter, horizontal and vertical transforms
  • use ECMWF's TRANS package for spectral transform as BUMP doesn't use spectral transform
  • Once this work is done, it will be easier to have contributions from partners - and it would be desirable to test with different ensemble configurations.
• By Sep, 2023 aim to implement 3DVar within JEDI to make sure there is a tool available for LFRic testing
  • First step is to compare 3DVar-JEDI with 3DVar-VAR both based on the UM
• for 4DVar use a linearised version of LFRic
  • finish testing linearised LFRic within JEDI by Sep, 2023
  • 4D-Var will not be implemented with the UM interface.
  • STFC to develop automatic differentiator for the TL/Adj of the dynamical core of GungHo via Psyclone
  • Interim plan is to use Local Ensemble Tangent Linear Model (LETLM; Craig Bishop and Tim Payne or Mike Cullen????) for the physics part of the linear version of LFRic
• By Dec 2024 have 4DVar with a linearised LFRic ready within JEDI
  • Assumption here is that JEDI and LFRic will go operational at the same time - it could be possible to delay JEDI but it's not desirable
  • backup plan is En4DEnVar if 4DVar performance unsatisfactory
  • assumption is that LFRic will be used and ENDGAME will retire
• Priority is the global but a lot of the work will be applicable to LAM
  • however, at the moment UKMO is not clear about the strategy for LAM
    • 2 options: En4DEnvar (favoured by Andrew Lorenc) vs. EnKF (favoured by Jonathan Flowerdew - new head DA Methods team)

Land Surface DA

• Not sure whether this is being handled under NG-OPS or NG-DA?
• The strategy is being mapped out this year - could be an area where we could contribute
• Work being done by Breo Gomez, Chris Harris and Sam Pullen

General comments on learning C++ and code development within JEDI

• it takes about 2 months for a scientist to learn enough JEDI, C++, etc. to be able to participate in code development
• Infrastructure and kernels will be written in C++, Fortran code such as RTTOV can be plugged in
  • People's contributions will depend on how comfortable each person is with C++ relative to Fortran.
  • Sometimes if Fortran code needs to be extensively modularised, it is easier to start from scratch in C++
• in UKMO they hold weekly informal meetings where people can raise questions on C++ and JEDI code and experts can present on topics of interest
• Initially an external provider was hired to provide web-based C++ training; found face-to-face or self-directed learning is a better option
• recommended contacting JEDI core development team before start making code changes
  • JEDI uses specific code design and it's better to find out if your planned code change conforms with their design in advance
  • need to keep in mind that JEDI is JCSDA code and there are certain constraints
  • Agile code development requires contributors to work fast and in small chunks
  • however the people in JEDI core development team are C++ experts and so seek their help