Changes between Version 1 and Version 2 of access/JEDIAtNCI/BoMMOJEDIMeeting20201209


Ignore:
Timestamp:
Dec 10, 2020 6:05:09 PM (2 years ago)
Author:
Jin Lee
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • access/JEDIAtNCI/BoMMOJEDIMeeting20201209

    v1 v2  
    55== Timeline of NG-OPS and NG-DA - David ==
    66
     7* Aiming to deliver NG-OPS by March 2023
     8  * to be used in 3DVar UM-JEDI and 3DVar LFRic-JEDI
     9  * assumption is that LFRic and NG-DA will be implemented together
     10  * plan to use ODB
     11* The NG-OPS and NG-DA projects are driven by supercomputer changes
     12  * avoid porting UM
     13  * Plan A: 4DVar using LFRic-JEDI and hybrid
     14  * Plan B: 4DEnVar and possibly EnKF for LAM
     15
    716== Possible areas of contribution ==
     17
     18* Best if partners take on workpackages which are not in the critical pth
     19  * work undertaken can be considered in stretch packages
     20* 3 possible work areas,
     21  1. Currently C++ JOPA calls Fortran. Helpful if all Fortran can be replaced with C++
     22  2. FSOI capability
     23     * UKMO is not planning to implement FSOI
     24     * depending on whether the global DA uses 4DVar or 4DEnVar the implementation of FSOI would be radically different: adjoint-based in the case of former and ensemble-based in the case of the latter
     25  3. Currently the 1DVar used in radiance processing is only an interface to Fortran. Useful if Fortran is replaced with C++. This is not entirely coding exercise
     26     * UKMO would like to use OOPS 1DVar
     27     * implement different minimisation method: e.g. Levenberg-Marquardt
     28     * Instead of processing column by column there might be a way to process all at once
     29     * TL and Adj need to written in C++
     30     * desirable to merge radiance and GPSRO 1DVar processing
     31* Already Jorge Bornemann (NIWA) has taken on a piece of work
     32  * IAU
     33  * LFRic-JEDI interface to Fortran (?)