diff --git a/da/doc/source/overview.rst b/da/doc/source/overview.rst index 603ef27e2eee976571e4118654d8ac2e86b46c52..9e3e0395b5fc6fe2867bf572115c6a2dd71ee3cf 100644 --- a/da/doc/source/overview.rst +++ b/da/doc/source/overview.rst @@ -10,14 +10,39 @@ This page gives a brief overview of CTDAS, with the intention to provide backgro What is CTDAS? -------------- +CTDAS is short for "CarbonTracker Data Assimilation Shell". +This is the implementation of an extendible data assimilation framework for CarbonTracker, +developed by NOAA ESRL & Wageningen University, in close cooperation with many partners around the world. + +The aim of the CTDAS system is to facilitate the use of CarbonTracker, and to +foster its development by its many international partners. + + How can you use CTDAS? ---------------------- +At its most basic, the CTDAS is a simple +control system for CarbonTracker that deals with the running, optimization, analysis, and time stepping of the system. +For advanced users, the CTDAS provides an easy way to extend or modify the system by introducing new configurations +for the state vector, for the observations, or even for the transport model or optimization method. CTDAS Design philosophy ----------------------- +CTDAS is implemented in python. Each component of the data assimilation system is written as a separate python class, which are +combined in a pipeline. Separate pipelines exist for an inverse simulation, or a forward run. Four classes compose the core of +the system: Observations, StateVector, ObservationOperator, and Optimizer. These are controlled by a CycleControl object, which +itself holds information from class PlatForm and class DaSystem. For each of these seven components, a "baseclass" exists that +describes the basic layout, and mandatory methods that each class needs to have. A specific implementation of a baseclass +"inherits" this basic behavior, and then extends or overwrites the methods. + +As a typical example: the baseclass class:`ObservationOperator` is a nearly empty object, that contains methods to Initialize() the ObservationOperator, to Validate() the input for it, to Run() the operator, and to SaveData() that is needed for a next cycle. The class TM5ObservationOperator is derived from this baseclass, and has a new implementation of each of these methods. When they are called in the pipeline, a TM5 model run is prepared and executed by the methods of the class, returning a set of samples for the optimizer to use in the +minimum least squares method. + +This design philosophy makes the pipeline completely independent of the specific implementation. It simply calls methods from the clasees it receives in a given order, and ensures that the flow of time and data works. The pipeline does not know (or need to know) whether it is running a gridded inversion with satellite data and the TM5 model without zoom, or whether it is running a methane inversion with TM3. The implementation is thus in the hands of the user. + Extending CTDAS --------------- +To extend CTDAS, one needs to write new classes that inherit from one of the baseclasses, and have specific functionality implemented under the methods called from the pipeline.