IFS code overhaul & Object Oriented Programming: a likely evolution of our codes ?

This talk has been prepared by C. Fischer, freely extracting material and summarizing the talks and discussions that have taken place with ECMWF

Toulouse, Sept 20-22, 2010 Aladin/LACE/Hirlam maintenance training workshop

ECMWF’s view on the state of the IFS code

Toulouse, Sept 20-22, 2010 Aladin/LACE/Hirlam maintenance training workshop

Why to re-arrange the IFS code ?

• The IFS code has reached a very high level of complexity. • The maintenance cost has become very high.

• New cycles take longer and longer to create and debug.

• There is a long, steep learning curve for new scientists and visitors.

• It is becoming a barrier to new scientific developments such as long window weak constraints 4D-Var.

• Some algorithmic limitations: – Entities are not always independent => H^t R−1 H is one piece (jumble) of code.

– The nonlinear model M can only be integrated once per execution => algorithms that require several calls to M can only be written at script level.

Toulouse, Sept 20-22, 2010 Aladin/LACE/Hirlam maintenance training workshop

IFS growth: unfortunately, it’s not an investment: It’s growth of costs, not of benefits.

Toulouse, Sept 20-22, 2010 Aladin/LACE/Hirlam maintenance training workshop

Modernizing the IFS

• Re-assess « modularity »: – Define self-sufficient entities that can be composed, that define the scope of their variables (avoid « bug propagation ») => requires a careful understanding and definition of their interface – Avoid as much as possible global variables – Will require to widen the IFS coding rules and

break the « setup/module/namelist » triplet paradigm

• Information hiding and abstraction The above leads to

object-oriented programming

Toulouse, Sept 20-22, 2010 Aladin/LACE/Hirlam maintenance training workshop

Principles of OO programming

Toulouse, Sept 20-22, 2010 Aladin/LACE/Hirlam maintenance training workshop

Basics about OO-programming

• One key idea of Object-Oriented programming is to organize the code around the data , not around the algorithms.

• The primary mechanism used by object-oriented languages to define and manipulate objects is the class • Classes define the properties of objects, including: – The structure of their contents, – The visibility of these contents from outside the object, – The interface between the object and the outside world, – What happens when objects are created and destroyed.

Toulouse, Sept 20-22, 2010 Aladin/LACE/Hirlam maintenance training workshop

More basics about OO

• Encapsulation : content+scope of variables+interfaces (operators) put altogether • Inheritance : allows more specific classes to be derived from more general ones. It allows sharing of code that is common to the derived classes.

• Polymorphism/Abstraction: ../..

Toulouse, Sept 20-22, 2010 Aladin/LACE/Hirlam maintenance training workshop

Even more basics about OO

• Polymorphism : refers to the ability to re-use a piece of code with arguments of different types.

• Abstraction : refers to the ability to write code that is independent of the detailed implementation of the objects it manipulates. It allows algorithms to be coded in a manner that is close to their mathematical formulations.

Toulouse, Sept 20-22, 2010 Aladin/LACE/Hirlam maintenance training workshop

ECMWF’s toy model

Toulouse, Sept 20-22, 2010 Aladin/LACE/Hirlam maintenance training workshop

Toy OOPS (OO Prediction System)

• ‘Toy’ data assimilation system to try out Object Oriented programming for IFS • Abstract Part – Code the algorithm in terms of base classes which serve to define interfaces to the data structures & functions • can be compiled separately • In C++ • Implementations – Code Lorenz95 and QG models in terms of derived classes from the base classes which define data structures and functions • without change of abstract part • Computational code remains in Fortran95 Toulouse, Sept 20-22, 2010 Aladin/LACE/Hirlam maintenance training workshop

Toy OOPS implementations

LorenzMain QgMain incrementalAlgorithm Base Classes: Derived Classes: x State LorenzState QgState δx Increment LorenzIncrement QgIncrement y Observation LorenzObservation QgObservation y-H(x) Departure LorenzDeparture QgDeparture B BkgErrCov LorenzBkgErrCov QgBkgErrCov R ObsErrCov LorenzObsErrCov QgObsErrCov Toulouse, Sept 20-22, 2010 Aladin/LACE/Hirlam maintenance training workshop

Next steps in the toy

• At ECMWF: – Further develop and test ideas: OO construction and architecture – ODB & Jo (observations) – Other algorithms ?

• At MF & partners (Aladin, Hirlam): – Learn about the toy – “play with the toy”: install limited area model(s) Toulouse, Sept 20-22, 2010 Aladin/LACE/Hirlam maintenance training workshop

And for the IFS ? (in short)

Toulouse, Sept 20-22, 2010 Aladin/LACE/Hirlam maintenance training workshop

A proposal for the transition from IFS to OOPS

• The main idea is to

keep the computational parts of the existing code and reuse them in a re-designed structure

=> this can be achieved by a top-down and bottom-up approach.

• From the top : Develop a new modern, flexible structure =>

Expand the existing toy system

.

• From the bottom :

Move setup, namelists, data and code together

.

• C++/F95 breaking levels: STEPO and COBS/HOP ?

• Put the two together: Extract self-contained parts of the IFS and plug them into OOPS => this step should be quick enough for versions not to diverge.

Toulouse, Sept 20-22, 2010 Aladin/LACE/Hirlam maintenance training workshop

Feasibility study and towards IFS

• • At which level to split OO and standard F95 ? How far should OO go into the IFS ?: – Start with D.A. control; assess the interior of the forecast model(s) later =>

prototype with Jb and one obs operator

– Later: break STEPO, make GP buffers the natural vehicle for initializing and passing model data at OO-level (spectral transforms and data become an « optional » entity within the models) – Still later on, define grids and interpolators as Objects (both « base objects » and « instantiated objects »)

All these aspects will require further investigation & decision making

=> C++ & OO programming in the IFS/LAMs, depth of code cleaning and restructuring Toulouse, Sept 20-22, 2010 Aladin/LACE/Hirlam maintenance training workshop

Ancillary aspects

• If C++ is retained: training of NWP staff will be required • User interface: – Xml files:

no more namelists after OOPS

!!!

– Must preserve the facility to read in model parameters from a model input file (like with « FA » files; for LAM at least) – Change the S.C.R. tool at ECMWF ?: maybe move to Subversion or GIT • Documentation: needs to remain at a reasonable level (clean code is « auto-documentary ») Toulouse, Sept 20-22, 2010 Aladin/LACE/Hirlam maintenance training workshop

The end

Toulouse, Sept 20-22, 2010 Aladin/LACE/Hirlam maintenance training workshop