TOMAS aerosol microphysics

From Geos-chem
Jump to: navigation, search

This page describes the TOMAS aerosol microphysics option in GEOS-Chem. TOMAS is one of two aerosol microphysics packages being incorporated into GEOS-Chem, the other being APM.

Overview

The TwO-Moment Aerosol Sectional (TOMAS) microphysics package was developed for implementation into GEOS-Chem at Carnegie-Mellon University. Using a moving sectional and moment-based approach, TOMAS tracks two independent moments (number and mass) of the aerosol size distribution for a number of discrete size bins. It also contains codes to simulate nucleation, condensation, and coagulation processes. The aerosol species that are considered with high size resolution are sulfate, sea-salt, OC, EC, and dust. An advantage of TOMAS is the full size resolution for all chemical species and the conservation of aerosol number, the latter of which allows one to construct aerosol and CCN number budgets that will balance.

Authors and collaborators


--Dan W. 11:53, 27 January 2010 (EST)

TOMAS User Groups

User Group Personnel Projects
Carnegie-Mellon University Peter Adams
Dan Westervelt
New particle formation evaluation in GC-TOMAS
Sensitivity of CCN to nucleation rates
Development of number tagging and source apportionment model for GC-TOMAS
Dalhousie University
Colorado State
Jeffrey Pierce
Sal Farina
Stephen D'Andrea
Sensitivity of CCN to condensational growth rates
TOMAS parallelization
Others...
Add yours here

--Bob Y. 16:35, 12 May 2014 (EDT)

TOMAS-specific setup

TOMAS has its own run directories (run.Tomas) that can be downloaded from the Harvard FTP. The input.geos file will look slightly different from standard GEOS-Chem, and between versions.

Pre- v9.02: To turn on TOMAS, see the "Microphysics menu" in input.geos and make sure TOMAS is set to T.

v9.02 and later: TOMAS is enabled or disabled at compile time - the TOMAS flag in input.geos has been removed.


TOMAS is a simulation type 3 and utilizes 171-423 tracers. Each aerosol species requires 30 tracers for the 30 bin size resolution, 12 for the 12 bin, etc. Here is the (abbreviated) default setup in input.geos for TOMAS-30 in v9.02 and later (see run.Tomas directory):

Tracer #   Description   
  1- 62    Std Geos Chem 
     63    H2SO4              
 64- 93    Number             
 94-123    Sulfate            
124-153    Sea-salt           
154-183    Hydrophilic EC     
184-213    Hydrophobic EC     
214-243    Hydrophilic OC     
244-273    Hydrophobic OC     
274-303    Mineral dust       
304-333    Aerosol water

TOMAS-40 requires 423 tracers (~360 TOMAS tracers for each of the 40-bin species, and ~62 standard GEOS-Chem tracers)

--Salvatore Farina 18:48, 8 July 2013 (EDT)

Implementation notes

  1. The original implementation and validation of TOMAS had been done for version GEOS-Chem v8-03-01, which was released on 24 Feb 2010.
  2. TOMAS was completely re-integrated into GEOS-Chem v9-02, which was released on 03 Mar 2014.

Update April 2013

This update was tested in the 1-month benchmark simulation v9-02k and approved on 07 Jun 2013.

Sal Farina has been working with the GEOS-Chem Support Team to inline the TOMAS aerosol microphysics code into the GeosCore directory. All TOMAS-specific sections of code are now segregated from the rest of GEOS-Chem with C-preprocessor statements such as:

#if defined( TOMAS )

# if defined( TOMAS40 ) 
  ... Code for 40 bin TOMAS simulation (optional) goes here ...
# elif defined( TOMAS12 )
  ... Code for 12 bin TOMAS simulation (optional) goes here ...
# elif defined( TOMAS15 )
  ... Code for 15 bin TOMAS simulation (optional) goes here ...
# else
  ... Code for 30 bin TOMAS simulation (default) goes here ...
# endif

#endif 


TOMAS is now invoked by compiling GEOS-Chem with one of the following options:

Command Result
make -j4 TOMAS=yes ... Compiles GEOS-Chem for the 30 bin (default) TOMAS simulation
make -j4 TOMAS12=yes ... Compiles GEOS-Chem for the 12 bin (optional) TOMAS simulation
make -j4 TOMAS15=yes ... Compiles GEOS-Chem for the 15 bin (optional) TOMAS simulation
make -j4 TOMAS40=yes ... Compiles GEOS-Chem for the 40 bin (optional) TOMAS simulation

The -j4 in the above examples tell the GNU Make utility to compile 4 files at a time. This reduces the overall compilation time.

All files in the old GeosTomas/ directory have now been deleted, as these have been rendered obsolete.

These updates are included in GEOS-Chem v9-02. These modifications will not affect the existing GEOS-Chem simulations, as all TOMAS code is not compiled into the executable unless you compile with one of the TOMAS options (described in the above table) at compile time.

--Salvatore Farina 13:49, 4 June 2013 (EDT)
--Bob Y. 16:39, 12 May 2014 (EDT)

Computational Information

GC-TOMAS v9-02 (30 sections) on 8 processors:

  • One year simulation = 7-8 days wall clock time

More speedups are available using lower aerosol size resolution

--Dan W. 11:00, 07 May 2013 (EST)


GC-TOMAS v9-02 on 16 processors (glooscap)

Simulation Wall time / simulation year
TOMAS12 (optional) 2.8 days
TOMAS15 (optional) 3.3 days
TOMAS30 (default) 6.1 days
TOMAS40 (optional) 7.8 days

--Salvatore Farina 15:51, 3 March 2014 (EST)

Microphysics Code

