Traits, Factories, BUMP and Binding in Model Interfacing
This article delves into the use of Traits and Factories in handling class implementations within models. It covers the specific roles of Traits such as Geometry, State, and Increment, along with Factories like Model, Bias, Error Covariance, Localization, and Change Variables. BUMP, a generic implementation for covariance and localization, is also explored, along with the instantiation process using factories. The content further discusses B.Matrix, Static.B.YAML control, and Factory instantiation.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Model Interfacing II Traits, Factories, BUMP and Binding
Traits and Factories There are two ways of handling the specific implementation of classes in the models: Traits and Factories Traits are used when there s one specific implementation per class, e.g. geometry, state, increment. Factories are used when there are multiple potential implementations of a class, e.g. model, covariance, localization.
Model Classes CLASS DESCRIPTION METHOD Geometry Generates and contains grid information, processor layout etc. Traits State The variables by which the increment will interact with the model and all operations. Traits Increment The variables adjusted by the minimization, linear algebra needed for data assimilation. Traits Model Interaction with the nonlinear forecast model. Factory Model Bias Implementation of any bias correction to the model, IAU Traits TLM Interaction with the tangent linear and adjoint versions of the forecast model. Factory Error Covariance Multiply the increment by the error covariance model. Factory Localization Application of a localization matrix. Factory Change Variables Factory for changing variables. Factory
B Matrix Variable Change Variable Change Covariance model There are numerous ways to implement a B matrix for a particular model so it s handled in the code using a base class (<src>/oops/src/oops/base/ModelSpaceCovarianceBase.h). Specific implementations (sub classes) are instantiated using factories. E.g. using /generic/ErrorCovarianceBUMP.h or some model specific implementations.
Static B YAML control Call the FV3-JEDI covariance class. Requires a B matrix operator to be coded up in that FV3-JEDI sub class. Call BUMP. Only requires implementation of unstructured grid.
BUMP Completely generic implementation of covariance, standard deviation and localization. Convert the u-wind increment to the unstructured grid and then let BUMP works its magic!
Factory instantiation Instantiate the change of variable designated by VarChaC2MFV3JEDI. In the YAML we need to call as Control2Model Factory: the class VarChaC2MFV3JEDI is then implemented as normal. YAML: choose the subclass and the variables to be allocated.
VarChaC2MFV3JEDI Increment containing control variables comes in, increment with model variables goes out. The base class handles the allocation and deallocation either side.
FV3-JEDI Traits OOPS level State.h interface FV3-JEDI Templates passed in through Traits. Basically just a list of implemented classes.
Data assimilation application Many of the classes in OOPS are templated by the model, UFO and IODA. The passing of these templates is controlled through Traits (or factories). fv3jedi4DVar.cc: Include the model traits Include the factories Include the main application Pass config (YAML) Initialization step (FMS etc) Instantiate factories Create application object Assimilate
Class file structure All the model (and UFO) classes follow basically the same file structure: StateFV3JEDI.h fv3jedi_state_interface_mod.F90 State.h (OOPS) StateFV3JEDI.cc fv3jedi_state_mod.f90 StateFV3JEDIFortran.h Binding between C++ and Fortran is handled in these two files
Binding: C++ side GeometryFV3JEDI.cc GeometryFV3JEDIFortran.h
Binding: Fortran side fv3jedi_geom_interface_mod.F90 Access to the object is through a linked list Integer Key comes in, pointer to an object gets passed.
LinkedList inclusion At the interface_mod level the Linked List is created for the Fortran version of the object. linkedList_i.f contains the list of objects and linkedList_c.f contains the methods for manipulating and accessing the current object in the linked list.
linkedList_i.f Linked list node is where an object is actually stored in memory. It also contains a pointer to the next element. Class containing pointer to the head node. Methods for accessing that object.
linkedList_c.f: initilaize If linked list not initialized associate the head node and set the flags.
linkedList_c.f: add Key comes in from OOPS. Adding an object to the linked list so up the counter and set the key. Then allocate the next element. This is the actual allocation of memory for the object. Associate a pointer to the next element in the linked list.
linkedList_c.f: get Pointer comes in which needs to be associated with the object in the position in the linked list associated with the key. Do while loop sweeps the linked list until the key matches the point in the linked list.
