Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Yannick then introduced our featured speaker of the day, Willem DeconnickDeconinck, who is the lead developer of Atlas for ECMWF.  After some technical difficulties, Willem proceeded to present the following slides


Atlas was originally developed to explore and support new numerical schemes for the IFS forecast system at ECMWF, particularly finite volume methods based on unstructured meshes.  It was introduced in 2017 and is now available as an open source project distributed by ECMWF on Github.   Development continues at ECMWF, with ongoing contributions from JCSDA, Met Office and MeteoFrance.   It is written in C++ with Fortran interfaces; each C++ class has a corresponding derived type in Fortran.


Using the NEMO ocean grid as an example, Willem described how new functionality can be incorporated into Atlas through plugins (slide 14).  These plugins are rendered as dynamic libraries that can be loaded at run time with no need to change any atlas code.   One advantage of this is that proprietary code can be kept private.

Atlas provides tools to help the user with actions such as grid parameter specification (see the atlas-grids tool example on slides 12 and 13). Willem added that by adding and registering new functionality through the plugin feature, the built-in tools will become accordingly aware of the plugin feature. For example, the atlas-grids tool will display grid specifications for the NEMO ocean grid when enabled through the plugin mechanism.

Grids of different resolution can be created with overlapping domain decompositions to minimize communication during interpolation (slides 16, 22, 23).  Interpolation for grids that do not have overlapping domain decompositions is less efficient but can be useful.  They are working on this capability but it is not yet available.


Jake asked if atlas can support an unstructured grid of any type.  Willem responded that a grid is just a collection of point points but interpreted the question in terms of a mesh.  Atlas can currently support a triangular or quadrilateral mesh or a combination of both.  He said this could be extended as needed.

Tom asked about the efficiency of the GPU performance that Willem described.  Willem answered that atlas is not doing computations itself - it enables GPU usage but benchmarking efficiency would depend on the application, which they have not yet done.  Willem added that atlas does take steps to optimize for GPU efficiency such as padding arrays to 32 elements to align with GPU caches.

There was another question about Andrew Lorenc asked how atlas handles ensembles.   Willem said that the object-oriented approach will let you create as many objects as you wish to represent an ensemble.  But, Yannick clarified the question and described how some applications may benefit from the ensemble member as the innermost dimension of a field.  Willem said that one could create a functionspace that did this but then there was some debate on how generic this would be.


Guillaume asked about the possibility of applying the interpolation in lat-lon space versus non-projected xy coordinates for some grids.  Willem responded that it should be possible to do either provided that there was no data loss such as applied smoothing applied in the projection, and provided that there is a regular analytic mapping from x,y to lat-lon (which is not the case for cubed sphere).  Dan also added that the fv3 developers are considering using the gridtools library that is now used optionally by atlas to improve efficiency in mesh operations.

Jake asked if Dan's work with the cubed sphere grid would eventually be incorporated into the Atlas code base. For now, the cubed sphere grid code will remain in JEDI, and folding it back into Atlas will be considered in the future.

Since we had exceeded our 1-hour meeting time by this point, the meeting was adjourned