Version 16 (modified by Jin Lee, 2 years ago) (diff)



In early 2020 UKMO formally commenced and committed substantial resources to the Next-Generation OPS (NG-OPS) and Next-Generation DA (NG-DA) projects. Both projects rely heavily on JEDI with UKMO concentrating development on components that it requires to implement its specific data assimilation schemes and observation processing. Their aim is to have JEDI-based DA system which is comparable to the current operational system ready by mid-2023 (the Bureau has not had access to the final project plans as of May 2020).

At the time of this writing (May 2020) the Bureau's position is uncertain as to how to respond to the development. Anticipating that the Bureau will commit commensurate resources to JEDI-based NG-OPS and NG-DA projects the Data Assimilation Team has begun familiarisation with various components of JEDI itself. This is to enable early adopters to explore opportunities to collaborate with their UKMO colleagues so that when the Bureau formally decides to participate in the NG projects as a part of a partnership-wide effort we are ready to make contributions with minimum spin-ups.

In this wiki page and the links in it we attempt to record various JEDI-related work undertaken by DA Team members.

Building and installing software stack for running JEDI applications

This section is for scientific computing support who will be maintaining the software stack used in running JEDI. Developers and users of JEDI subsystems and applications can skip this section.

JEDI applications depend on a large number of software packages. The group of packages needed to run various JEDI applications is referred to as jedi-stack. The scripts used to build the packages are hosted in one of the JCSDA github repositories (

Jin LEE and Wenming LU completed the initial build and installation of jedi-stack on Gadi. The name of the github branch used to build the software packages is feature/gadi. The site-specific instruction for building jedi-stack for Gadi can be found in a markdown. The initial installation is documented in the jedi-stack github issue #93. Some of the the decisions made at the time of the initial build/installation were provisional and there is an ample room for improvement. We list below some of these decisions which are not documented in the github issue.

  • The environment variable, OPT determines the top-level of the installation directory. We decided to use,
    export OPT=/projects/access/da/jedi/jedi-stack
  • The official releases of jedi-stack are now tagged. However we decided not to affix to modulefiles the tag as our jedi-stack pre-dates the decision to start tagging. We have need to use tags later to improve traceability (see further discussion in the github issue #93 .
    • Mark Miesch (core development team, JCSDA, suggested that a minor change to one or more packages of jedi-stack may not warrant a new release (see the github issue #93). Hence he recommended upgrading those specific packages manually and then creating a meta-module with a different name. We see a potential problem with this approach: deciding whether an upgrade to a package is minor or not may not be so straighforward as the minor change may affect other packages. We will have to see how well this initial jedi-stack installation supports the running of JEDI applications and prepared to revise the way our installations are managed and named.
  • We recommend scientific computing who will be maintaining jedi-stack to keep a close eye on the JEDI Teams page ( for any announcement related to jedi-stack. The official jedi-stack releases are in the github jedi-stack releases.

Running JEDI subsystems and applications

First obtain a github account. However, this will not allow you to access the private repositories used by common JEDI subsystems and applications. JEDI Academy has kindly provided a temporary github user account for us to use. Follow the steps below,

  1. Create a Git credentials file, ${HOME}/.git-credentials and put details of JEDI Academy temporary account,
  1. Follow this link in the main JEDI user documentation to configure Git.
    1. To use Git LFS use git/2.24.1 or later
  1. Set up your environment by loading the jedi-stack meta-module,
export OPT=/projects/access/da/jedi/jedi-stack
module purge
module use ${OPT}/modulefiles/apps
module load jedi/gcc-system_openmpi-3.1.4

Note that jedi-stack has its own set of Python packages (exclusively Python3).

  1. Try building and running ufo-bundle: see this link in the main JEDI user documentation

2020 JEDI Academy tutorial

Now, you are ready to get your hands dirty! Try the tutorial exercises from the JEDI Academy held in Monterey in 2020. All the lecture slides and tutorial instructions are in

I recommend that you read Presentation Slides given on each day and then attempt Interactive Activities listed under the same day. The course at the Academy was 4 days long but this will not be the case when you are doing self-paced learning. Please contact Jin LEE ( when you get stuck. Good luck and may the force be with you!


There are various tools used in JEDI and many of them are third-party software. For most JEDI subsystems documentation can be built by supplying suitable variables to ecbuild and targets to make. Provisionally we will store those documents under the following directory on accessdev,


To be able to browse the documents using your browser go to the URL,

and then look for the relevant JEDI component.

Next Step: lfric-bundle

Marek Wlasak (UKMO) put together a rose-stem test suite for running LFRic in JEDI. The suite also runs 4DEnVar, 3DVar etc. The suite is hosted on one of the private JCSDA repositories and is named lfric-bundle.

Most likely our involvement with JEDI will be through the UKMO's projects, NG-OPS and NG-DA. So we will need to become familiarised with lfric-bundle.