The aerosol microphysics code is largely contained within the file tomas_mod.f. Tomas_mod and its subroutines are modular -- they use all their own internal variables. For details, see tomas_mod.f and comments.

Nucleation

The choice of nucleation theory is selected in the header section of tomas_mod.f. The choices are currently binary homogeneous nucleation as in Vehkamaki, 2001 or ternary homogenous nucleation as in Napari et al., 2002. The ternary nucleation rate is typically scaled by a globally uniform tuning factor of 10^-4 or 10^-5. Binary nucleation (Vehkamaki et al. 2002), ion-mediated nucleation (Yu, 2008) and activation nucleation (Kulmala, 2006) are options as well.

In TOMAS-12 and TOMAS-30, nucleated particles follow the Kerminen approximation to grow to the smallest size bin. This has a tendency to overpredict the number of particles in the smallest bins of those models. See Y. H. Lee, J. R. Pierce, and P. J. Adams 2013 here for more details on the consequences of this.

Condensation

Coagulation

--Dan W. 14:08, 9 May 2011 (EST)

Validation

The following figure documents the performance of GEOS-Chem-TOMAS for predicting aerosol number (N10 = number of particles larger than 10 nm etc.) against measurements at 20 global sites. Details of observations are in

  • D'Andrea, S. D., Hakkinen, S. A. K., Westervelt, D. M., Kuang, C., Levin, E. J. T., Kanawade, V. P., Leaitch, W. R., Spracklen, D. V., Riipinen, I., and Pierce, J. R.: Understanding global secondary organic aerosol amount and size-resolved condensational behavior, Atmos. Chem. Phys., 13, 11519-11534, doi:10.5194/acp-13-11519-11534, 2013.

GEOS-Chem-TOMAS performance update 20140304.png

--User:Jeff Pierce 13:21, 4 March 2014 (MST)

Other features of TOMAS

Other varieties of TOMAS are suited for specific science questions, for example with nucleation studies where explicit aerosol dynamics are needed for nanometer-sized particles.

Set-up Guide

This TOMAS setup guide was written for users on ACE-NET's Glooscap cluster, but may be more generally applicable.

--Salvatore Farina 11:55, 26 July 2013 (EDT)

Size Resolution

The different TOMAS simulations (12, 15, 30, 40 size bins) have the following characteristics:

Simulation Size resolution
TOMAS12 All 7 chemical species have size resolution ranging from 10 nm to 1 µm spanned by 10 logarithmically spaced (mass quadrupling) bins and two supermicron bins. Coarser resolution than TOMAS30 - Improved computation time.
TOMAS15 Same as TOMAS12 with 3 additional (mass quadrupling) sub-10nm bins with a lower limit ~2nm. Analogous to TOMAS40 with improved computation time.
TOMAS30 All 7 chemical species have size resolution ranging from 10 nm to 10 µm, spanned by 30 logarithmically spaced (mass doubling) bins.
TOMAS40 Same as TOMAS30 with 10 additional (mass doubling) sub-10nm bins with a lower limit ~1nm.

--Salvatore Farina 12:51, 4 June 2013 (EDT)

Nesting and grid size

TOMAS is implemented on a 2x2.5 North American domain. Developed by Jeffrey Pierce (jeffrey.pierce@dal.ca)

AOD, CCN post-processing code

Codes available for calculating aerosol optical depth using TOMAS predicted aerosol composition and size and Mie Theory. Also CCN concentrations calculated from TOMAS size-resolved composition and Kohler theory. Developed by Yunha Lee and Jeffrey Pierce, adapted for GEOS-Chem output by Jeffrey Pierce.

--Dan W. 2:00, 9 May 2011 (EST)

References

In this section we provide references relevant to TOMAS aerosl microphysics simulations.

Studies using TOMAS simulations

  1. Nucleation in GEOS-Chem: Westervelt, D. M., Pierce, J. R., Riipinen, I., Trivitayanurak, W., Hamed, A., Kulmala, M., Laaksonen, A., Decesari, S., and Adams, P. J.: Formation and growth of nucleated particles into cloud condensation nuclei: model-measurement comparison, Atmos. Chem. Phys. Discuss., 13, 8333-8386, doi:10.5194/acpd-13-8333-2013, 2013. LINK
  2. TOMAS implementation in GEOS-Chem: Trivitayanurak, W., Adams, P. J., Spracklen, D. V. and Carslaw, K. S.: Tropospheric aerosol microphysics simulation with assimilated meteorology: model description and intermodel comparison, Atmos. Chem. Phys., 8(12), 3149-3168, 2008.
  3. TOMAS initial paper, sulfate only: Adams, P. J. and Seinfeld, J. H.: redicting global aerosol size distributions in general circulation models, J. Geophys. Res.-Atmos., 107(D19), -, doi:Artn 4370 Doi 10.1029/2001jd001010, 2002.
  4. TOMAS with sea-salt: Pierce, J.R., and Adams P.J., Global evaluation of CCN formation by direct emission of sea salt and growth of ultrafine sea salt, J. Geophys. Res.-Atmos., 111 (D6), doi:10.1029/2005JD006186, 2006.
  5. TOMAS with carbonaceous aerosol: Pierce, J. R., Chen, K. and Adams, P. J.: Contribution of primary carbonaceous aerosol to cloud condensation nuclei: processes and uncertainties evaluated with a global aerosol microphysics model, Atmos. Chem. Phys., 7(20), 5447-5466, doi:10.5194/acp-7-5447-2007, 2007.
  6. TOMAS with dust: Lee, Y.H., K. Chen, and P.J. Adams, 2009: Development of a global model of mineral dust aerosol microphysics. Atmos. Chem. Phys., 8, 2441-2558, doi:10.5194/acp-9-2441-2009.
  7. TOMAS with SOA: D'Andrea, S. D., Hakkinen, S. A. K., Westervelt, D. M., Kuang, C., Levin, E. J. T., Kanawade, V. P., Leaitch, W. R., Spracklen, D. V., Riipinen, I., and Pierce, J. R.: Understanding global secondary organic aerosol amount and size-resolved condensational behavior, Atmos. Chem. Phys., 13, 11519-11534, doi:10.5194/acp-13-11519-11534, 2013.

