Linoz stratospheric ozone chemistry

From Geos-chem
Jump to: navigation, search

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


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


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)


  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 GC_Error( ErrMsg, RC, ThisLoc )
     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:

            ! 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)