Linoz stratospheric ozone chemistry

From Geos-chem
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

On this page we list information about the Linoz stratospheric ozone chemistry mechanism.

Overview

The Linoz stratospheric ozone chemistry package is a linearized chemistry mechanism for the stratosphere. It is designed to replace the older Synoz algorithm, which was a flux-based boundary condition that placed 500 Tg Ox/year through the tropopause.

It is recommended to use the Linoz option in your GEOS-Chem simulations.

Authors and collaborators:

  • Chris McLinden (UC Irvine ?)
  • Philip Cameron-Smith (LLNL)
  • Brendan Field (formerly Harvard)
  • Dylan Jones (U. Toronto)
  • Jane Liu (U. Toronto)

Implementation notes

Linoz has been implemented into GEOS-Chem v8-02-04.

Code structure

The main-level Code directory has now been divided into several subdirectories:

GeosCore/    GEOS-Chem "core" routines
GeosUtil/    "Utility" modules (e.g. error_mod.f, file_mod.f, time_mod.f, etc.
Headers/     Header files (define.h, CMN_SIZE, CMN_DIAG, etc.)
ISOROPIA/    Directory where ISORROPIA II code resides   
KPP/         KPP solver directory structure
bin/         Directory where executables are placed
doc/         Directory where documentation is created
help/        Directory for GEOS-Chem Help Screen
lib/         Directory where library files are placed
mod/         Directory where module files are placed
obsolete/    Directory where obsolete versions of code are archived

Linoz consists of the following files:

  • GeosCore/linoz_mod.f: Source code file with Linoz chemistry subroutines
  • GEOS_1x1/Linoz_200910/Linoz_March2007.dat: File with ozone climatology in the GEOS_1x1 data directory

Additional Documentation

Validation

Dylan Jones wrote:

Testing [the Linoz code in GEOS-Chem v8-02-04 was more difficult that I thought. I began by trying to compare the output of v8-02-04 with our previous runs with v8-02-01. I accounted for the changes in the transport_mod.f and I tried to undo the changes in when the diagnostics are archived in v8-02-04, but I was still getting large differences between v8-02-04 and v8-02-01. I finally gave up on this since I may have made a mistake in reverting to the old way of doing the diagnostics in v8-02-04. In the end I took the new linoz code from v8-02-04 and used it in v8-02-01. I ran two GEOS-5 full chemistry simulations for 2007 and the output were consistent over the full year.
I think that it is safe to release [Linoz in v8-02-04]. However, we should acknowledge that it was [only] tested in v8-02-01, since I was not able to assess the quality of the output in v8-02-04.

--Bob Y. 11:09, 4 February 2010 (EST)

Dylan Jones wrote:

...the stratospheric source of O3 in the code with linoz...I get a stratospheric source for 2006 of 572 Tg O3 for GEOS-4 and 502 Tg O3 for GEOS-5. Lee, I suspect that there is still a problem with the stratospheric flux diagnostic in GEOS-5, which is why we are getting unrealistically large source values using that approach. However, I haven't found the problem yet. So, after talking to Jennifer at the Aura meeting, I decided to use the tagged Ox simulation to get the source. I ran the model starting on Jan 1st with a stratospheric tracer that was initialized to 10 ppt everywhere in the troposphere and equal to the total Ox in the stratosphere. I then archived the monthly mean abundances and loss rates of the tracer and calculated the stratospheric source as follows.
For the stratospheric tracer in the troposphere:
   d[O3]/dt = Trans - f_loss 
where Trans is the total transport from the stratosphere (in g/s), f_loss is the loss rate integrated over the troposphere (in g/s), and [O3] is the total tropospheric burden of the tracer (in g). So the stratospheric source is:
  sum(Trans_i*dt_i) = sum( [O3]_i - [O3]_i-1 + f_loss_i*dt_i)  for i=1,12 months
where [O3]_0 is the initial 10 ppt. I used the annual mean tropopause for GEOS-4 and the monthly mean tropopause heights for GEOS-5. The tropospheric loss rates were calculated using Ox defined only as O3, NO2, and NO3.

--J. Mao 10:17, 19 Oct 2010 (EST)

References

  1. Mc.Linden, S.A., et al., Stratospheric ozone in 3-D models: a simple chemistry and the cross-tropopause flux, J. Geophys. Res., 105, 14653-14665, 2000.

Previous issues that have now been resolved

Turn on Synoz when Linoz is set to false in input.geos

This update was included in GEOS-Chem 12.0.0.

There was a bug in strat_chem_mod.F90 where SYNOZ will never be used. If LINOZ is turned off, then the code treats O3 like all other species and uses the UCX (formerly GMI) prod/loss rates. It looks like a logical LSYNOZ was added for GEOS-5 data assimilation applications during GEOS-Chem v11-01 development, but LSYNOZ is not set anywhere so it’s always False. This is easy to fix -- just set LSYNOZ to true if LLINOZ is false in input.geos. This bug fix only impacts tropchem-based mechanisms.

In routine READ_CHEMISTRY_MENU in GeosCore/input_mod.F, you can add the following lines in green:

     ! Use Linoz for stratospheric ozone? (Otherwise, Synoz is used)
     CALL SPLIT_ONE_LINE( SUBSTRS, N, 1, 'LLINOZ', RC )
     IF ( RC /= GC_SUCCESS ) THEN
        CALL GC_Error( ErrMsg, RC, ThisLoc )
        RETURN
     ENDIF
     READ( SUBSTRS(1:N), * ) Input_Opt%LLINOZ

     ! Use Synoz if Linoz is turned off
     IF ( .not. Input_Opt%LLINOZ ) Input_Opt%LSYNOZ = .TRUE.

--Melissa Sulprizio (talk) 12:04, 10 August 2018 (UTC)

Reactivate parallel DO loop in LINOZ_CHEMO3

This update was tested in the 1-month benchmark simulation v9-02r and approved on 14 Nov 2013. This update is included in Adjoint v35j.

The !$OMP PARALLEL DO loop in routine LINOZ_CHEM3 was deactivated in GEOS-Chem v9-01-01 because it previously caused an error that we could not resolve at the time.

Recent tagged O3 and full-chemistry simulations performed with the GEOS-Chem Unit Tester have shown that the parallel loop now functions properly when activated. Therefore, we have now re-activated this parallel DO loop in GEOS-Chem v9-02. As a result, we expect to see a gain in scalability for long tagged O3 and full-chemistry simulations.

--Bob Y. 15:29, 14 November 2013 (EST)

Unresolved issues

Turning Linoz off

Please note that when you turn Linoz off, GEOS-Chem will default to the older Synoz stratospheric chemistry scheme.

We recommend always using the Linoz stratospheric chemistry. However, if you have a special research need (i.e. sensitivity study) for which you need to disable both Linoz and Synoz, then please see the instructions below:

Also be advised that the TPCORE advection scheme will always bring a certain fraction of the stratospheric ozone into the troposphere regardless of whether or not the Linoz scheme is turned on.

Jaegun Jung wrote:

Is it possible to turn off stratospheric O3 generation or to not transport stratospheric O3 into troposphere? [If you turn off Linoz, will] it still turn on stratospheric chemistry but with an older scheme?

Bob Yantosca wrote:

You can always comment out the calls to both SYNOZ and LINOZ in routine DO_UPBDFLX (in upbdflx_mod.f). See:
         IF ( ITS_A_FULLCHEM_SIM() ) THEN

            !---------------
            ! Fullchem run
            !---------------

   !%%% Comment this out to shut off O3 from strat
   !%%%
   !%%%         ! Ox from strat 
   !%%%         ! dbj changed for linoz
   !%%%         IF ( LLINOZ ) THEN 
   !%%%            CALL DO_LINOZ
   !%%%         ELSE
   !%%%            CALL UPBDFLX_O3
   !%%%         ENDIF
   !%%%
   !%%%         ! NOy from strat
   !%%%         CALL UPBDFLX_NOY( 1 )
That will disable both options.

--Bob Y. 10:13, 18 April 2011 (EDT)

Crash caused by column ozone not being calculated properly

This is an as-yet unresolved issue. We are working to fix the problem.

Prasad Kasibhatla wrote:

I encountered a crash running GEOS-Chem v9-01-01 with GMAO GEOS-4 meterology and finally traced it to something that was going in in LINOZ. Basically, what seems to happening is that at a certain location, the Ox mixing ratio is 0 for some reason at a couple of altitudes near the tropopopause -- I assume that this is because of some issue related to a box switching between the tropopause and the stratopause. In any event, within routine LINOZ_CHEM3 (in linoz_mod.f, the column O3 above this altitude is not calculated owing to the CYCLE statement in this DO loop:
           DO L = LM,LBOT,-1        
              ...
              IF (STT(I,J,L,NTRACER) .LE. 0.D0) CYCLE     
At the next lower altitude, where Ox is greater than 0 the column O3 calculation requires the column O3 value at the next higher level - and in my run for some reason an absurdly large number is used since it was not calculated.
Perhaps a fix for this would be to add a statement to the effect:
   colo3(i,j,l) = colo3(i,j,l+1) 
when a 0 Ox conc is encountered.

Dylan Jones wrote:

I will try running the code to see if I can reproduce the problem. The fix that you've suggested will work, but I am concerned that we could get pockets of low-ozone air being transported around in the upper troposphere. I will see if I can prevent this from occurring so that we don't need the fix.

--Bob Y. 12:34, 15 July 2011 (EDT)