--Bob Y. 09:53, 2 June 2014 (EDT)

Input data used by TOMAS

  1. Usoskin, I. G. and Kovaltsov, G. A., Cosmic ray induced ionization in the atmosphere: Full modeling and practical applications, J. Geophys. Res., 111, doi:10.1029/2006JD007150, 2006..
  2. Yu, Fangqun, et al, Ion-mediated nucleation in the atmosphere: Key controlling parameters, implications, and look-up table, J. Geophys. Res., 115, D03206, doi:10.1029/2009JD012630, 2010.

--Bob Y. 17:03, 24 February 2014 (EST)

Previous issues now resolved

Fixes for TOMAS simulation in v11-02c

These fixes will be included in v11-02c.

Sal Farina provided several updates to get the TOMAS simulation to work in v11-02c, including:

1) A patch for TOMAS to run in v11.02c (applies to 7c92951206e62). Prior to this fix, the TOMAS simulation was crashing because of 3D emissions added in v11-02a.

2) A TOMAS data file that has contained a typo for a long time. Sal added a leading space to each line for the formatted read to work correctly on negative numbers. The corrected file can now be found in GEOS_NATIVE/TOMAS_201402/YuIMN_AMOLF3D.txt (the original file is named with pre_v11-02a for record keeping).

3) A tweak to the UT for TOMAS to have longer timesteps than the other simulations (30/60, instead of 10/20) by default.

--Melissa Sulprizio (talk) 20:21, 26 June 2017 (UTC)

Minor bug in TOMAS sulfate emissions

This update was tested in the 1-month benchmark simulation v9-02o and approved on 03 Sep 2013.

Sal Farina wrote:

Calling mnfix before and after emission ensures the size distribution is well behaved, and eliminates "Negative SF emis" warnings. An edit to mnfix was also introduced, whereby "tiny" mass added to zero mass, "epsilon" number situations resulted in very high mass per particle results - necessitating excessive error detection, correction, and verbosity.

--Melissa Sulprizio 15:08, 7 August 2013 (EDT)

Segmentation Fault

You may get an early segfault if your stacksize is not set to either unlimited or a very large number. To avoid this, you either have to change the value of an environmental variable (setenv command in .cshrc) or use the ulimit command. See this page for details.

--Dan W. 20:20, 10 February 2010 (EST)

Updates for GEOS-Chem v9-02 public release

NOTE: As described below, there appears to be a potential parallelizaiton problem with the TOMAS ND60 diagnostic. We are currently looking into this. This issue, however, does not affect the tracer concentrations computed by TOMAS, but only the output of the ND60 diagnostic itself. For this reason we decided not to delay the GEOS-Chem v9-02 public release process. TOMAS benchmarks for v9-02 are currently being evaluated.

We have found and fixed several minor numerical and coding issues prior to the public release of GEOS-Chem v9-02 (03 Mar 2014). The TOMAS40 simulation has been validated with the GEOS-Chem Unit Tester. Below is the output of a unit test that was submitted on 2014/02/21 at 12:47:26 PM:

###############################################################################
### VALIDATION OF GEOS-CHEM OUTPUT FILES
### In directory: geos5_4x5_TOMAS40
###
### File 1    : trac_avg.geos5_4x5_TOMAS40.2005070100.sp
### File 2    : trac_avg.geos5_4x5_TOMAS40.2005070100.mp
### Sizes     : IDENTICAL (680420788 and 680420788)
### Checksums : IDENTICAL (179613338 and 179613338)
### Diffs     : IDENTICAL
###
### File 1    : trac_rst.geos5_4x5_TOMAS40.2005070101.sp
### File 2    : trac_rst.geos5_4x5_TOMAS40.2005070101.mp
### Sizes     : IDENTICAL (263480068 and 263480068)
### Checksums : IDENTICAL (1925551193 and 1925551193)
### Diffs     : IDENTICAL
###
### File 1    : soil_rst.geos5_4x5_TOMAS40.2005070101.sp
### File 2    : soil_rst.geos5_4x5_TOMAS40.2005070101.mp
### Sizes     : IDENTICAL (54040 and 54040)
### Checksums : IDENTICAL (3229970876 and 3229970876)
### Diffs     : IDENTICAL
###############################################################################

In the subsections below, we describe in more detail the fixes that we made for GEOS-Chem v9-02:

