|
|
(72 intermediate revisions by 5 users not shown) |
Line 1: |
Line 1: |
− | == FAST-J Photolysis ==
| + | #REDIRECT [[Tropospheric chemistry mechanism]] |
− | | + | |
− | === 25-Sep-2007 ===
| + | |
− | | + | |
− | The new cloud overlap algorithms from Hongyu Liu (see correspondence below) are scheduled to be implemented into v8-01-xx. The approximate random overlap will be the default option. We will have to do a 1-year benchmark with this revision separately, as the cloud overlap will have a substantial effect on the chemistry.
| + | |
− | | + | |
− | '''''Hongyu Liu (hyl@nianet.org) 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
| + | |
− | | + | |
− | == Variable Tropopause ==
| + | |
− | | + | |
− | === 25-Sep-2007 ===
| + | |
− | | + | |
− | # Note that the implementation of the variable tropopause is buggy in versions prior to [[GEOS-Chem_versions_under_development#v7-04-12|GEOS-Chem v7-04-12]]. If you are using versions prior to v7-04-12, you should turn the variable tropopause OFF. | + | |
− | # Jennifer Logan (see correspondence below) suggested that we should cap the variable tropopause at 200hPa in near-polar regions (90-60S and 60-90N), to avoid the problem with anomalously high tropopause heights at high latitudes. This fix was not in v7-04-12, but will be implemented into [[wiki:geos-chem:development#v7-04-13|GEOS-Chem internal version v7-04-13]].
| + | |
− | | + | |
− | | + | |
− | :'''''Jennifer Logan (jlogan@seas.harvard.edu) wrote:'''''
| + | |
− | | + | |
− | ::After looking at the two papers I sent, I think we should restrict the tropopause at latitudes > 60 deg. to pressures greater than 200 mb (about 11 km). From Fig. 3 in Seidel and Randel, there are tropopause (TP) heights as high as 13.5 km in the Antarctic (median height is ~9.8 km, 250 mb), but I don't think we want to be doing trop. chem there. The median TP pressure at ~80 N is ~300 mb, compared to ~250 mb at 70-85 S. The extratropical TP heights are higher (lower pressure) in the SH than in the NH according to Fig. 3.
| + | |
− | | + | |
− | ::This approach is also very easy to explain in a paper.
| + | |
− | | + | |
− | ::Jennifer
| + | |
− | | + | |
− | == Other errors in SMVGEAR ==
| + | |
− | | + | |
− | * Click [[Bugs_and_fixes#nov_2007|HERE]] for a description of the SMVGEAR bug that caused concentrations of certain tracers in STT to go to zero. This bug was fixed by May Fu and Philippe Le Sager.
| + | |
− | * Lok Lamsal reported a bug with NaN's in SMVGEAR. Bob Yantosca recommended a fix for this error. Click [[Bugs_and_fixes#jul_2007|HERE]] to visit the discussion in the Bug Fixes Forum.
| + | |