Linoz stratospheric ozone chemistry: Difference between revisions
No edit summary |
|||
(2 intermediate revisions by the same user not shown) | |||
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 === |
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 subroutinesGEOS_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
- 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
(inupbdflx_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
(inlinoz_mod.f
, the column O3 above this altitude is not calculated owing to theCYCLE
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)