Fixes for minor coding errors

  1. In GeosCore/main.F, we now replaced CALL FLUSH() with CALL FLUSH(6). The FLUSH routine needs to take an argument. Unit #6 is the unit stdout (i.e. the screen and/or log file).

  2. In routine CHEM_SO2 (in module GeosCore/sulfate_mod.F), we now avoid referencing the dust tracers DST1, DST2, DST3, and DST4 tracers for TOMAS simulations. TOMAS uses size-resolved dust tracers, and therefore does not carry DST1-4 tracers. This error seems to have been introduced when the fix for cloud pH was introduced in Sep 2013.

  3. In routine COND_NUC (in module GeosCore/tomas_mod.F), we added error traps to avoid division-by-zero errors that occurred when the variable CSCH is zero. When CSCH is zero, we now set variable ADDT to zero. When ADDT is zero, it will get reassigned to a minimum time step, so this fix should work OK.

  4. In GeosCore/gamap_mod.F, we now have restored several entries to tracerinfo.dat for the ND44 diagnostic that were not getting properly printed out when the TOMAS simuation was being used.

  5. In module GeosCore/drydep_mod.F, we Now set MAXDEP=105 for all simulations, including TOMAS. Formerly, TOMAS had MAXDEP=100. This is close enough.

  6. In module GeosCore/diag3.F, we now avoid an out-of-bounds error in DEPNAME(N) during TOMAS simulations. We save the drydep species name from DEPNAME(N) into an new variable DRYDEP_NAME for N = 1..NUMDEP. We then set DRYDEP_NAME = for N > NUMDEP. This error occurs because we extend the # of drydep tracers during TOMAS simulations to account for the size bins.

  7. We have fixed a couple of logical errors that prevented dust emissions from happening. Minor modifications were made to IF statements in GeosCore/chemistry_mod.F, GeosCore/dust_mod.F, and GeosCore/input_mod.F.

  8. In file GeosCore/Makefile, make sure to add tomas_mod.o to the list of modules used by wetscav_mod.F (aka the "dependency listing"). The corrected code should look like this:

    wetscav_mod.o               : wetscav_mod.F                                  \
                                  dao_mod.o               diag_mod.o             \
                                  depo_mercury_mod.o      get_ndep_mod.o         \
                                  get_popsinfo_mod.o      tracerid_mod.o         \
                                  tracer_mod.o            tomas_mod.o

--Bob Y. 10:20, 19 February 2014 (EST)

Fixes for parallelization errors

  1. In routine AEROPHYS (in module GeosCore/tomas_mod.F), we need to add the following variables to the !$OMP+PRIVATE statement: TRACNUM, NH3_TO_NH4, and SURF_AREA. Adding these now causes TOMAS to have identical sp vs. mp results when chemistry and microphysics are turned on.

  2. In routine DEPVEL (in GeosCore/drydep_mod.F): Instead of holding A_RADI and A_DEN as !$OMP+PRIVATE in TOMAS simulations (in the main DO loop in DEPVEL), we now save the particle size and density values to private variables DIAM and DEN. We then pass those as arguments to function DUST_SFCRSII.

  3. We have corrected an issue in routine NFCLDMX (in module GeosCore/convection_mod.F) that potentially impacts the TOMAS wet scavenging, as described below:

    • We think there are different results for parallel and serial because of an assumption that's true for normal simulations but fails on TOMAS. The assumption is "tracers are independent through wet scavenging." Since TOMAS scavenging is size dependent, removing material from the distribution before calculating the soluble fraction of another component is "wrong." We now compute the fractions explicitly before the removal step. To do this, we now call routine COMPUTE_F in its own parallel DO loop located immediately before the main parallel do loop in NFCLDMX.

    • This modification also required the ND37 diagnostic IF block to be put into the same loop as COMPUTE_F. Furthermore, because COMPUTE_F returns the value of diagnostic index ISOL, and because ISOL is also used for the ND38 diagnostic in the main parallel loop below, we must also save the values of ISOL in a 1-D vector. This will allow the values of ISOL to be passed from the first parallel loop to the second. This ensures that the ND37 and ND38 diagnostics will be computed properly for all GEOS-5 simulations that have soluble tracers.

    • This modification has been tested in the GEOS-Chem Unit Tester by Bob Yantosca (04 Feb 2014) and it has yielded identical results for geos5_4x5_fullchem, geos5_4x5_Hg, geos5_4x5_RnPbBe, geos5_4x5_soa and geos5_4x5_soa_svpoa simulations.

  4. We have made some fixes in GeosCore/wetscav_mod.F that caused single-processor TOMAS runs to have different output than multi-processor runs. A few instances of code were computing quantities sequentially and then storing them for later use. These were technically thread-safe, but were susceptible to error because the order of computation would be different when running with parallelization turned on. These sections of code have now been rewritten accordingly.

--Bob Y. 14:09, 21 February 2014 (EST)

Removed inefficient subroutine calls

  1. In GeosCore/diag3.F, we now use a 2-D array (J-L) for archiving into the ND60 TOMAS diagnostic. This eliminates an array temporary in the call to routine BPCH2.

  2. In routine AEROPHYS (in module GeosCore/tomas_mod.F), we now use an array ERR_IND to pass the I,J,L,N indices to error checking routine CHECK_VALUE. We previously used an array descriptor (/I,J,L,0/) which caused an array temporary to be created.

  3. In routine EMISSCARBON (in module GeosCore/carbon_mod.F), we removed array temporaries from the calls to subroutine EMITSGC. We now sum two arrays into a temporary array, and then pass that to EMITSGC.

  4. We rewrote the subroutine calls to NH4BULKTOBIN to avoid the creation of array temporaries. In most cases this was done by replacing MK(1:IBINS,SRTSO4) with MK(:,SRTSO4), etc. By explicitly stating the sub-slice MK(1:IBINS,SRTSO4), this causes the compiler to create an array temporary. Using MK(:,SRTSO4) instead allows for a more efficient pointer slice to be passed.

--Bob Y. 14:47, 31 January 2014 (EST)

Fixes for convenience

We now read many of the TOMAS data files from the directory TRIM( DATA_DIR_1x1 ) // 'TOMAS_201402/'. This avoids us from having to keep these big files (some of which approach 100 MB in size) in individual users' run directories.

--Bob Y. 16:20, 31 January 2014 (EST)

