Linoz stratospheric ozone chemistry: Difference between revisions

From Geos-chem
Jump to navigation Jump to search
 
(4 intermediate revisions by 2 users not shown)
Line 20: Line 20:
=== Code structure ===
=== Code structure ===


The main-level <tt>Code</tt> directory has now been divided into several subdirectories:
The main-level <code>Code</code> directory has now been divided into several subdirectories:


  GeosCore/    GEOS-Chem "core" routines
  GeosCore/    GEOS-Chem "core" routines
Line 36: Line 36:
Linoz consists of the following files:
Linoz consists of the following files:


*<tt>GeosCore/linoz_mod.f</tt>: Source code file with Linoz chemistry subroutines
*<code>GeosCore/linoz_mod.f</code>: Source code file with Linoz chemistry subroutines
*<tt>GEOS_1x1/Linoz_200910/Linoz_March2007.dat</tt>: File with ozone climatology in the [[Downloading_GEOS-Chem_source_code_and_data#Primary_download_site|GEOS_1x1 data directory]]
*<code>GEOS_1x1/Linoz_200910/Linoz_March2007.dat</code>: File with ozone climatology in the [[Downloading_GEOS-Chem_source_code_and_data#Primary_download_site|GEOS_1x1 data directory]]


=== Additional Documentation ===
=== Additional Documentation ===
Line 46: Line 46:
'''''[mailto:dbj@atmosp.physics.utoronto.ca Dylan Jones] wrote:'''''
'''''[mailto:dbj@atmosp.physics.utoronto.ca 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 [[GEOS-Chem v8-02-01|v8-02-01]].  I accounted for the changes in the <tt>transport_mod.f</tt> 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.   
: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 [[GEOS-Chem v8-02-01|v8-02-01]].  I accounted for the changes in the <code>transport_mod.f</code> 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.
: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.
Line 73: Line 73:


== Previous issues that have now been resolved  ==
== Previous issues that have now been resolved  ==
=== Turn on Synoz when Linoz is set to false in input.geos ===
<span style="color:green">'''''This update was included in [[GEOS-Chem 12#12.0.0|GEOS-Chem 12.0.0]].'''''</span>
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 <span style="color:green">'''green'''</span>:
      ! 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
      <span style="color:green"><b>! Use Synoz if Linoz is turned off
      IF ( .not. Input_Opt%LLINOZ ) Input_Opt%LSYNOZ = .TRUE.</b></span>
--[[User:Melissa Payer|Melissa Sulprizio]] ([[User talk:Melissa Payer|talk]]) 12:04, 10 August 2018 (UTC)


=== Reactivate parallel DO loop in LINOZ_CHEMO3 ===
=== Reactivate parallel DO loop in LINOZ_CHEMO3 ===


'''''This update was tested in the 1-month benchmark simulation [[GEOS-Chem v9-02 benchmark history#1-month benchmark with GEOS-5 meteorology|v9-02r]] and approved on 14 Nov 2013.'''''
<span style="color:green">'''''This update was tested in the 1-month benchmark simulation [[GEOS-Chem v9-02 benchmark history#1-month benchmark with GEOS-5 meteorology|v9-02r]] and approved on 14 Nov 2013. This update is included in Adjoint [[GEOS-Chem_Adjoint_v35 | v35j]].'''''</span>
'''''This update is included in Adjoint [[GEOS-Chem_Adjoint_v35 | v35j]].'''''


The <tt>!$OMP PARALLEL DO</tt> loop in routine <tt>LINOZ_CHEM3</tt> was deactivated in [[GEOS-Chem v9-01-01]] because it previously caused an error that we could not resolve at the time.
The <code>!$OMP PARALLEL DO</code> loop in routine <code>LINOZ_CHEM3</code> was deactivated in [[GEOS-Chem v9-01-01]] because it previously caused an error that we could not resolve at the time.
      
      
Recent [[Tagged Ox simulation|tagged O3]] and [[NOx-Ox-HC-aerosol|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.
Recent [[Tagged O3 simulation|tagged O3]] and [[NOx-Ox-HC-aerosol|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.


--[[User:Bmy|Bob Y.]] 15:29, 14 November 2013 (EST)
--[[User:Bmy|Bob Y.]] 15:29, 14 November 2013 (EST)
Line 101: Line 121:
'''''[mailto:yantosca@seas.harvard.edu Bob Yantosca] wrote:'''''
'''''[mailto:yantosca@seas.harvard.edu Bob Yantosca] wrote:'''''


:You can always comment out the calls to both SYNOZ and LINOZ in routine <tt>DO_UPBDFLX</tt> (in <tt>upbdflx_mod.f</tt>).  See:
:You can always comment out the calls to both SYNOZ and LINOZ in routine <code>DO_UPBDFLX</code> (in <code>upbdflx_mod.f</code>).  See:


           IF ( ITS_A_FULLCHEM_SIM() ) THEN
           IF ( ITS_A_FULLCHEM_SIM() ) THEN
Line 132: Line 152:
'''''[mailto:psk9@duke.edu Prasad Kasibhatla] wrote:'''''
'''''[mailto:psk9@duke.edu 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 <tt>LINOZ_CHEM3</tt> (in <tt>linoz_mod.f</tt>, the column O3 above this altitude is not calculated owing to the <tt>CYCLE</tt> statement in this DO loop:
: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 <code>LINOZ_CHEM3</code> (in <code>linoz_mod.f</code>, the column O3 above this altitude is not calculated owing to the <code>CYCLE</code> statement in this DO loop:


             DO L = LM,LBOT,-1         
             DO L = LM,LBOT,-1         

Latest revision as of 18:55, 16 August 2018

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)