Difference between revisions of "Aerosol thermodynamical equilibrium"

Latest revision as of 16:27, 18 June 2019

This page describes the aerosol thermodynamical equilbrium codes that are implemented into GEOS-Chem. These are:

ISORROPIA II

Newer version of the ISORROPIA scheme of Fountoukis and Nenes [2007]. This version has been the default ATE option for GEOS-Chem v8-03-01 and higher versions.

RPMARES

An implementation of the MARS-A scheme of Binkowski and Roselle [2003]. This is an alternative option.

ISORROPIA I

Previous version of the ISORROPIA scheme of Thanos Nenes et al. This version had been implemented into GEOS-Chem to replace the MARS-A scheme. However, this version of ISORROPIA has a bug which gives incorrect results at low RH values. For this reason, we used the MARS-A algorithm in versions GEOS-Chem v8-01-01 thru GEOS-Chem v8-03-01.

ISORROPIA II

This is an updated version of the ISORROPIA scheme [Fountoukis and Nenes, 2007], whose implementation into GEOS-Chem is described by Pye et al [2009]. For more information, please see our separate wiki page about ISORROPIA II.

--Bob Y. 16:08, 22 February 2010 (EST)

RPMARES

The RPMARES source code is contained in module rpmares_mod.f. It is currently only activated if the sea salt species are omitted from the simulation.

Bug in sulfate_mod.f caused by switch to RPMARES

NOTE: This fix was standardized in GEOS-Chem v8-01-02 and higher versions.

Lyatt Jaeglé wrote:

I've been trying to run v8-01-01 in an offline aerosol simulation. It seems to crash in sulfate_mod.f, at line 1892

   CALL GET_GNO3( I, J, L, HNO3_kg )

GET_GNO3 is in isorropia_mod.f, which is no longer called (I saw the discussion on the Wiki page), so I think that GAS_HNO3(I,J,L) is not defined.

What is the best way of fixing this? Should we simply set HNO3_vv to the monthly mean value of HNO3 read in GLOBAL_HNO3_MOD and bypass isorropia?

Bob Yantosca wrote:

The simple thing seems to be something like this:

    USE GLOBAL_HNO3_MOD, ONLY : GET_HNO3_UGM3
    USE DAO_MOD,         ONLY : AIRVOL

    ...

    IF ( ITS_A_FULLCHEM_SIM() ) THEN

       ! Convert HNO3 [v/v] to [equivalents]
       HNO3_vv = STT(I,J,L,IDTHNO3)
       HNO3_eq = HNO3_vv * AD(I,J,L) / ( 28.97d0 / 63d0 ) / 63.d-3

    ELSE

       !%%% Get gas-phase HNO3 from ISORROPIA code
       !%%%CALL GET_GNO3( I, J, L, HNO3_kg )
              
       ! Get HNO3 in ug/m3, then multiply by volume in m3
       ! and 1e-6 kg/ug to get HNO3 in kg
       HNO3_kg = GET_HNO3_UGM3( I, J, L ) * AIRVOL(I,J,L) * 1e-6

       ! Convert HNO3 [kg] first to [v/v]
       HNO3_vv = HNO3_kg * ( 28.97d0 / 63d0 )   / AD(I,J,L)

       ! Then convert HNO3 [kg] to [equivalents]
       HNO3_eq = HNO3_kg / 63d-3

    ENDIF

You might want to doublecheck the unit conversion but I think that's right.

--Bob Y. 16:18, 22 February 2010 (EST)

Run dies in RPMARES unexpectedly

Colette L. Heald reported a run dying silently in RPMARES.

Philippe Le Sager wrote:

Again aerosol chemistry is the problem. RPMARES algorithm is not handling every possible cases. I found that a negative concentration for H+ can be returned when solving a cubic equation. I made a general fix for it even though it may have been a case of underflow propagation when I caught one instance.