Standard GC bulk dust is now unavailable in tomas simulations. Including the option for bulk dust in tomas simulations led to very confusing logical constructs, causing neither to function in a TOMAS simulation.

--Salvatore Farina 16:01, 3 March 2014 (EST)

Need to increase MAXCAT parameter in gamap_mod.F

This update was validated in the 1-month benchmark simulation v10-01c and approved on 29 May 2014.

In module GeosCore/gamap_mod.F, we had to increase the parameter:

      INTEGER,           PARAMETER   :: MAXCAT    = 150

by a little bit to account for the increased # of GAMAP diagnostic categories. We used:

      INTEGER,           PARAMETER   :: MAXCAT    = 160

and this worked just fine.

--Bob Y. 15:25, 11 April 2014 (EDT)

Prevent sea salt from being emitted over ice in TOMAS

This update was validated in the 1-month benchmark simulation v10-01c and approved on 29 May 2014.

Jeff Pierce wrote:

The FOCEAN (fraction of box that is ocean parameter) in TOMAS seasalt emissions didn't consider ice. I've modified it to do things more like the bulk emissions. In GeosCore/seasalt_mod.F, at line 1954, there is a line...
   FOCEAN   = 1d0 - State_Met%FRCLND(I,J)
I've updated this to be...
   IF ( IS_WATER( I, J, State_Met ) ) THEN
      FOCEAN   = 1d0 - State_Met%FRCLND(I,J)
   ELSE
      FOCEAN = 0.d0
   ENDIF
I couldn't figure out a way for FOCEAN to take into account the fraction that is land and fraction that is ice, so I will just use the IS_WATER to filter out boxes that are mostly ice. The box scheme is actually simpler and emits into the full box (or not) depending on the logical variable returned by function IS_WATER.

--Bob Y. 17:04, 30 May 2014 (EDT)

Fix for ND61 diagnostic

These updates were validated with the 1-month benchmark simulation v10-01e and approved on Approved 07 Nov 2014.

Betty Croft wrote:

Jeff and I found that the GEOS-Chem ND61 diagnostic (for TOMAS nucleation rates) was not working properly since AD61 was not initialized in initialize.F.
Please add the following line to initialize.F to correct this problem.
        IF ( ND61 > 0 ) AD61     = 0e0

--Melissa Sulprizio 10:27, 17 September 2014 (EDT)

Updates to TOMAS Jeagle sea salt extension

This update was included in the 1-month benchmark simulation v11-01j and approved on 03 Dec 2016

Jack Kodros wrote:

I recently made some updates to the TOMAS Jeagle sea salt HEMCO/Extensions file that allows for 12,30, and 40-bin TOMAS simulations (the previous version would run, just with unrealistic bin widths). If possible I would like the attached file the replace the former in the public release of version 11 (or any future development releases).

--Melissa Sulprizio (talk) 13:07, 18 July 2016 (UTC)

Add temporary fix to get TOMAS dry deposition to pass unit tests

This fix was included in the v11-01 provisional release.

We have reversed the order of the second parallel DO loop in TOMAS routine GeosCore/aero_drydep.F. This prevents a numerical roundoff error in the ND44 dry deposition diagnostic that was causing TOMAS unit tests to fail.

We added the code in GREEN at approx. line 410:

      ! Loop over chemically-active grid boxes
! %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
! %%% TEMPORARY FIX: REVERSE ORDER OF LOOPS IN ORDER TO PASS UNIT TESTS    %%%
! %%%                                                                      %%%
! %%% Sal Farina wrote: Change the loop order from LJI to IJL or JIL.      %%%
! %%% This will make the MP code add up the diagnostic in the same order   %%%
! %%% as SP mode (only the outermost loop gets parallelized). Yes looping  %%%
! %%% over LJI should be faster than IJL, but (and correct me if i'm       %%%
! %%% wrong) if we are looping over species inside that loop, all benefits %%%
! %%% are totally lost anyway. The way Spc / STT is defined, tracerid      %%%
! %%% should always be the outermost loop...                               %%%
! %$%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
!$OMP PARALLEL DO
!$OMP+PRIVATE( L, J, I, AREA_CM2, RKT, flux, JC, BIN )
!$OMP+PRIVATE( ID, X0, X, Y0, Y )
!$OMP+DEFAULT( SHARED )
!$OMP+SCHEDULE( DYNAMIC )
      DO I = 1, IIPAR
      DO J = 1, JJPAR
      DO L = 1, LLCHEM 

This prevents roundoff error due to a loss of numerical significance (as pointed out by TOMAS team member Sal Farina).

This is a temporary fix. The GCST will work with the TOMAS team to search for a more permanent solution.

--Bob Yantosca (talk) 18:05, 7 December 2016 (UTC)

Typo in wetscav_mod.F for TOMAS30 simulation

This fix will be included in v11-02c.

Jack Kodros wrote:

I found a minor typo in wetscav_mod.F in a TOMAS-only if statement (If defined (TOMAS30)). I believe I introduced this in v10 typing "KIMIN" in one instance instead of "KMIN". This typo only applied to 30-bin versions of TOMAS and not for the more popular 15 and 40 bin versions (and not for standard GEOS-Chem).

--Melissa Sulprizio (talk) 18:04, 18 May 2017 (UTC)

Unresolved issues

The following issues are still being worked on:

Reactivating dust tracers in TOMAS simulations

These updates were validated with the 1-month benchmark simulation v10-01e and approved on Approved 07 Nov 2014.

Jeff Pierce and David Ridley wrote:

