W15 O3v2 Design Document

Owned by Renata McCoy
Last updated: Aug 02, 2019 by Michael J Prather
5 min read

The Design Document page provides a description of the algorithms, implementation and planned testing including unit, verification, validation and performance testing. Please read  Step 1.3 Performance Expectations that explains feature documentation requirements from the performance group point of view. 

Design Document

 Click here for instructions to fill up the table below ......

The first table in Design Document gives overview of this document, from this info the Design Documents Overview page is automatically created.

In the overview table below 4.Equ means Equations and Algorithms, 5.Ver means Verification, 6.Perf - Performance, 7. Val - Validation

  • Equations: Document the equations that are being solved and describe algorithms
  • Verification Plans: Define tests that will be run to show that implementation is correct and robust. Involve unit tests to cover range of inputs as well as benchmarks.
  • Performance expectations: Explain the expected performance impact from this development
  • Validation Plans: Document what process-based, stand-alone component, and coupled model runs will be performed, and with what metrics will be used to assess validity

Use the symbols below (copy and paste) to indicate if the section is in progress or done or not started.

In the table below 4.Equ means Equations and Algorithms, 5.Ver means Verification, 6.Perf - Performance, 7. Val - Validation,   (tick) - competed, (warning) - in progress, (error) - not done


Overview table for the owner and an approver of this feature

1.Description

Ozone (O3v2) 
2.OwnerQi Tang
3.Created
4.Equ(tick)
5.Ver(tick)
6.Perf(error)
7.Val(warning)
8.Approver
9.Approved Date
V2.0
 Click here for Table of Contents ...

Table of Contents




Title: Improved ozone (O3v2) 

Requirements and Design

E3SM Watercycle Group

Date:    

Summary

The redesigned ozone chemistry module (O3v2) replaces the current module (designated O3v1 here).  O3v2 retains the same linearized chemistry in the stratosphere used in O3v1, but it allows transport of the stratospheric ozone across the tropopause to be removed in the lower boundary layer, where a constant abundance is maintained (e.g., 30 ppb in current tests).  Ozone is an interactive tracer throughout the atmosphere and thus can respond to climatic changes such as a rising tropopause and simulate stratospheric folds around the jet stream and the stratosphere-to-troposphere exchange (STE) of ozone.  This fix enables more realistic simulations near the tropopause in 4x CO2 and future projection runs.  Including the surface sink allows the O3v2 module to diagnose the monthly latitudinal STE net O3 flux.  The STE flux is a direct, integrated measure of the stratospheric circulation such as Quasi-Biennial Oscillation (QBO) and Brewer-Dobson circulation (BDC).  
In terms of climate interactions, O3v2 is a great improvement over the O3v1 chemistry for which tropospheric O3 is locked into the 2-D Mozart climatology and does not respond properly to a changing stratosphere-troposphere interface, nor predict the pattern of ozone around the jet stream.  In terms of chemistry, O3v2 is a first step because the tropospheric ozone is maintained by a balance between STE flux and surface uptake.  The next versions will develop increasing more complex and realistic tropospheric chemistries that calculate tropospheric production and loss of ozone and well as other key greenhouse gases like methane.  O3v2 does not supplant the use of the O3v1 tropospheric climatology that supplied oxidants for the aerosol chemistry; but it does provide a full atmosphere (troposphere plus stratosphere) for use in the RRTM radiation module.  

Requirements

Requirement: minor changes in the Linoz module and some related physics code

Date last modified:  
Contributors: Qi Tang, Juno Hsu (Unlicensed), Michael J Prather


Each requirement is to be listed under a ”section” heading, as there will be a one-to-one correspondence between requirements, design, proposed implementation and testing. Requirements should not discuss technical software issues, but rather focus on model capability. To the extent possible, requirements should be relatively independent of each other, thus allowing a clean design solution, implementation and testing plan.


Algorithmic Formulations

Design solution:  Ensure that ozone is transported as a tracer throughout the atmosphere.  Add an ozone surface sink by applying an e-folding decay to 30 ppb with a 2-day time scale within the four lowermost layers of the atmosphere.  Turn off the code that resets the ozone values to climatological values in the troposphere. Also remove ozone from the dry deposition list.

Date last modified:  
Contributors: Qi Tang, Juno Hsu (Unlicensed), Michael J Prather


For each requirement, there is a design solution that is intended to meet that requirement. Design solutions can include detailed technical discussions of PDEs, algorithms, solvers and similar, as well as technical discussion of performance issues. In general, this section should steer away from a detailed discussion of low-level software issues such as variable declarations, interfaces and sequencing.


Design and Implementation

Implementation: Pull requests implemented O3v2 (https://github.com/E3SM-Project/E3SM/pull/3047)

Date last modified:  
Contributors: Qi Tang, Juno Hsu (Unlicensed), Michael J Prather


This section should detail the plan for implementing the design solution for requirement XXX. In general, this section is software-centric with a focus on software implementation. Pseudo code is appropriate in this section. Links to actual source code are appropriate. Project management items, such as svn branches, timelines and staffing are also appropriate. How do we typeset pseudo code?


Planned Verification and Unit Testing 

Verification and Unit Testing: 5-year and 20-year tests

Date last modified:  
Contributors: Qi Tang, Juno Hsu (Unlicensed), Michael J Prather


A 5-year test run with O3v2 has been completed and compared with the 5-year control run with the ozone calculated in E3SMv1 (O3v1).  The climates of these two runs, including ozone columns remain very similar. The magnitude of the O3v2 STE flux (integrated tropospheric loss) looks reasonable and approaches a state balancing the stratospheric influx within a couple of months from an initial state taken from O3v1.  An extended 20-year test further confirms that the O3v2 is implemented correctly and produces the expected results.  The pattern of STE flux is similar to the UCI CTM running O3v2 and also to other published results.

Planned Validation Testing 

Validation Testing: 20-year test and 4x CO2 simulation

Date last modified:  
Contributors: Qi Tang


The 20-year simulation is complete (as mentioned above). It verifies that the code is implemented correctly and the results are reasonable. A 4x CO2 is planned to examine the climate sensitivity changes. We have data sets for both total ozone column and stratospheric ozone column, monthly from 2004 based on NASA Aura satellite (Ziemke et al., 2019).  This period has a stable chemistry with an irregular but recurring Antarctic ozone hole, and thus the current linearized ozone chemistry in O3v2 is suitable.  It is important to separate the stratosphere from troposphere here as O3v2 stratospheric columns should be realistic, but the tropospheric columns will be biased because we lack pollution sources.  Nevertheless, the O3v2 tropospheric columns will vary in response to changes in STE flux driven by the QBO and BDC as they are in the data and we can look for such variability. 

Stratospheric ozone in the early MIPs was generally prescribed form a climatology and thus standard diagnostics as in the PCMDI Metrics Package have not included ozone.  With the chemistry-climate models, however, versions of Taylor diagrams for stratospheric ozone are appearing (Righi et al., 2015), and we will establish a standard one based on variability from seasonal to interannual time scales in which to measure the future O3v2 simulations. for this, a realistic QBO simulation is needed. 

Planned Performance Testing 

Performance Testing: short-desciption-of-testing-here

Date last modified:
Contributors: (add your name to this list if it does not appear)


How will XXX be tested? i.e. how will be we know when we have met requirement XXX. Will these unit tests be included in the ongoing going forward?