Wet deposition
This page describes the current wet deposition scheme used in GEOS-Chem.
Overview
Original algorithm
The Harvard Atmospheric Chemistry Modeling Group developed a wet deposition scheme (including scavenging of soluble tracer in convective updrafts, as well as rainout and washout of soluble tracers) for the GMI model. This scheme was then implemented into GEOS-Chem. Jacob et al [2000] describes the algorithm in full. This scheme is also described in Liu et al [2001].
Further updates
The following update to the original wet scavenging algorithm will be added to GEOS-Chem following the v8-03-02 release:
Allow both washout and rainout when precipitation forms
Qiaoqiao Wang wrote:
- When there is new formation of precipitation in lower layer k, rainout will be applied to the whole precipitation area: max(Fk,Fk+1), considering the contribution of precipitation formation overhead. This will overestimate rainout effect when Fk+1 is much larger than Fk. Therefore, we now apply rainout effect to precipitation area Fk and washout effect to the area: max (0, Fk+1-Fk) in the same grid box.
NOTE: This update was incorporated into GEOS-Chem v9-01-01.
Updates for aerosol scavenging efficiency
Qiaoqiao Wang wrote:
- The bulk below-cloud scavenging parameterization of Dana and Hales (k = 0.1P, where P is the precipitation rate mm h-1) used in the standard GEOS-Chem model integrates scavenging efficiencies over typical aerosol size distributions. This overestimates scavenging as it does not account for the preferential removal of the very fine and coarse particles over the course of the precipitation event, shifting the aerosol size distribution toward the more scavenging-resistant accumulation mode that accounts for most of aerosol mass. Now we use the below-cloud scavenging coefficients (k = a Pb constructed by Feng (2007, 2009)) integrated over accumulation mode for most aerosols and over coarse mode for coarse dust and sea salt.
--Bob Y. 15:50, 11 January 2011 (EST)
Updates for MERRA met fields
In GEOS-Chem v9-01-01, we have implemented an improved wet deposition scheme which uses the precipitation fields directly from the MERRA reanalysis product.
The wet deposition algorithm for GEOS-5 is relatively unchanged, except that we allow both rainout and washout to form within a grid box simultaneously. The wet deposition code has been partitioned into several new subroutines within wetdep_mod.f in order to allow for better compatibility with the wet deposition scheme used for the MERRA met fields.
--Bob Y. 14:12, 9 March 2011 (EST)
Add scavenging by snow
NOTE: This update is currently slated for inclusion into GEOS-Chem v9-01-03.
Qiaoqiao Wang wrote:
- For in-cloud scavenging by rain droplets, we assume 100% of water-soluble aerosols are rained out. But in the case of snow, only dust and hydrophobic BC are considered to be IN and then could be rained out. Note that HNO3 is also assumed to be rained out by snow as it forms a monolayer in ice crystal. The below-cloud scavenging coefficients are also higher for snow than for rain droplets.
--Bob Y. 14:14, 9 March 2011 (EST)
Validation
See Liu et al [2001].
References
- Dana, M.T., and J.M. Hales, Statistical aspects of the washout of polydisperse aerosols, Atmos. Environ, 10, 45-50, 1976.
- Domine, F., and E. Thibert, Mechanism of incorporation of trace gases in ice grown from the gas phase, Geophys. Res. Lett., 23, 3627-3630, 1996.
- Giorgi, F., and W.L. Chameides, Rainout lifetimes of highly soluble aerosols as inferred from simulations with a general circulation model, J. Geophys. Res., 91, 14,367-14,376, 1986.
- Jacob, D.J., Heterogeneous chemistry and tropospheric ozone, Atmos. Environ., 34, 2131-2159, 2000. PDF
- Jacob, D.J. H. Liu, C.Mari, and R.M. Yantosca, Harvard wet deposition scheme for GMI, Harvard University Atmospheric Chemistry Modeling Group, revised March 2000. PDF
- Levine, S.Z., and S.E. Schwartz, In-cloud and below-cloud scavenging of nitric acid vapor, Atmos. Environ., 16, 1725-1734, 1982.
- Liu, H., D.J. Jacob, I. Bey, and R.M. Yantosca, Constraints from 210Pb and 7Be on wet deposition and transport in a global three-dimensional chemical tracer model driven by assimilated meteorological fields, J. Geophys. Res., 106, 12,109-12,128, 2001. PDF
- Mari, C., D.J. Jacob, and P. Bechtold, Transport and scavenging of soluble gases in a deep convective cloud, J. Geophys. Res., 105, 22,255-22,267, 2000. PDF
- Selin, N.E. and D.J. Jacob, Seasonal and spatial patterns of mercury wet deposition in the United States: North American vs. intercontinental sources, Atmospheric Environment, 42, 5193-5204, 2008. PDF
- Wang, Q., D.J. Jacob, J.A. Fisher, J. Mao, E.M. Leibensperger, C.C. Carouge, P. Le Sager, Y. Kondo, J.L. Jimenez, M.J. Cubison, and S.J. Doherty, Sources of carbonaceous aerosols and deposited black carbon in the Arctic in winter-spring: implications for radiative forcing, Atmos. Chem. Phys., 11, 12,453-12,473, 2011. PDF
Previous issues that have been resolved
Negative tracer in routine WETDEP because of negative RH
See this post: GEOS-5 issues#Small negative RH value in 20060206.a6.2x25 file
Fixes are available at ftp://ftp.as.harvard.edu/pub/geos-chem/patches/v8-01-01.
--phs 16:31, 6 June 2008 (EDT)
Negative tracer in routine WETDEP
Dylan Millet wrote:
- I'm having a run die consistently at the same time (October 1, 2005; first time step of the month) in large-scale wetdep, with an STT element < 0.
- Platform: Linux cluster
- Threads: 8
- Version: v7-4-13 out of the box.
- GEOS4, 4x5, 30L, full chemistry
- IFORT 10.1
- In Section 6 (No Downward Precip) of wetscav_mod.f, subroutine safety is getting called.
WETDEP - STT < 0 at 1 1 29 for tracer 7 in area 6
- (First of all it seems odd to do wetdep for L=29, this is 63 km up). Have you seen anything like this? I ran for the whole year starting Jan 1 successfully until this point.
- ... By the way, the problem persists when I turn off chemistry altogether.
Philippe Le Sager replied:
- I used your restart file and the same input.geos (w/ chemistry on and off). My code went thru without problem. I tried both Sun Studio and Ifort 9 compilers, and the later on two different machines (altix and ceres). I used v7-04-13 and v8-01-01. I never reproduced your error.
- We just got the new Ifort 10, and tried it too. I run v8-01-01 without an error. But when I tried v7-04-13, I finally reproduced your error, with the exact same negative values!
- In other words: the bug happens with IFort 10 and v7-04-13 only.
- Also, have a look at this recent development. This is not the reason for your bug (I tried v8 w/ ifort 10 and isorropia -like v7-04-13- and it did not crash), but using RPMARES instead of Isorropia may be a way to fix it.
- ... More about the Ifort 10 / v7-04-13 issue. When I wanted to debug with TotalView, I could not reproduce the bug anymore.... because I simply suppress any optimization. So, I did more test and found that if the default -O2 optimization is used, GEOS-Chem crashes. But it works fine with -O1. It is hard to tell what happens, since only the emissions step is done between reading the restart file and the crash.
- Bob and I will further test Ifort 10 for optimization on our machines. Maybe we will find something... For the time being, you may have to switch to -O1, at least for the run that crashes. You will find the optimization flag at the beginning of the Makefile.ifort.
Long story short: This appears to be an optimization issue with IFORT 10 and v7-04-13. Upgrading to GEOS-Chem v8-01-01 should solve this problem.
--Bmy 10:38, 17 April 2008 (EDT)
Negative tracer in routine WETDEP #2
If you find find negative values caused by the wet deposition (particularly on data date 22 July 2010), then here is a workaround:
Mark Parrington wrote
- I'm getting negative values in the wet deposition and am having some difficulty in identifying a possible reason. I've experienced this problem in 3 different versions of the model (v8-02-01, v8-02-04, and v8-03-02) and have tried turning off the chemistry and changing the optimization. Has anyone else had a similar problem?
Claire Carouge replied:
- I don't know if this would help, but a crash on negative or NaN values in wet deposition doesn't always mean that there is a problem in wet deposition.
- GEOS-Chem has the subroutine CHECK_STT in GeosCore/tracer_mod.f. This function is used at some points in the code to check the concentration values (STT array) and stop the code if there is any negative, NaN, or Inf values. In particular, it's used in the wet deposition, but not before this point.
- I think the first thing to do is to identify were the bad values are created. You can insert calls to the CHECK_STT subroutine at different places in main.f (e.g. after transport, after PBL, after emissions, etc.) and see where the code stops. Then you can refine by adding the calls to CHECK_STT into the problematic subroutine and so on.
Mark Parrington followed up:
- I traced the bug to excessive evaporation in a subroutine called MAKE_QQ in wetscav_mod.f - which gives very small, ~1.0E-22, values of the accumulated precipitation (PREACC) leading to very large negative values of the convective fraction of precipitation (FRAC). To get around this I hard-wired the value of FRAC in MAKE_QQ to be 0.67 for the large scale fraction or else 0.33, if the value of PREACC is less than 1.0E-10 (around line number 474 in wetscav_mod.f v9-01-01):
! Large scale or convective fraction of precipitation
IF ( LS ) THEN
FRAC = ( PREACC(I,J) - PRECON(I,J) ) / PREACC(I,J)
! mp hack for -ve wet deposition
if ( preacc(i,j) .lt. 1.0E-10 ) frac = 0.67
ELSE
FRAC = PRECON(I,J) / PREACC(I,J)
! mp hack for -ve wet deposition
if ( preacc(i,j) .lt. 1.0E-10 ) frac = 0.33
ENDIF
- I was successfully able to run the model up to the end of October this way. I found this issue in v8-02-04 and v9-01-01 but only for the 2x2.5 simulation.
--Bob Y. 12:07, 28 April 2011 (EDT)
Outstanding issues
Values of F_PRIME greater than 1 in WETDEP
In GEOS-Chem v8-03-01, the value of the variable F_PRIME may end up being slightly greater than 1 under some circumstances. This can cause a negative tracer condition to occur in subroutine WETDEP of wetscav_mod.f.
Kelley Wells wrote:
- The following error message is continually produced in the 03 to 06 UTC time period of 29 July 2010 (2° x 2.5°, GEOS-5).
WETDEP - STT < 0 at 73 65 11 for tracer 1 in area 4
- We've determined that the issue is due to the variable F_PRIME being slightly greater than 1.0 at this point, thus resulting in F > 1.0 and finally RAINFRAC > 1.0. But, it's currently a mystery as to why F_PRIME is greater than 1.0, since both variables that go into its calculation (Q and K_RAIN) have positive values.
Dylan Millet wrote:
- The value of F_PRIME is only very marginally >1, so that
print*,f_prime gives 1.00000000
- but
print*,f_prime - 1d0 gives something on the order of 1E-12
- As best we can tell this is what gives the negative tracer value which causes the run to crash. Inserting a line of code setting:
F = MAX( F_PRIME, FTOP ) !### Kludge, don't let F be greater than 1 F = MIN( F, 1d0 )
- Seems to have fixed the issue. Perhaps we can be more careful and use a more elaborate IF test such as:
IF( ( ( F - 1d0 ) > 0d0 ) ) .and. ( ( F - 1d0 ) < 1d-6 ) ) THEN
F = 1d0
ENDIF
- which would catch this type of numerical instability error but not risk masking some other problem.
This type of error can be attributed to numerical instability. You can test by recompiling with the DEBUG=yes option, which will turn off all optimization. You might find that this error disappears when the optimization is turned off. However, turning off all optimization is only recommended for debugging purposes, as code that is not optimized will run much more slowly. Therefore, we recommend adding an IF statement (as shown above) to make sure that the value of F never exceeds 1.
NOTE: In GEOS-Chem v9-01-01 the wet deposition code was rewritten such that subroutine WETDEP was broken up into smaller subroutines, for better compatibility with the new MERRA wet scavenging algorithm. We are unsure if this condition exists in v9-01-01 as of this writing.
--Bob Y. 09:24, 11 March 2011 (EST)
Anomalous PRECTOT values on 22 July 2010
Several users have reported their 2° x 2.5° GEOS-5 simulations dying in the wet deposition module on 22 July 2010. We have traced this to an error in the GEOS-5 met fields. The PREACC variable in routine MAKE_QQ of wetscav_mod.F (which holds the GEOS-5 met field PRECTOT) contains the total precipitation at the ground. This should always be larger than the PRECON variable (which holds the GEOS-5 met field PRECCON), which is the convective fraction.
However, on at 06 GMT on 22 July 2010, the PREACC array contains some anomalous values (of the order 1e-20). This results in a situation where PREACC is larger than PRECON. Because the fraction of the precipitating box (FRAC) computed according to:
FRAC = ( PREACC(I,J) - PRECON(I,J) ) / PREACC(I,J)
then, this can lead to an (unphysical) large negative value for FRAC.
We recommend the following kludge. Add the following code in routine MAKE_QQ:
!==============================================================
! %%%%% FOR ALL OTHER MET FIELDS EXCEPT MERRA %%%%%
!==============================================================
IF ( PREACC(I,J) > 0d0 ) THEN
! Large scale or convective fraction of precipitation
IF ( LS ) THEN
FRAC = ( PREACC(I,J) - PRECON(I,J) ) / PREACC(I,J)
ELSE
FRAC = PRECON(I,J) / PREACC(I,J)
ENDIF
!##################################################################
!### KLUDGE: On July 22, 2010, there is an error where PREACC
!### is set to a very small number (but nonzero). This causes
!### FRAC to blow up to near infinity and PDOWN to be a very
!### large number. For now, limit FRAC to be between 0 and 1.
!###
IF ( FRAC > 1d0 ) FRAC = 1d0
IF ( FRAC < 0d0 ) FRAC = 0d0
!##################################################################
This will always make sure that the precipitating fraction of the grid box is between 0 and 1. Here is an example:
---> DATE: 2010/07/22 GMT: 06:00 X-HRS: 6.000
- Found all 33 A-3 met fields for 2010/07/22 07:30
- Found all 5 I-6 met fields for 2010/07/22 12:00
- LINOZ_CHEM3: Doing LINOZ stratospheric chemistry
### FRAC(99,75): -6.807457425009224E+016
### RESET FRAC(99,75): 0.000000000000000E+000
NOTE: Simulations done with the MERRA met fields are not affected because we use a different wet scavenging algorithm.
--Bob Y. 17:06, 1 December 2011 (EST)