Many of you are aware that recent versions of GEOS-Chem-TOMAS haven't worked with dust emissions on. The fix for this is actually quite simple (sorry it took me a while to get to this).
(1) In routine READ_AEROSOLS_MENU in module file GeosCore/input_mod.F, add the following USE statement:
   #if defined( TOMAS )
         USE TRACERID_MOD, ONLY : IDTDUST1
   #endif
(2) In READ_AEROSOLS_MENU, find this code (around line 1925 in G-C v9-02):
         !---------------------------------
         ! Error check DUST AEROSOLS
         !---------------------------------

         I = IDTDST1 + IDTDST2 + IDTDST3 + IDTDST4
and change it to:
         !---------------------------------
         ! Error check DUST AEROSOLS
         !---------------------------------

   #if defined( TOMAS )

         ! For TOMAS only: IF DUST1 is present, the other dust tracers are too
         I = IDTDUST1

   #else

         ! Non-TOMAS simulations: Need all DST1-DST4 tracers
         I = IDTDST1 + IDTDST2 + IDTDST3 + IDTDST4 

   #endif
(3) Add the following USE statements at the top of routine AEROSOL_CONC (in module GeosCore/aerosol_mod.F):
#if   defined( TOMAS ) 
      USE TRACERID_MOD,       ONLY : IDTDUST1
      USE TOMAS_MOD,          ONLY : IBINS
#endif
(4) Modify the following IF block in routine AEROSOL_CONC as described below. These modifications add the new code for TOMAS simulations, while preserving the original code for non-TOMAS simulations.
         !===========================================================
         ! M I N E R A L   D U S T   A E R O S O L S
         . . . etc . . .
         !===========================================================
#if defined( TOMAS )

         !-----------------------------------------------------------
         ! TOMAS simulations only 
         !-----------------------------------------------------------
         IF ( LDUST ) THEN

            ! Zero SOILDUST
            SOILDUST(I,J,L,:) = 0.d0

            ! Loop over the # of TOMAS dust bins
            DO K = 1, IBINS

               ! Bin #1
               IF ( Input_Opt%DUSTREFF(K) < 0.2D-6 ) THEN
                  SOILDUST(I,J,L,1) = SOILDUST(I,J,L,1)
     &                              + STT(I,J,L,IDTDUST1+K-1)  
     &                              / AIRVOL(I,J,L)


               ! Bin #2
               ELSE IF ( Input_Opt%DUSTREFF(K) < 0.325D-6 ) THEN
                  SOILDUST(I,J,L,2) = SOILDUST(I,J,L,2)
     &                              + STT(I,J,L,IDTDUST1+K-1) 
     &                              / AIRVOL(I,J,L)

               ! Bin #3
               ELSE IF ( Input_Opt%DUSTREFF(K) < 0.6D-6 ) THEN
                  SOILDUST(I,J,L,3) = SOILDUST(I,J,L,3)
     &                              + STT(I,J,L,IDTDUST1+K-1) 
     &                              / AIRVOL(I,J,L)

               ! Bin #4
               ELSE IF ( Input_Opt%DUSTREFF(K) < 1.15D-6 ) THEN
                  SOILDUST(I,J,L,4) = SOILDUST(I,J,L,4)
     &                              + STT(I,J,L,IDTDUST1+K-1) 
     &                              / AIRVOL(I,J,L)

               ! Bin #5
               ELSE IF ( Input_Opt%DUSTREFF(K) < 2.0D-6 ) THEN
                  SOILDUST(I,J,L,5) = SOILDUST(I,J,L,5)
     &                              + STT(I,J,L,IDTDUST1+K-1) 
     &                              / AIRVOL(I,J,L)

               ! Bin #6
               ELSE IF ( Input_Opt%DUSTREFF(K) < 3.25D-6 ) THEN
                  SOILDUST(I,J,L,6) = SOILDUST(I,J,L,6)
     &                              + STT(I,J,L,IDTDUST1+K-1) 
     &                              / AIRVOL(I,J,L)

               ! Bin #7
               ELSE 
                  SOILDUST(I,J,L,7) = SOILDUST(I,J,L,7)
     &                              + STT(I,J,L,IDTDUST1+K-1) 
     &                              / AIRVOL(I,J,L)

               ENDIF
            ENDDO

         ENDIF
#else

         !-----------------------------------------------------------
         ! Preserve original code for non-TOMAS simulations
         !-----------------------------------------------------------
         IF ( LDUST ) THEN

            ! Lump 1st dust tracer for het chem
            SOILDUST(I,J,L,1) = 
     &            0.06d0 * STT(I,J,L,IDTDST1) / AIRVOL(I,J,L)
            SOILDUST(I,J,L,2) =
     &            0.12d0 * STT(I,J,L,IDTDST1) / AIRVOL(I,J,L)
            SOILDUST(I,J,L,3) =
     &             0.24d0 * STT(I,J,L,IDTDST1) / AIRVOL(I,J,L)
            SOILDUST(I,J,L,4) =
     &            0.58d0 * STT(I,J,L,IDTDST1) / AIRVOL(I,J,L)

            ! Other hetchem bins
            SOILDUST(I,J,L,5) = STT(I,J,L,IDTDST2) / AIRVOL(I,J,L)
            SOILDUST(I,J,L,6) = STT(I,J,L,IDTDST3) / AIRVOL(I,J,L)
            SOILDUST(I,J,L,7) = STT(I,J,L,IDTDST4) / AIRVOL(I,J,L)
           
         ENDIF

#endif

--Bob Y. 15:30, 17 June 2014 (EDT)

Reactivating Ginoux dust emissions

After making the updates described above, modify the EMISSIONS MENU section of input.geos as follows
   Online DUST    AEROSOLS : T
    => Use DEAD emissions? : F