We previously take care of an overflow case when dealing with ionic activity coefficients, now with your restart file I came across an underflow issue. Instead of too small divisor, I got too large ones basically. The problem can happen either in the divisions or a little bit later when computing the A0 and A1 coefficients, i.e., at lines denoted with a @ here:

   DO NNN = 1, 50 ! loop count reduced 04/09/2001 by FSB
   NITR = NNN

   ! set up equilibrium constants including activities
   ! solve the system for hplus first then sulfate & nitrate
 @ RK2SA = K2SA * GAMAS2 * GAMAS2 / (GAMAS1 * GAMAS1 * GAMAS1)
 @ RKNA = KNA / ( GAMANA * GAMANA )
   RKNWET = RKNA * WH2O
   T21 = ZSO4 - MNH4
   T221 = ZSO4 + T21

   ! set up coefficients for cubic
   A2 = RK2SA + RKNWET - T21
 @ A1 = RK2SA * RKNWET - T21 * ( RK2SA + RKNWET )
  & - RK2SA * ZSO4 - RKNA * TNO3
 @ A0 = - (T21 * RK2SA * RKNWET
  & + RK2SA * RKNWET * ZSO4 + RK2SA * RKNA * TNO3 )

   CALL CUBIC ( A2, A1, A0, NR, CRUTES )

So, I tried to make a general fix that handle both cases of small and large GAMAxx and should be compiler/machine independent, with a new subroutine in error_mod.f and a new rpmares_mod.f. You can grab them at:

• ftp://ftp.as.harvard.edu/pub/geos-chem/patches/v8-01-01/error_mod.f
• ftp://ftp.as.harvard.edu/pub/geos-chem/patches/v8-01-01/rpmares_mod.f.

--phs 16:57, 6 June 2008 (EDT)

Fix for floating point error in RPMARES

NOTE: This fix was standardized in GEOS-Chem v8-01-02 and higher versions.

In GEOS-Chem v8-01-01, we have added a fix into routine RPMARES (in rpmares_mod.f) to avoid a floating point error that can occur under some conditions.

Philippe Le Sager wrote:

In RPMARES, the hydrogen ion (HPLUS) obtained as the root of a cubic equation is so large (286 moles/kg) that it triggers a large binary activity coefficient (LGAMA0) and then a very small mean molal ionic activity (GAMA=10**TRM=2.44e-159) when input into ACTCOF. That all seems correct, but this is so close to zero (~2e-159) that an error occurs when re-injected into RPMARES to compute the coefficients of the cubic equation for H+ at the next step.

We basically need to shunt the cubic equation for zero ionic activity coefficients to solve for H+, and then sulfate and nitrate.

Rokjin Park replied:

I agree with Philippe that the case with extremely low NH3 cases we don’t need to solve the cubic equation.

RPMARES should simply return the original values to avoid the NaN error.

Bob Yantosca replied:

FYI, Philippe and I have put in a fix in routine RPMARES:

      CALL ACTCOF ( CAT, AN, GAMS, MOLNU, PHIBAR )

      GAMANA = GAMS( 1, 2 )
      GAMAS1 = GAMS( 1, 1 )
      GAMAS2 = GAMS( 1, 3 )
      GAMAAN = GAMS( 2, 2 )

      !------------------------------------------------------------
      ! Add robustness: now check if GAMANA or GAMAS1 is too small
      ! for the division in RKNA and RK2SA. If they are, return w/
      ! original values: basically replicate the procedure used
      ! after the current DO-loop in case of no-convergence
      ! (phs, bmy, rjp, 4/10/08)
      !--------------------------------------------------------------
      IF ( ( ABS( GAMANA ) < EPS ) .OR.
   &       ( ABS( GAMAS1 ) < EPS ) ) THEN

         ! Reset to original values
         ANH4  = TNH4 * MWNH4
         GNH3  = FLOOR
         GNO3  = GNO3_IN
         ANO3  = ANO3_IN
         ASO4  = TSO4 * MWSO4
         AHSO4 = FLOOR

         ! Update water
         CALL AWATER ( IRH, TSO4, TNH4, TNO3, AH2O )

         ! Exit this subroutine
         RETURN
      ENDIF

