Cloud convection: Difference between revisions

From Geos-chem
Jump to navigation Jump to search
 
(49 intermediate revisions by 3 users not shown)
Line 1: Line 1:
This page describes the cloud convection (aka wet convection) algorithms of GEOS-Chem.
This page describes the cloud convection (aka wet convection) algorithms of GEOS-Chem.  We also invite you to read [[Wet deposition|our ''Wet deposition'' wiki page]], which contains information about the algorithms used for scavenging of soluble tracers.


== Overview ==
== Overview ==
Line 13: Line 13:
== Relaxed Arakawa-Schubert scheme ==
== Relaxed Arakawa-Schubert scheme ==


This is the convection scheme that GEOS-Chem uses with both GEOS-3 and GEOS-5 meteorology.  The source code for this scheme is located in routine <tt>NFCLDMX</tt> in <tt>convection_mod.f</tt>.
This is the convection scheme that GEOS-Chem currently uses with [[GEOS-FP]] and [[MERRA-2]] meteorology.  The source code for this scheme is located in routine <tt>DO_CONVECTION</tt> in <tt>GeosCore/convection_mod.F</tt>.
 
== Hack and Zhang-McFarlane schemes ==
 
This is the convection scheme that GEOS-Chem uses with both GEOS-4 and GCAP meteorology.
 
=== GEOS-4 ===
 
The source code for the convection scheme required for GEOS-4 meteorology is contained within the F90 module <tt>fvdas_convect_mod.f</tt>.  The main driver is called <tt>FVDAS_CONVECT</tt>.  This routine calls the following routines:
 
#<tt>ARCONVTRAN</tt>: Prepares arrays for use by <tt>CONVTRAN</tt>
#<tt>CONVTRAN</tt>: Main driver for deep convection (i.e. Zhang/McFarlane scheme)
#<tt>HACK_CONV</tt>: Main driver for shallow convection (i.e. Hack scheme)
 
=== GISS ===
 
The source code for the convection scheme required for GISS/GCAP meteorology is contained within the F90 module <tt>gcap_convect_mod.f</tt>.  The main driver is called <tt>GCAP_CONVECT</tt>.  This routine calls the following routines:
 
#<tt>ARCONVTRAN</tt>: Prepares arrays for use by <tt>CONVTRAN</tt>
#<tt>CONVTRAN</tt>: Main driver for deep convection (i.e. Zhang/McFarlane scheme)
 
There is no equivalent routine to <tt>HACK_CONV</tt> for the GCAP meterology.  Instead, <tt>ARCONVTRAN</tt> and <tt>CONVTRAN</tt> are called with entraining mass fluxes, and then again with non-entraining mass fluxes.
 
--[[User:Bmy|Bob Y.]] 13:11, 19 February 2010 (EST)


== Validation ==
== Validation ==
Line 56: Line 33:


--[[User:Bmy|Bob Y.]] 13:11, 19 February 2010 (EST)
--[[User:Bmy|Bob Y.]] 13:11, 19 February 2010 (EST)
== Previous issues that are now resolved ==
=== Avoid NaN values for WASHFRAC in routine DO_MERRA_CONVECTION ===
'''''Qiaoqiao Wang wrote:'''''
:I found a bug in routine of <tt>DO_MERRA_CONVECTION</tt> in <tt>convection_mod.F</tt>.  The washfrac from washout subroutine can sometimes return NAN value. But simulation won't stop unless the DIAG38 is turned on as it check for infinity only if DIAG38 is on. I notice that some lines has been added in <tt>wetscav_mod.F</tt> regarding this problem. So maybe it's better to also add those line (in bold) after call <tt>washout</tt> in this code:
                  CALL WASHOUT( I, J, K,  IC,      BXHEIGHT(K),
    &                          T(K),      QDOWN,    SDT,
    &                          F_WASHOUT, H2O2s(K), SO2s(K),
    &                          WASHFRAC,  AER,      State_Met,
    &                          State_Chm                        )
                  <b>!%%% BUG FIX: Only apply this section of when running
                  !%%% GEOS-Chem with MERRA met fields.  (bmy, hamos, 5/26/11)
                  !
                  ! Check if WASHFRAC = NaN or WASHFRAC < 0.1 %
                  !
                  ! If WASHFRAC = NaN, then DSTT = NaN and SAFETY trips because
                  ! tracer concentrations must be finite.WASHFRAC = NaN when F = 0.
                  ! When less than 0.1% of a soluble tracer is available for washout
                  ! DSTT < 0 and SAFETY trips.  (Helen Amos, 20100928)
                  IF ( IT_IS_NAN( WASHFRAC ) ) THEN
                    CYCLE
                  ELSEIF ( WASHFRAC < 1D-3 ) THEN
                    CYCLE
                  ENDIF</b>
                  ! Check if the tracer is an aerosol or not
                  IF ( AER == .TRUE. ) THEN