and run GEOS-Chem. This will turn on the Ginoux dust emissions.

--Bob Y. 15:30, 17 June 2014 (EDT)

Reactivating DEAD dust emissions

Info to be posted here shortly.

--Bob Y. 14:26, 16 June 2014 (EDT)

Offline Dust

NOTE: The fix described above will alleviate this bottleneck.

Currently, GEOS-Chem with TOMAS uses proscribed offline dust aerosol data in radiative transfer / photolysis calculations. Due to complications, this is turned off entirely for 2x2.5 resolution.

Potential parallelization problems

NOTE: This is still an open issue. It does not affect the simulation results but only the ND60 diagnostic output.

We have noticed that there may be a parallelization error in the TOMAS ND60 diagnostic. This may be caused by a coding error; in particular, one or more variables that may have been omitted from an !$OMP+PRIVATE declaration.

This is illustrated by the following unit test simulation of the GEOS-Chem v9-01-02 provisional release code (submitted at 2:11 PM on 21 Feb 2014):

###############################################################################
### VALIDATION OF GEOS-CHEM OUTPUT FILES
### In directory: geos5_4x5_TOMAS40
###
### File 1    : trac_avg.geos5_4x5_TOMAS40.2005070100.sp
### File 2    : trac_avg.geos5_4x5_TOMAS40.2005070100.mp
### Sizes     : IDENTICAL (707260156 and 707260156)
### Checksums : DIFFERENT (895530022 and 2949483685)
### Diffs     : DIFFERENT
###
### File 1    : trac_rst.geos5_4x5_TOMAS40.2005070101.sp
### File 2    : trac_rst.geos5_4x5_TOMAS40.2005070101.mp
### Sizes     : IDENTICAL (263480068 and 263480068)
### Checksums : IDENTICAL (1925551193 and 1925551193)
### Diffs     : IDENTICAL
###
### File 1    : soil_rst.geos5_4x5_TOMAS40.2005070101.sp
### File 2    : soil_rst.geos5_4x5_TOMAS40.2005070101.mp
### Sizes     : IDENTICAL (54040 and 54040)
### Checksums : IDENTICAL (3229970876 and 3229970876)
### Diffs     : IDENTICAL
###############################################################################

In the above test, all TOMAS diagnostics (ND59, ND60, and ND61) were turned on. The restart files (here named trac_rst.*) from the single-processor and multi-processor stages of the unit test are identical, but the ctm.bpch files (here named trac_avg.*) were different. When the restart files are identical, that means single-processor and multi-processor stages produced the identical tracer concentrations (and soil NOx quantities).

The only differences in the trac.avg.* files between the single-processor and multi-processor stages of the unit test were in TOMAS diagnostic quantities. The affected categories appear to be TMS-COND, TMS-COAG, TMS-NUCL, AERO-FIX, which points to the ND60 diagnostic.

In order to confirm that the ND60 diagnostic exhibits the problem, we ran an additional unit test with ND59 and ND61 turned on, but ND60 turned off. This unit test, which was submitted at 3:33PM on 21 Feb 2014, yielded identical results.

###############################################################################
### VALIDATION OF GEOS-CHEM OUTPUT FILES
### In directory: geos5_4x5_TOMAS40
###
### File 1    : trac_avg.geos5_4x5_TOMAS40.2005070100.sp
### File 2    : trac_avg.geos5_4x5_TOMAS40.2005070100.mp
### Sizes     : IDENTICAL (690218236 and 690218236)
### Checksums : IDENTICAL (4196844107 and 4196844107)
### Diffs     : IDENTICAL
###
### File 1    : trac_rst.geos5_4x5_TOMAS40.2005070101.sp
### File 2    : trac_rst.geos5_4x5_TOMAS40.2005070101.mp
### Sizes     : IDENTICAL (263480068 and 263480068)
### Checksums : IDENTICAL (1925551193 and 1925551193)
### Diffs     : IDENTICAL
###
### File 1    : soil_rst.geos5_4x5_TOMAS40.2005070101.sp
### File 2    : soil_rst.geos5_4x5_TOMAS40.2005070101.mp
### Sizes     : IDENTICAL (54040 and 54040)
### Checksums : IDENTICAL (3229970876 and 3229970876)
### Diffs     : IDENTICAL
###############################################################################

We are still looking into this issue. Because this issue only affects the ND60 diagnostic output, but not tracer concentrations, we are moving ahead with the TOMAS benchmarks for GEOS-Chem v9-02 (as of 21 Feb 2014).

--Bob Y. 16:17, 21 February 2014 (EST)

Vertical Grids

Currently, GC-TOMAS is only compatible with the reduced vertical grids:

Development for the full vertical grids is ongoing.

--Dan W. 20:43, 10 February 2010 (EST)

Obsolete versions of TOMAS

In this section we preserve information that pertained to older versions of TOMAS (before the GEOS-Chem v9-02 release).

Code structure

NOTE: This has been rendered obsolete by the re-integration of TOMAS into GEOS-Chem, which was included in GEOS-Chem v9-02. All of the TOMAS routines have now been ported into the GeosCore directory. We shall leave this post here for reference.

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

GeosCore/    GEOS-Chem "core" routines
GeosTomas/   Parallel copies of GEOS-Chem routines that reference TOMAS
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.)
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

Because there were a lot of TOMAS-related modifications in several GEOS-Chem "core" routines, the routines that need to "talk" to TOMAS were placed into a separate subdirectory named GeosTomas/. The files in GeosTomas are:

Files:
------
Makefile            -- GEOS-Chem routines that have been
aero_drydep.f          modified to reference the TOMAS aerosol
carbon_mod.f           microphysics package.  These are kept
chemdr.f               in a separate GeosTomas directory so that
chemistry_mod.f        they do not interfere with the routines
cleanup.f              in the GeosCore directory.
diag3.f
diag_mod.f             The GeosTomas directory only needs to
diag_pl_mod.f          contain the files that have been modified
drydep_mod.f           for TOMAS.  The Makefile will look for
dust_mod.f             all other files from the GeosCore directory
emissions_mod.f        using the VPATH option in GNU Make.
gamap_mod.f
initialize.f           NOTE to GEOS-Chem developers: When you
input_mod.f            make changes to any of these routines
isoropia_mod.f         in the GeosCore directory, you must also
logical_mod.f          make the same modifications to the
ndxx_setup.f           corresponding routines in the GeosTomas
planeflight_mod.f      directory.
seasalt_mod.f
sulfate_mod.f          Maybe in the near future we can work
tomas_mod.f            towards integrating TOMAS into the GeosCore
tomas_tpcore_mod.f90   directory more cleanly.  However, due to
tpcore_mod.f           the large number of modifications that were
tpcore_window_mod.f    necessary for TOMAS, it was quicker to
tracerid_mod.f         implement the TOMAS code in a separate
wetscav_mod.f          subdirectory.    
xtra_read_mod.f            -- Bob Y. (1/25/10)

Each of these files were merged with the corresponding files in the GeosCore subdirectory. Therefore, in addition to having the GEOS-Chem modifications from v8-03-01, these files also have the relevant TOMAS references.

A few technical considerations dictated the placing of these files into a separate GeosTomas/ directory:

  • The ND60 diagnostic in the standard GEOS-Chem code (in GeosCore/) is now used for the CH4 offline simulation, but in TOMAS it's used for something else.
  • Some parameters needed to be declared differently with for simulations with TOMAS.
  • Because not all GEOS-Chem users will choose to use TOMAS, we did not want to unnecessarily bog down the code in GeosCore/ with references to TOMAS-specific routines.

All of these concerns could be best solved by keeping parallel copies of the affected routines in the GeosTomas directory.

--Bob Y. 13:35, 25 February 2010 (EST)

Building GEOS-Chem with TOMAS

NOTE: This has been rendered obsolete by the re-integration of TOMAS into GEOS-Chem, which was included in GEOS-Chem v9-02. All of the TOMAS routines have now been ported into the GeosCore directory. We shall leave this post here for reference.

The VPATH feature of GNU Make is used to simplify the compilation. When GEOS-Chem is compiled with the tomas target, the GNU Make utility will search for files in the GeosTomas/ directory first. If it cannot find files there, it will then search the GeosCore/ directory. Thus, if we make a change to a "core" GEOS-Chem routine in the GeosCore/ subdirectory (say in dao_mod.f or diag49_mod.f), then those changes will automatically be applied when you build GEOS-Chem with TOMAS. Thus, we only need to keep in GeosTomas/ separate copies of those files that have to "talk" with TOMAS.

Several new targets were added to the Makefile in the top-level Code/ directory:

#=============================================================================
# Targets for TOMAS aerosol microphysics code (win, bmy, 1/25/10)
#=============================================================================

.PHONY: tomas libtomas exetomas cleantomas

tomas:
        @$(MAKE) -C $(GEOSTOM) TOMAS=yes all

libtomas:
        @$(MAKE) -C $(GEOSTOM) TOMAS=yes lib

exetomas:
        @$(MAKE) -C $(GEOSTOM) TOMAS=yes exe

cleantomas:
        @$(MAKE) -C $(GEOSTOM) TOMAS=yes clean

You can build GEOS-Chem with the TOMAS option by typing:

make tomas ...

This will automatically do the proper things to build the TOMAS code into GEOS-Chem, such as:

  • Adding a -DTOMAS C-preprocessor switch to the FFLAGS compiler flag settings in Makefile_header.mk. This will cause TOMAS-specific areas of code to be turned on.
  • Turning off OpenMP parallelization. For now the GEOS-Chem + TOMAS code needs to be run on a single processor. We continue to work on parallelizing the code.
  • Calling the Makefile in the GeosTomas/ subdirectory to build the executable. The executable file is now named geostomas in order to denote that the TOMAS code is built in.

The GEOS-Chem + TOMAS has been built on the following compilers

  • Intel Fortran compiler v10
  • Intel Fortran compiler v11.1 (20101201)
  • SunStudio 12

--Bob Y. 10:36, 27 January 2010 (EST)

Compile from GeosTomas directory

NOTE: This has been rendered obsolete by the re-integration of TOMAS into GEOS-Chem, which was included in GEOS-Chem v9-02. We shall leave this post here for reference.

Dan Westervelt wrote:

I think there is something going wrong in my compilation, although errors have come up at both compile time and run time. The worst of the problems is this: I'll make a change to any fortran file in the code (even something meaningless like print*, 'foo') and hundreds of compile errors come out with fishy error messages such as (from ifort v10.1):
 ***fortcom: Error: chemistry_mod.f, line 478: A kind type parameter must be a compile-time constant.   [DP]
          REAL(kind=dp) :: RCNTRL(20)
Any advice? The errors I'm having are not unique to any version of GC, any type of met fields, any compiler, etc.

Bob Yantosca wrote:

Make sure you are always in the GeosTomas subdirectory when you build the code. Sometimes there is a problem if you build the code from a higher level directory. This may have to do with the VPATH in the makefile.

Dan Westervelt wrote:

Thanks, that seems to do the trick.

--Bob Y. 14:37, 14 April 2010 (EDT)