so then if either of the GAMANA or GAMAS1 variables that get returned from ACTCOF is zero (or smaller than a minimum value) then we don't continue the iteration but then reset to original values and exit the subroutine. This definitely fixed the problem.

--Bob Y. 16:18, 22 February 2010 (EST)

Reverting to RPMARES due to ISORROPIA giving unrealistic values

Due to the ISORROPIA bug at low RH discussed below, we will revert to the RPMARES aerosol thermodynamic equilibrium code in GEOS-Chem v8-01-01.

Daniel Jacob wrote:

Thanks! The HNO3 simulation is doing much better but I still wonder if the high values in the free troposphere (where the RH is low) are caused by the ISORROPIA bug. We do need to replace ISORROPIA with RPMARES in the standard model until Havala gives us the corrected ISORROPIA version. Daniel

Bob Yantosca replied:

Hi all,

I will put RPMARES into the std code. I will do 2 1-yr benchmark simulations with the GEOS-5 v8-01-01 std code:

• v8-01-01-geos5 w/ ISORROPIA (for clean comparison between v8-01-01 and previous models)
• v8-01-01-geos5 w/ RPMARES (for clean comparison between RPMARES & ISORROPIA w/ the same version)

RPMARES will be used in all NRT-ARCTAS runs for model dates 4/1/08 and beyond.

Thanks and stay tuned,

Bob Y.

--Bmy 13:16, 4 April 2008 (EDT)

Comparison of RPMARES to ISORROPIA II

I was curious about the seemingly low global burden of nitrate I was getting from my simulation using RPMARES (0.18 Tg NO3, about 40% lower than other models and Pye [2009]). Havala Pye conducted a test of RPMARES vs. ISORROPIA II and found the same 40% difference (ISORROPIAII 0.35 Tg NO3, RPMARES 0.20 Tg NO3).

I assumed the difference was mainly due to ISORROPIA II including sea salt in the aerosol thermodynamic equilibrium calculation, while RPMARES does not. I conducted a test with ISORROPIA II, ISORROPIA II with artificially low sea salt concentrations, and RPMARES. Each simulation started from the same restart file and was run for one timestep so that the results could be compared. The global burdens were:

1. ISORROPIA II: 0.27 Tg NO3
2. ISORROPIA II with low sea salt: 0.23 Tg NO3
3. RPMARES: 0.20 Tg NO3

The results show that sea salt plays in an important part in marine areas and a smaller role in the free troposphere.

Surface comparisons show that both RPMARES and ISORROPIA II can reproduce observations over the US, an ammonia-rich environemnt.

--Eric L. 10:42, 10 November 2009 (EST)

References

1. Binkowski, F. S., and S. J. Roselle, Models-3 Community Multiscale Air Quality (CMAQ) model aerosol component: 1. Model description, J. Geophys. Res., 108(D6), 4183, doi:10.1029/2001JD001409. 2003.
2. Fountoukis, C., and A. Nenes (2007), ISORROPIA II: A computationally efficient thermodynamic equilibrium model for K+-Ca²⁺-Mg²⁺-NH₄⁺-Na⁺-SO₄^2-NO₃^--Cl-H₂O aerosols, Atmos. Chem. Phys., 7(17), 46394659.
3. Park, R. J., D. J. Jacob, B. D. Field, R. M. Yantosca, and M. Chin, Natural and transboundary pollution influences on sulfate-nitrate-ammonium aerosols in the United States: implications for policy, J. Geophys. Res., 109, D15204, 10.1029/2003JD004473, 2004. PDF
4. Pye, H. O. T., H. Liao, S. Wu, L. J. Mickley, D. J.Jacob, D. K. Henze, and J. H. Seinfeld, Effect of changes in climate and emissions on future sulfate-nitrate-ammonium aerosol levels in the United States, J. Geophys. Res., 114, D01205, 2009. PDF

--Bob Y. 15:42, 22 February 2010 (EST)