Difference between revisions of "Multi-mission Observation Operator (M2O2)"

From Geos-chem
Jump to: navigation, search
(Overview)
(Code Versions, Bug Fixes and Developments)
Line 18: Line 18:
 
     <ul>
 
     <ul>
 
         <li> Adjoint Code base : GEOS-Chem-Adjoint V34
 
         <li> Adjoint Code base : GEOS-Chem-Adjoint V34
 +
        <li> User Guide (http://adjoint.colorado.edu/~yanko/m2o2/GCA-M2O2-UserGuide.pdf)
 
     </ul>
 
     </ul>
 
   </ul>
 
   </ul>

Revision as of 04:55, 28 February 2014

Contact information

  • PI  : Meemong Lee / Jet Propulsion Laboratory, California Institute of Technology
  • Co-Is  : Kevin Bowman & Richard Weidner / Jet Propulsion Laboratory, Chris Lynnes /Goddard Space Flight Center, Daven Henze / University of Colorado, Boulder

Overview

The M2O2 task is supported by NASA's Advanced Collaborative Connections for Earth System Science (ACCESS) program.

The goal of the M2O2 task is to create a streamlined interface mechanism between the atmospheric chemistry model developers and the atmospheric sounding mission data providers. The M2O2 addresses a major challenge in utilizing the space-based observations within the atmospheric chemistry modeling and assimilation community, which involves linking between the model analysis and the observed atmospheric state in the level 2 mission data products (L2 data). The state-of-the-practice is to develop an observation operator for each atmospheric component of an atmospheric sounding mission, which often involves laborious data preparation. A wide range of observation operators with its own ad-hoc way of handling L2 data greatly hinders integration of observations from multiple missions. A generic observation operator that provides the link between the model analysis and mission observations requires an automated “assimilation-purpose” data preparation service and representation coordinate transformation.

The M2O2 task achieves the mission-generic assimilation via two step transformation processes, a data transformation process and a model transformation process. The data transformation process prepares assimilation-ready data, referred to as L2# (L2-sharp)data from mission-unique level 2 data products while the model transformation provides an automated spatial and temporal resolution mapping between the model space and the L2# data space for computing the cost function. The data transformation process has created a set of L2# data services including MLS-O3, TES-O3, AIRS-CO, and AOCS-XCO2 and the model transformation process has been integrated to GEOS-Chem Ajoint system. The L2# data services have been installed as web services and they are operational 24/7 by Goddard Earth System Data and Information Service Center (GESDISC) . The GCA-M2O2 code has been delivered to GEOS-Chem-Adjoint working group for maintenance and distribution.

Code Versions, Bug Fixes and Developments

    Previous GCA-M2O2 version released
      none

Summary of Main M2O2 Code Supported Features

  • L2# data services : L2# data is organized as daily Netcdf file.
    • ACOS-xCO2 (2009-2011)
    • AIRS-CO (2002-current)
    • MLS-O3 (2004-current)
    • TES-O3 (2006-2009)
  • Multi-mission Observation Assimilation : one or more mission observations can be simultaneously assimilated.
    • 3DVAR
    • 4DVAR

Distribution and Use

Code for the GCA-M2O2 is distributed through GITLAB, a web interface connected to a GIT server located at ajdoint.colorado.edu. You can access GITLAB at http://adjoint.colorado.edu:8080 after your account is created. Please refer to the Quick guide to GIT described under GEOS-Chem Adjoint wiki page.

Even if your office mate has a copy of the code, the best way to obtain the model is to get an account for yourself and download a version from the repository. So please do not copy code directly from others or pass the code along to third parties. This vastly helps with tracking developments and keeping up with model updates.

Use of the GCA-M2O2 code follows standard practice for GEOS-Chem-Adjoint. It is expected that any developments that come of individual applications based on this community model will eventually given back to the community by incorporation of new developments into the standard adjoint code. New development should be submitted to Daven Henze for inclusion in the standard adjoint model code.

Using GIT gives the users the ability to change the code and commit their changes without affecting the main repository hosted at the adjoint.colorado.edu. Users can work with their tuned versions of the code and even create their own tags because GIT acts as a local repository. When ready to submit your update to the community just send Daven Henze your patch and we'll take case of the rest.


Publications