Photolysis mechanism: Difference between revisions

From Geos-chem
Jump to navigation Jump to search
No edit summary
 
(25 intermediate revisions by 3 users not shown)
Line 1: Line 1:
This page describes some of the updates to the FAST-J photolysis mechanism, as is currently implemented in GEOS-Chem.
Here we link to pages describing the various versions of the FAST-J and FAST-JX photolysis mechanisms used in GEOS-Chem.


== Input files for FAST-J ==
== Photolysis mechanisms used in standard GEOS-Chem versions ==


The following input files are required for the FAST-J photolysis mechanism:
The following photolysis mechanisms have been implemented in official releases of GEOS-Chem:


;[http://acmg.seas.harvard.edu/geos/doc/man/chapter_5.html#5.4.1 ratj.d]: This file is where you specify each of the FAST-J photolysis species.  Each species is mapped to a corresponding entry of the GEOS-Chem chemical mechanism.
=== FAST-JX v7.0 ===
;[http://acmg.seas.harvard.edu/geos/doc/man/chapter_5.html#5.4.2 jv_atms.dat]: This file specifies the reference O3 climatology for FAST-J.  NOTE: GEOS-Chem will overwrite this reference climatology with TOMS/SBUV data for those months and locations where such data exists.
;[http://acmg.seas.harvard.edu/geos/doc/man/chapter_5.html#5.4.3 jv_spec.dat]: This file is where the various quantum yields and aerosol cross-sections are specified.


=== Modifications for the grid-independent model===
The [[FAST-JX v7.0 photolysis mechanism]] is the newest version of the FAST-J software.  It was incorporated into [[GEOS-Chem v10-01]] by Sebastian Eastham (MIT) and the [[GEOS-Chem Support Team]], along with the [[UCX chemistry mechanism|UCX stratospheric-tropopsheric chemistry mechanism]].


'''''This update was tested in the 1-month benchmark simulation [[GEOS-Chem v9-01-03 benchmark history#v9-01-03k|v9-01-03k]] and approved on 27 Apr 2012. '''''
--[[User:Bmy|Bob Yantosca]] ([[User talk:Bmy|talk]]) 17:06, 16 November 2016 (UTC)


For the [[Grid-independent_GEOS-Chem|grid-independent model]], it was necessary to convert ASCII data files to netCDF format to allow for more efficient I/O. Bob Yantosca has converted the <tt>jv_atms.dat</tt> file to netCDF format, and has introduced code to read the netCDF equivalent file into GEOS-Chem. This file is available at:
=== FAST-J ===


  ftp://ftp.as.harvard.edu/pub/geos-chem/data/GEOS_NATIVE/FastJ_201204/fastj.jv_atms_dat.nc
The [[FAST-J photolysis mechanism]] was used in GEOS-Chem versions prior to [[GEOS-Chem v10-01]]. It has since been replaced by [[FAST-JX v7.0 photolysis mechanism]].


--[[User:Melissa Payer|Melissa Payer]] 15:41, 21 June 2012 (EDT)
--[[User:Bmy|Bob Yantosca]] ([[User talk:Bmy|talk]]) 17:07, 16 November 2016 (UTC)


== Overhead TOMS/SBUV merged O3 columns ==
== Photolysis mechanisms used in research versions of GEOS-Chem ==


=== GEOS-Chem v9-02 ===
The following photolysis mechanisms have been used in non-standard research versions of GEOS-Chem:


'''''This update was tested in the 1-month benchmark simulation [[GEOS-Chem_v9-02_benchmark_history#v9-02m|v9-02m]] and approved on 30 Jul 2013.'''''
=== FAST-JX v6.2 ===


Jenny Fisher has updated to TOMS overhead O3 columns to account for years through December 2010.  The data files are available at:
The [[FAST-JX v6.2 photolysis mechanism]] was implemented into several research versions of GEOS-Chem by Jingqiu Mao (Princeton).  But this version of FAST-J was never incorporated into the standard GEOS-Chem model.


ftp://ftp.as.harvard.edu/gcgrid/geos-chem/data/GEOS_NATIVE/TOMS_201203/
--[[User:Bmy|Bob Y.]] 11:58, 20 May 2014 (EDT)
ftp://ftp.as.harvard.edu/gcgrid/geos-chem/data/GEOS_2x2.5/TOMS_201203/
ftp://ftp.as.harvard.edu/gcgrid/geos-chem/data/GEOS_4x5/TOMS_201203/
 
You can download these directories with anonymous FTP or the Wget utility.  For instructions, please see [http://acmg.seas.harvard.edu/geos/doc/man/chapter_2.html#2.4 Chapter 2.4, Downloading the GEOS-Chem shared data directories] in the GEOS-Chem Online User's Guide.
 
Modifications to subroutine <tt>READ_TOMS</tt> in <tt>toms_mod.F</tt> include changing the directory name and updating the final year from 2008 to 2010.
 
==== Prevent 0.5 x 0.667 nested grid simulations from crashing when reading TOMS data ====
 
'''''Update 05 Mar 2014:''''' Jintai Lin provided a permanent solution for this issue, which will be applied in [[GEOS-Chem v10-01]]. For more information, see [[#Now use MAP_A2A to regrid 1x1 TOMS O3 to model resolution|this wiki post]].
 
'''''This issue was resolved in the [[GEOS-Chem v9-02]] public release (01 Mar 2014).'''''
 
'''''Luke Schiferl wrote:'''''
 
:I am attempting to run the standard nested NA 0.5x0.667 grid for v9-02. However, I'm missing the updated TOMS directory which is called, <tt>TOMS_201203</tt>, and the run crashes. Updated files are available on the Harvard ftp for 2x2.5 and 1x1, but not 0.5x0.667_NA.
 
As a temporary solution to prevent the nested grid simulation from crashing, we have added the fixes below to <tt>GeosCore/toms_mod.F</tt>. We will use the older TOMS data in <tt>TOMS_200906</tt> for the 0.5x0.667 nested grid simulations for now, until the data in <tt>TOMS_201203</tt> can be regridded.
 
      ! Define filename (with replaceable tokens)
#if  !defined( GCAP )
#if defined( GRID4x5 ) || defined( GRID2x25 ) || defined( GRID025x03125 )
      FILENAME = 'TOMS_201203/TOMS_O3col_YYYY.' // GET_NAME_EXT_2D() //
      &          '.'                            // GET_RES_EXT()
#else
      FILENAME = 'TOMS_200906/TOMS_O3col_YYYY.' // GET_NAME_EXT_2D() //
      &          '.'                            // GET_RES_EXT()
#endif
#else
      FILENAME = 'TOMS_200701/TOMS_O3col_YYYY.' // GET_NAME_EXT_2D() //
      &          '.'                            // GET_RES_EXT()
#endif
 
and at the top of the module:
 
#if defined( GRID4x5 ) || defined( GRID2x25 ) || defined( GRID025x03125 )
      INTEGER, PUBLIC, PARAMETER :: LAST_TOMS_YEAR  = 2010
#else
      INTEGER, PUBLIC, PARAMETER :: LAST_TOMS_YEAR  = 2008
#endif
 
--[[User:Melissa Payer|Melissa Payer]] 14:01, 20 March 2012 (EDT)
 
==== Now use MAP_A2A to regrid 1x1 TOMS O3 to model resolution ====
 
'''''This update was tested in the 1-month benchmark simulation [[GEOS-Chem v10-01 benchmark history#v10-01b|v10-01b]] and approved on 06 Mar 2014.'''''
 
'''''[mailto:jlin5@pku.edu.cn Jintai Lin] wrote:'''''
 
:With the update, the code basically reads the TOMS files on geos.1x1 grid,and then regrid to 4x5, 2x2.5 or 0.5x0.667. This ensures that all three resolutions start from the same TOMS files, and also that the 0.5x0.667 resolution model has the TOMS data. Currently, the directory <tt>TOMS_201203/</tt> containing new TOMS data is missing for the nested resolution model.
 
Code modifications apply to routine <tt>READ_TOMS</tt> (found in module <tt>GeosCore/toms_mod.F</tt>):
 
      USE DIRECTORY_MOD,  ONLY : DATA_DIR_1x1
      USE REGRID_A2A_MOD, ONLY : DO_REGRID_A2A
      CHARACTER(LEN=255) :: LLFILENAME
      REAL*4            :: ARRAY1x1(I1x1,J1x1,1)
      REAL*8            :: INGRID (I1x1,J1x1)
 
#if  !defined( GCAP )
      ! Define filename (with replaceable tokens)
!    FILENAME = 'TOMS_201203/TOMS_O3col_YYYY.' // GET_NAME_EXT_2D() //
!    &          '.'                            // GET_RES_EXT()
      ! Regrid from the files on geos.1x1 grid -- Lin_20140305
      FILENAME = 'TOMS_201203/TOMS_O3col_YYYY.geos.1x1'
      ! Replace YYYY token with current year
      CALL EXPAND_DATE( FILENAME, YYYYMMDD, 000000 )
      ! Now prefix the data directory
      FILENAME = TRIM( DATA_DIR_1x1 ) // TRIM( FILENAME )
      ! Echo filename
      WRITE( 6, 110 ) TRIM( FILENAME )
110  FORMAT( '    - READ_TOMS: Reading ', a )
      !=================================================================
      ! Regrid from 1x1 to model resolution
      !=================================================================
      ! File with lat/lon edges for regridding
      LLFILENAME = TRIM( DATA_DIR_1x1) //
    &            'MAP_A2A_Regrid_201203/MAP_A2A_latlon_geos1x1.nc'
      !-----------------------------
      ! TOMS O3 columns
      !-----------------------------
     
      ! Read data
      CALL READ_BPCH2( FILENAME, 'TOMS-O3',  1,
    &                XTAU,      I1x1,      J1x1,
    &                1,        ARRAY1x1,  QUIET=.TRUE. )
      ! Regrid to current model resolution
      INGRID = ARRAY1x1(:,:,1)
      CALL DO_REGRID_A2A( LLFILENAME, I1x1, J1x1,
    &                    INGRID,    TOMS,  IS_MASS=0,
    &                    netCDF=.TRUE.              )
      !--------------------------------
      ! d(TOMS)/dT (1st half of month)
      !--------------------------------
      ! Read data
      CALL READ_BPCH2( FILENAME, 'TOMS-O3',  2,
    &                XTAU,      I1x1,      J1x1,
    &                1,        ARRAY1x1,  QUIET=.TRUE. )
      ! Regrid to current model resolution
      INGRID = ARRAY1x1(:,:,1)
      CALL DO_REGRID_A2A( LLFILENAME, I1x1,    J1x1,
    &                    INGRID,    DTOMS1,  IS_MASS=0,
    &                    netCDF=.TRUE.              )
      !--------------------------------
      ! d(TOMS)/dT (2nd half of month)
      !--------------------------------
      ! Read data:
      CALL READ_BPCH2( FILENAME, 'TOMS-O3',  3,
    &                XTAU,      I1x1,      J1x1,
    &                1,        ARRAY1x1,  QUIET=.TRUE. )
      ! Regrid to current model resolution
      INGRID = ARRAY1x1(:,:,1)
      CALL DO_REGRID_A2A( LLFILENAME, I1x1,    J1x1,
    &                    INGRID,    DTOMS2,  IS_MASS=0,
    &                    netCDF=.TRUE.              )
#else
      ...
 
--[[User:Melissa Payer|Melissa Sulprizio]] 10:44, 5 March 2014 (EST)
 
==== Bug fix for determining when to use TOMS O3 columns ====
 
'''''This update will be tested in the 1-month benchmark simulation [[GEOS-Chem v10-01 benchmark history#v10-01c|v9-02c]].'''''
 
It was discovered after the [[GEOS-Chem v9-02]] public release that <tt>Input_Opt%USE_O3_FROM_MET</tt> might not be set properly for simulations using [[GEOS-5]] meteorology, so TOMS O3 columns might not be used. Traditionally, we use TOMS data when the simulation year is less than the last year of available TOMS data (currently 2010). In v9-02, the code to determine <tt>Input_Opt%USE_O3_FROM_MET</tt> was moved from subroutine <tt>GET_OVERHEAD_O3_FOR_FASTJ</tt> to the initialization stage at the top of <tt>main.F</tt>. In its new location, the variable <tt>YEAR</tt> was not defined properly and so <tt>Input_Opt%USE_O3_FROM_MET</tt> could be incorrect. To fix this issue, we have moved the code for determining <tt>Input_Opt%USE_O3_FROM_MET</tt> to just after the call to subroutine <tt>READ_MET_FIELDS</tt>.
 
        !==============================================================
        !          ****** R E A D  M E T  F I E L D S ******
        !
        !    For clarity, we have split off the code that reads met
        !    fields into the internal subroutine READ_MET_FIELDS.
        !    Lightning NOx emissions are also computed at the same
        !    time when A3 or A6 met fields are read from disk.
        !==============================================================
        CALL READ_MET_FIELDS()
#if  defined( GEOS_5 )
        ! When TOMS data is not available, then we will use
        ! the O3 columns directly from the met fields. 
        ! Currently, this is only done for GEOS-5 met.
        IF ( YEAR > LAST_TOMS_YEAR ) THEN
            Input_Opt%USE_O3_FROM_MET = .TRUE.
        ELSE
            Input_Opt%USE_O3_FROM_MET = .FALSE.
        ENDIF
#elif defined( GEOS_FP )
        ! For GEOS-FP met, always use the O3 columns
        ! from the A1 met field files (bmy, 11/14/13)
        Input_Opt%USE_O3_FROM_MET = .TRUE.
#else
       
        ! When TOMS data is not available, then we will use
        ! the TOMS data from the last valid year.  This is
        ! done for all met field products other than GEOS-5.
        Input_Opt%USE_O3_FROM_MET = .FALSE.
#endif
 
--[[User:Melissa Payer|Melissa Sulprizio]] 11:53, 11 March 2014 (EDT)
 
=== GEOS-Chem v8-01-04 ===
 
Bob Yantosca has updated the TOMS overhead O3 columns to account for years 2006 and 2007.  The data files are available at:
 
ftp ftp.as.harvard.edu
cd pub/geos-chem/data/GEOS_2x2.5/TOMS_200701/
get README
get TOMS_O3col_2006.geos.2x25
get TOMS_O3col_2007.geos.2x25
cd pub/geos-chem/data/GEOS_4x5/TOMS_200701/
get README
get TOMS_O3col_2006.geos.4x5
get TOMS_O3col_2007.geos.4x5
 
Also you will have to make a modification in the subroutine <tt>READ_TOMS</tt> in <tt>toms_mod.f</tt>.  Replace the following lines:
 
      ! Use 2005 data after 2005
      IF ( YEAR > 2005 ) THEN
        WRITE( 6, 105 ) YEAR
        YEAR = 2005
      ENDIF
   
with these lines:
 
      ! Use 2007 data after 2007
      IF ( YEAR > 2007 ) THEN
        WRITE( 6, 105 ) YEAR
        YEAR = 2007
      ENDIF
 
This will make sure the code uses the files for 2006 and 2007.
 
Here is an excerpt from the README that describes the TOMS data set versions that we are currently using:
 
  Data source and version:
  -------------------------
  1985 - 2005 are taken from:
    http://code916.gsfc.nasa.gov/Data_services/merged/index.html
    TOMS/SBUV MERGED TOTAL OZONE DATA, Version 8, Revision 3.
    Resolution:  5 x 10 deg.
    Contact person for the merged data product:
    Stacey Hollandsworth Frith (smh@hyperion.gsfc.nasa.gov)
  2006 and 2007 are taken from:
      http://code916.gsfc.nasa.gov/Data_services/merged/index.html
      Version 8 Merged Ozone Data Sets
      Revision 04
      DATA THROUGH: SEP 2008
      LAST MODIFIED: 20 OCT 2008
 
'''''NOTE: This fix was introduced into version [[GEOS-Chem v8-01-04|v8-01-04]].'''''
 
--[[User:Bmy|Bob Y.]] 14:15, 24 March 2009 (EDT)
 
== O1D reaction updated to JPL 2006 ==
 
The rate constants in the "FAST-J" [http://acmg.seas.harvard.edu/geos/doc/man/chapter_5.html#5.4.2 jv_atms.dat file] have been updated by Lin Zhang.
 
These were the old values:
 
O3_1d  180 9.500E-01 9.330E-01 4.270E-01 6.930E-02 6.060E-02      0.0      0.0
O3_1d  260 9.500E-01 9.420E-01 4.890E-01 1.360E-01 7.110E-02      0.0      0.0
O3_1d  300 9.500E-01 9.550E-01 5.870E-01 2.370E-01 8.570E-02      0.0      0.0
 
which are now replaced by the new values from JPL 2006: 
 
O3_1d  180 9.000E-01 9.000E-01 3.824E-01 8.092E-02 7.650E-02      0.0      0.0
O3_1d  260 9.000E-01 9.000E-01 4.531E-01 1.438E-01 7.654E-02      0.0      0.0
O3_1d  300 9.000E-01 9.000E-01 5.273E-01 2.395E-01 7.659E-02      0.0      0.0
 
Also the new file has the following header line (the O1D update is noted there):
 
jv_spec.dat:  FAST-J, std JPL 00 (mje 4/02) -- aer/dust (rvm, 3/02) -- O1D (lzh 5/06)
 
For more information, please contact Lin Zhang (linzhang@fas.harvard.edu).
 
--[[User:Bmy|Bob Y.]] 14:49, 14 January 2009 (EST)
 
== Cloud overlap options in FAST-J ==
 
GEOS-Chem now has 3 cloud overlap options in the FAST-J photolysis mechanism:
 
=== Linear cloud overlap assumption === 
 
The linear cloud overlap option is the default in GEOS-Chem versions [[GEOS-Chem_versions_under_development#v8-01-01|v8-01-01]] and prior.  The option is:
 
    Grid Box Optical depth = In-cloud optical depth * Cloud fraction. 
 
=== Approximate random overlap assumption === 
 
This approximate random overlap option was introduced into the standard code in
[[GEOS-Chem versions under development#v8-01-02|GEOS-Chem v8-01-02]]:
 
    Grid Box Optical Depth = In-Cloud Optical Depth * ( Cloud Fraction )^1.5
 
=== Maximum random overlap assumption ===
 
This maximum random overlap option is much more computationally intensive, and therefore is not used as the default option.  However, if you wish to use this option, then manually edit the <tt>fast_j.f</tt> source code file such that <tt>OVERLAP = 3</tt>. 
 
The Maximum-Random Overlap (MRAN) scheme assumes that clouds in adjacent layers are maximally overlapped to form a cloud block and that blocks of clouds separated by clear layers are randomly overlapped.  A vertical profile of fractional cloudiness is converted into a series of column configurations with corresponding fractions see Liu et al., JGR 2006; hyl,3/3/04).
 
For more details about cloud overlap assumptions and their effect on photolysis frequencies and key oxidants in the troposphere, refer to the following articles:
 
#Liu, H., et al., ''Radiative effect of clouds on tropospheric chemistry in a global three-dimensional  chemical transport model'', <u>J. Geophys. Res.</u>, '''111''', D20303, doi:10.1029/2005JD006403, 2006.
#Tie, X., et al., ''Effect of clouds on photolysis and oxidants in the troposphere'', <u>J. Geophys. Res.</u>, '''108'''(D20), 4642, doi:10.1029/2003JD003659, 2003.
#Feng, Y., et al., ''Effects of cloud overlap in photochemical models'', <u>J. Geophys. Res.</u>, '''109''', D04310, doi:10.1029/2003JD004040, 2004.
#Stubenrauch, C.J., et al., ''Implementation of subgrid cloud vertical structure inside a GCM and its effect on the radiation budget'', <u>J. Clim.</u>, '''10''', 273-287, 1997.
 
=== Discussion ===
 
'''''[mailto:hyl@nianet.org Hongyu Liu] wrote:'''''
 
:I have a comment about how the effect of cloud overlap in the vertical may be included in GEOS-Chem. The standard GEOS-Chem assumes linear scaling of cloud optical depth with cloud fraction in a grid box, i.e., the grid average cloud optical depth TAU' = TAU * f, where TAU is the COD in the cloudy portion of the grid and f is cloud fraction in the layer. This linear assumption (LIN) not only introduces a significant bias because of the nonlinear relationship between J-values and COD, but also is not consistent with the cloud-radiation interactions taking place in the original GEOS-DAS. Current GCMs or DAS usually use random overlap (RAN) or maximum-random overlap (MRAN) in their cloud-radiation packages.
 
:Ideally, GEOS-Chem should use the same cloud overlap assumption as the one used in GEOS-DAS where TOA radiative fluxes have been validated against e.g. satellite observations. But the ("exact") random overlap and MRAN approaches are computationally expensive. Fortunately, the so-called "approximate" random overlap scheme [TAU' = TAU * f^(3/2) which is computationally cheap] has been demonstrated to be a good approximation to both the "exact" random overlap and MRAN calculations. For details, see my GEOS-Chem cloud paper (section 2.3 & Figures 8d,9d:    http://research.nianet.org/~hyl/publications/liu2006_cloud1.abs.html
 
:So, if we don't want to use any cloud overlap assumptions because of computational cost, the "approximate" random overlap seems a good option - it makes more sense physically and is more consistent with the mother GCM or DAS.  Actually it has been used in the MOZART model for years [see Brasseur et al., 1998].
 
:Hongyu Liu
 
For more information, please contact Hongyu Liu (hyl@nianet.org).
 
--[[User:Bmy|Bob Y.]] 12:44, 23 May 2008 (EDT)
 
== Updated aerosol optical properties ==
 
Please visit our new [[Aerosol optical properties]] wiki page for more information about:
 
# [http://www.atmos.colostate.edu/~heald/docs/GEOS_Chem_optics_description.pdf Description of aerosol optical properties in GEOS-Chem]
# [[Aerosol optical properties#Aerosol optical properties update for GEOS-Chem v8-02-05|Aerosol optical properties update for v8-02-05]]
# [[Aerosol optical properties#Aerosol optical properties at high spectral resolution|Aerosol optical properties at high spectral resolution]]
 
--[[User:Bmy|Bob Y.]] 11:07, 1 March 2010 (EST)
 
== Scaling of AOD diagnostic output to other wavelengths ==
 
Colette Heald and Randall Martin have added a new capability to the [[GEOS-Chem v8-03-01]] diagnostics that will facilitate comparing GEOS-Chem data to satellite observations.  This was released as a [[#Post-release patches|patch]] shortly after the release of v8-03-01.
 
The aerosol optical depth (AOD) output computed by the following diagnostics:
 
# ND21 (output to the <tt>ctm.bpch</tt> file)
# ND48 (timeseries station data)
# ND49 (instantaneous timeseries output)
# ND50 (24-hr timeseries output)
# ND51 (satellite timeseries)
# ND51b (satellite timeseries)
 
can now be scaled from 400nm (i.e. the FAST-J wavelength) to any arbitrary wavelength.  A new file, <tt>jv_spec_aod.dat</tt>, has now been added to all of the GEOS-Chem v8-03-01 run directories.  This file can be edited to contain the optical parameters for the aerosols at the target wavelength.  Currently the default <tt>jv_spec_aod.dat</tt> is set up to scale AOD output from 400nm to 550nm. 
 
For more information, please see the [http://acmg.seas.harvard.edu/geos/doc/man/chapter_5.html#5.4.4 Section 5.4.4 of the GEOS-Chem v8-03-01 User's Guide].  This contains information about how to edit <tt>jv_spec_aod.dat</tt> for other wavelengths.
 
It is important to note that this capability does not change the scientific results of GEOS-Chem, but is just a new option for the diagnostic output.
 
--[[User:Bmy|Bob Y.]] 16:10, 28 May 2010 (EDT)
 
== Too many levels in photolysis code ==
 
The scattering module (<tt>OPMIE.f</tt>) for Fast-J requires many additional vertical levels. It happens that the limit (<tt>NL</tt> set in <tt>jv_mie.h</tt>) can be reached in some situations, causing the program to stop with a "Too many levels in photolysis code.." error message.
Sometimes you can increase <tt>NL</tt> to solve the problem.
 
Now a new version of <tt>OPMIE.F</tt> is available, which still warns you if <tt>NL</tt> is reached, but works with that limit.
 
This can also be an indication that there may be a problem in your visual optical depths, dust emissions, or aerosol emissions.  Dust and aerosol optical depths are computed from the concentration array <tt>STT</tt>.  If for some reason you end up emitting too much aerosol or dust (i.e. a unit conversion error), then this will result in an abnormally high dust or aerosol optical depth.  A very high optical depth will cause FAST-J to want to keep adding points to the Gaussian quadrature in <tt>OPMIE.F</tt>.  You can get into a situation where the number of points that FAST-J wants to add is greater than the array parameter <tt>NL</tt> (it may want to add thousands of points!).
 
Therefore, if you encounter this type of error, it is a good idea to doublecheck your aerosol & dust emissions to make sure that the monthly and annual totals are reasonable.
 
NOTES:
#In [[GEOS-Chem v8-03-01]] we have updated the <tt>NL</tt> parameter from 750 to 1500, which should prevent this error from happening in most circumstances.
#In [[GEOS-Chem v9-01-03]], the <tt>NL</tt> parameter is now 2000 (which makes <tt>N__</tt> = 4000).
 
--[[User:Bmy|Bob Y.]] 14:36, 17 December 2012 (EST)

Latest revision as of 19:47, 2 January 2019

Here we link to pages describing the various versions of the FAST-J and FAST-JX photolysis mechanisms used in GEOS-Chem.

Photolysis mechanisms used in standard GEOS-Chem versions

The following photolysis mechanisms have been implemented in official releases of GEOS-Chem:

FAST-JX v7.0

The FAST-JX v7.0 photolysis mechanism is the newest version of the FAST-J software. It was incorporated into GEOS-Chem v10-01 by Sebastian Eastham (MIT) and the GEOS-Chem Support Team, along with the UCX stratospheric-tropopsheric chemistry mechanism.

--Bob Yantosca (talk) 17:06, 16 November 2016 (UTC)

FAST-J

The FAST-J photolysis mechanism was used in GEOS-Chem versions prior to GEOS-Chem v10-01. It has since been replaced by FAST-JX v7.0 photolysis mechanism.

--Bob Yantosca (talk) 17:07, 16 November 2016 (UTC)

Photolysis mechanisms used in research versions of GEOS-Chem

The following photolysis mechanisms have been used in non-standard research versions of GEOS-Chem:

FAST-JX v6.2

The FAST-JX v6.2 photolysis mechanism was implemented into several research versions of GEOS-Chem by Jingqiu Mao (Princeton). But this version of FAST-J was never incorporated into the standard GEOS-Chem model.

--Bob Y. 11:58, 20 May 2014 (EDT)

Retrieved from "https://wiki.seas.harvard.edu/geos-chem/index.php?title=Photolysis_mechanism&oldid=40057"