--[[User:Melissa Payer|Melissa Sulprizio]] 13:13, 14 May 2014 (EDT)
=== Reduce time spent in routine DO_CONVECTION when using GEOS-FP or MERRA ===
'''''This update is being tested with month benchmark simulation [[GEOS-Chem v10-01 benchmark history#v10-01c|GEOS-Chem v10-01c]].'''''
Using the [http://tau.uoregon.edu Tuning and Analysis Utilities (TAU)], we were able to make the following modifications to routine <tt>DO_CONVECTION</tt> (in module file <tt>GeosCore/convection_mod.F</tt>) that resulted in a speedup in the [[GEOS-FP]]/[[MERRA]] convection module.  We made modifications in the following routines:
#<tt>DO_CONVECTION</tt> (in module <tt>GeosCore/convection_mod.F</tt>)
#*We no longer use objects from <tt>GeosCore/gc_type_mod.F</tt> (i.e. <tt>OPTIONS</tt>, <tt>DIMINFO</tt>, etc.).  These have been largely superseded by the <tt>Input_Opt</tt> object.
#*Remove all pointer references to fields of <tt>State_Met</tt> and <tt>State_Chm</tt> from the parallel DO loop.
#*Now use the proper # of tracers for APM aerosol microphysics.
#*Now declare the parallel DO loop with <tt>!$OMP+PRIVATE</tt>, which results in better load-balancing.
#<tt>DO_MERRA_CONVECTION</tt> (in module <tt>GeosCore/convection_mod.F</tt>):
#*Now make the following variables local pointer variables instead of arguments:
#**<tt>AD, BXHEIGHT, CMFMC, DQRCU, DTRAIN, REEVAPCN, T, Q</tt>.  These point to the corresponding variables in <tt>State_Met</tt> or <tt>State_Chm</tt>.
#**<tt>H2O2s, SO2s</tt>: These point to the corresponding arrays in <tt>GeosCore/sulfate_mod.F</tt>.
#<tt>COMPUTE_F</tt> (in module <tt>GeosCore/wetscav_mod.F</tt>)
#*Now make the F argument of routine COMPUTE_F an assumed-shape array (i.e. <tt>F(:,:,:)</tt> ).  This allows us to pass pointer-valued arguments to
#<tt>GeosCore/gc_type_mod.F</tt>:
#*This has now been moved to the <tt>obsolete/</tt> subdirectory.
[[Image:GEOSFP_Conv_Speedup.png]]
Also note that with this fix, the total CPU time of this run (1-day with GEOS-4x5 met) dropped from 16:l1 to 15:23 (min:sec).  So this fix is making the overall simulation run a little faster for each simulation day.
--[[User:Bmy|Bob Y.]] 16:38, 18 April 2014 (EDT)
=== Removed array temporaries in call to FVDAS_CONVECT ===
'''''This update is being tested with month benchmark simulation [[GEOS-Chem v10-01 benchmark history#v10-01c|GEOS-Chem v10-01c]].'''''
The [[GEOS-Chem Unit Tester]] revealed the presence of array temporaries in the call to GEOS-4 convection routine <tt>FVDAS_CONVECT</tt>.  To remove the array temporaries, we made these modifications in subroutine <tt>DO_GEOS4_CONVECT</tt>, located in module <tt>GeosCore/convection_mod.F</tt>:
(1) Declare the <tt>F</tt> variable with the <tt>TARGET</tt> attribute, as follows:
#if  defined( APM ) 
      INTEGER        :: INDEXSOL(Input_Opt%N_TRACERS+N_APMTRA)
      REAL*8, TARGET  :: F      (IIPAR,JJPAR,LLPAR,
      &                            Input_Opt%N_TRACERS+N_APMTRA)
#else               
      INTEGER        :: INDEXSOL(Input_Opt%N_TRACERS)
      REAL*8, TARGET  :: F      (IIPAR,JJPAR,LLPAR,
      &                            Input_Opt%N_TRACERS)
#endif
(2) Add pointer variables <tt>p_STT</tt> and <tt>p_F</tt>:
      REAL*8, POINTER :: p_STT  (:,:,:,:)  ! Ptr to STT    (flipped in vert)
      REAL*8, POINTER :: p_F    (:,:,:,:)  ! Ptr to F      (flipped in vert)
(3) Point <tt>p_STT</tt> to the <tt>State_Chm%Tracers</tt> field and flip levels in the vertical.  Likewise, point <tt>p_F</tt> to the <tt>F</tt> array, and also flip in the vertical:
      ! Point to various fields and flip in vertical.  This avoids
      ! array temporaries in the call to FVDAS_CONVECT (bmy, 4/14/14)
      p_HKETA  => State_Met%HKETA  (:,:,LLPAR:1:-1  )
      ... etc ...
      p_STT    => State_Chm%Tracers(:,:,LLPAR:1:-1,:)
      p_F      => F                (:,:,LLPAR:1:-1,:)  
(4) Pass <tt>p_STT</tt> and <tt>p_F</tt> to subroutine <tt>FVDAS_CONVECT</tt>:
        ! Call the fvDAS convection routines (originally from NCAR!)
      CALL FVDAS_CONVECT( TDT, 
      &                    N_TOT_TRC,
!----------------------------------------------------------------------------
! Prior to 4/14/14:
! Eliminate an array temporary (bmy, 4/14/14)
!    &                    STT  (:,:,LLPAR:1:-1,:),   
!----------------------------------------------------------------------------
      &                    p_STT,
      &                    RPDEL,       
      &                    p_HKETA,
      &                    p_HKBETA,
      &                    p_ZMMU,
      &                    p_ZMMD,
      &                    p_ZMEU,
      &                    DP,   
      &                    NSTEP,   
!----------------------------------------------------------------------------
! Prior to 4/14/14:
! Eliminate an array temporary (bmy, 4/14/14)
!    &                    F    (:,:,LLPAR:1:-1,:),       
!----------------------------------------------------------------------------
      &                    p_F,
      &                    TCVV, 
      &                    INDEXSOL,
      &                    State_Met )
(5) Nullify the pointers <tt>p_STT</tt> and <tt>p_F</tt> at the end of subroutine <tt>DO_GEOS4_CONVECT</tt>:
      ! Free pointers
      NULLIFY( STT,    p_STT,    p_F                    )
--[[User:Bmy|Bob Y.]] 11:05, 15 April 2014 (EDT)
=== Fixed minor issues in MERRA cloud convection routine ===
Jenny Fisher discovered two minor issues in the [[MERRA]] convection routine <tt>DO_MERRA_CONVECTION</tt> (in module  <tt>convection_mod.f</tt>):
==== ND38 diagnostic issue in routine DO_MERRA_CONVECTION ====
'''''This update was tested in the 1-month benchmark simulation [[GEOS-Chem_v9-01-02_benchmark_history#v9-01-02j|v9-01-02j]] and approved on 16 Aug 2011.'''''
'''''[mailto:jafisher@fas.harvard.edu Jenny Fisher] wrote]:'''''
:The bug is in routine <tt>DO_MERRA_CONVECTION</tt>.  When <tt>DIAG38</tt> is first written (around line 2056 in my code, after the comment titled "(3.4) ND38 Diagnostic"), DIAG38 is formed by adding T0 (converted to appropriate units) to the diagnostic each level K. This is correct. However, the second time we add to <tt>DIAG38</tt> (below the cloud base, around line 2245 in my code), we add <tt>T0_SUM</tt> to each level. From what we can tell, <tt>T0_SUM</tt> represents not the washout from each level but instead the total wet scavenging loss, summed over the entire column. So we are effectively double counting in these levels and adding way too much. [Helen Amos and I] think this should instead be adding <tt>WETLOSS</tt>.
The fix is below:
                  IF ( OPTIONS%USE_DIAG38 .and. F(K,IC) > 0d0 ) THEN
                      DIAG38(K,IC) = DIAG38(K,IC)
!------------------------------------------------------------------------------
! Prior to 8/16/11:
! Now use WETLOSS instead of T0_SUM in the ND38 diagnostic below the cloud
! base.  WETLOSS is the loss in this level, but T0_SUM is the loss summed
! over the entire column.  Using T0_SUM leads us to over-count the tracer
! scavenged out of the column. (jaf, hamos, bmy, 8/16/11)
!    &                            + ( T0_SUM * AREA_M2 / TCVV_DNS )
!------------------------------------------------------------------------------
      &                            + ( WETLOSS * AREA_M2 / TCVV_DNS )
                  ENDIF
--[[User:Bmy|Bob Y.]] 16:48, 16 August 2011 (EDT)
==== Wrong IF tests used in routine DO_MERRA_CONVECTION ====
'''''This update was tested in the 1-month benchmark simulation [[GEOS-Chem_v9-01-02_benchmark_history#v9-01-02j|v9-01-02j]] and approved on 16 Aug 2011.'''''
:Routine <tt>DO_MERRA_CONVECTION</tt> was using tracer flags <tt>IDTHg2</tt> and <tt>IDTHgP</tt> to determine whether routines <tt>ADD_Hg2_WD</tt>, <tt>ADD_HgP_WD</tt>, and <tt>ADD_Hg2_SNOWPACK</tt> should be called.  However, <tt>IDTHg2</tt> and <tt>IDTHgP</tt> aren't ever defined and were set to zero, so these routines were never called even when the correct mercury species were used.
The fix is to replace these two lines of code
    IF ( IS_Hg .and. IC == IDT%Hg2 ) THEN
    ...
    IF ( IS_Hg .and. IC == IDT%HgP ) THEN
with these:
    IF ( IS_Hg .and. IS_Hg2( IC ) ) THEN
    ...
    IF ( IS_Hg .and. IS_HgP( IC ) ) THEN
--[[User:Bmy|Bob Y.]] 16:47, 16 August 2011 (EDT)
== Outstanding issues that are not yet resolved ==

Latest revision as of 20:46, 13 July 2023

This page describes the cloud convection (aka wet convection) algorithms of GEOS-Chem. We also invite you to read our Wet deposition wiki page, which contains information about the algorithms used for scavenging of soluble tracers.

Overview

From Section 2, paragraph 10 of Wu et al [2007]:

A major difference between the GEOS-3, GEOS-4, and GISS models is the treatment of wet convection. GEOS-3 [and now also GEOS-5, ed.] uses the Relaxed Arakawa-Schubert convection scheme [Moorthi and Suarez, 1992]. GEOS-4 has separate treatments of deep and shallow convection following the schemes developed by Zhang and McFarlane [1995] and Hack [1994]. The convection scheme in the GISS GCM was described by Del Genio and Yao [1993]. Unlike the GEOS models, the GISS GCM allows for condensed water in the atmosphere (i.e., condensed water is not immediately precipitated), resulting in frequent nonprecipitating shallow convection. In the wet deposition scheme, we do not scavenge soluble species from shallow convective updrafts at altitudes lower than 700 hPa in the GISS-driven model, whereas we do in the GEOS-driven model [Liu et al., 2001].

Updraft scavenging of soluble tracers (as applied to both the Relaxed Arakawa and Hack/Zhang-McFarlane schemes in GEOS-Chem) is described in Section 1 of Jacob et al [2000] and in Section 2.3.1 of Liu et al [2001].

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

Relaxed Arakawa-Schubert scheme

This is the convection scheme that GEOS-Chem currently uses with GEOS-FP and MERRA-2 meteorology. The source code for this scheme is located in routine DO_CONVECTION in GeosCore/convection_mod.F.

Validation

See Bey et al [2001], Liu et al [2001], and Wu et al [2007].

References

  1. Allen, D.J, R.B. Rood, A.M. Thompson, and R.D. Hidson, Three dimensional 222Rn calculations using assimilated data and a convective mixing algorithm, J. Geophys. Res, 101, 6871-6881, 1986a.
  2. Allen, D.J. et al, Transport induced interannual variability of carbon monoxide using a chemistry and transport model, 101, J. Geophys. Res, 28,655-28-670, 1986b.
  3. Bey I., D. J. Jacob, R. M. Yantosca, J. A. Logan, B. Field, A. M. Fiore, Q. Li, H. Liu, L. J. Mickley, and M. Schultz, Global modeling of tropospheric chemistry with assimilated meteorology: Model description and evaluation, J. Geophys. Res., 106, 23,073-23,096, 2001. PDF
  4. Del Genio, A. D., and M. Yao, Efficient cumulus parameterization for long-term climate studies: The GISS scheme, in The Representation of Cumulus Convection in Numerical Models, Meteorol. Monogr., 46, 181–184, 1993.
  5. Hack, J.J., Parameterization of moist convection in the National Center for Atmospheric Research Community Climate Model (CCM2), <u<J. Geophys. Res., 99, 5551–5568, 1994.
  6. 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.
  7. Liu, H., et al. (2001), 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. PDF
  8. Moorthi, S., and M. J. Suarez, Relaxed Arakawa-Schubert: A parameterization of moist convection for general circulation models, Mon. Weather Rev., 120, 978– 1002, 1992.
  9. Wu, S., L.J. Mickley, D.J. Jacob, J.A. Logan, R.M. Yantosca, and D. Rind, Why are there large differences between models in global budgets of tropospheric ozone?, J. Geophys. Res., 112, D05302, doi:10.1029/2006JD007801, 2007. PDF
  10. Zhang, G. J., and N. A. McFarlane, Sensitivity of climate simulations to the parameterization of cumulus convection in the Canadian Climate Centre general circulation model, Atmos. Ocean, 33(3), 407–446, 1995.

--Bob Y. 13:11, 19 February 2010 (EST)