Lightning NOx emissions

02 Oct 2007

Lee Murray has identified a bug in the existing code (GEOS-Chem v7-04-12) which manifests itself when lightning emissions are turned off in GEOS-Chem. The bug causes non-physical values to propagate through the tracer array...this shows up as anomalous CO concentrations at high altitudes over the tropics.

>The bug of simply turning off lightning in input.geos in a clean build of GEOS-Chem v7-04-12 causing the CO (and other species) to explode has been fixed. (see attached) > >We use common block arrays to pass lightning and aircraft (GEMISNOX) and soil (GEMISNOX2) emissions to the SMVGEAR solver. If a common block is called only in a subroutine, apparently (perhaps architecture/compiler-specific) it is able to occasionally lose its values (I had to really dig up old comments on F77 programming), which is feeding junk values into the model. > >I don't know if this will correct the problems that Ray and I had with the local-rescaling lightning as well. It is quite possible that this is also common block error, though maybe not. I will continue to investigate. > >The only sure way to eliminate this problem for certain is to eliminate the use of common block arrays (which is something that's been on the to-do list for a while). If we're going to be overhauling lightning for v7-04-13, I would strongly recommend that we switch over to the use of allocated arrays to hold the lightning emissions. (This would then also require modifying at least the aircraft emissions similarly). > >Do you agree? > >~Lee

• • ERROR: note weird values in CO**

{{wiki:geos-chem:error.png}}

• • FIXED: weird values in CO disappear**

{{wiki:geos-chem:fixed.png}}

Bob Yantosca replied that the preferred way to fix this error would be to replace the common block array GEMISNOX with separate module arrays for lightning NOx (EMIS_LI_NOx) and aircraft NOx (EMIS_AC_NOx). This fix will be implemented into GEOS-Chem v7-04-13.

>>It's probably better to just take the GEMISNOX array out of the common block completely and to create separate module arrays for lightning and aircraft emissions. That should get rid of any instability. >> >>Indeed, some of these common-block errors can be very esoteric. As Lee said, they may be specific to a given compiler/platform combination. Some of these types of errors may also depend on what level of optimization that you use to compile the code. Fortran optimizers can do stuff like try to force common blocks to align themselves in multiples of 64kb chunks or other weird stuff (unless you tell it not to). >> >>We do have some common blocks still in GEOS-Chem, mainly in the legacy code and 3rd-party code sections (i.e. emissions, SMVGEAR, FAST-J, ISORROPIA, etc.). It is often difficult to totally remove all of the common blocks in the older code sections without making changes in a lot of other places as well. Newer parts of GEOS-Chem have been written to the F90 specifications. >> >>Bob Y.

24 Sep 2007

Lee Murray (see correspondence below) has submitted a revised algorithm for lightning NOx emissions. This will be added into GEOS-Chem internal version v7-04-13.

>Here's a list of the changes in the lightning code over v7.04.12 that I'm about to send over to Bob for inclusion into the standard model -- these are all what I have been running my sensitivity simulations with, and I think are improvements. I just want to make sure that these sound reasonable to everyone -- please let me know if you have any concerns/objections. > >Thanks, >Lee > >**1. Elimination of "near-land" treatment** -- reverting to a single "lightning_nox_mod.f" ("lightning_nox_nl_mod.f" will be removed). This offers a significant improvement in correlation with the climatology on its own. > >**2. Elimination of all top-down scaling** -- Attempt to have a physically-based parameterization. > >**3. Elimination of emissions per path length**. This relied on the grossly-simplified assumption that the relative path lengths vary as the linear ratio between the vertical distances between the negative charge layer with the ground and the cloud top heights for CG or IC flashes, respectively. The CG and IC path lengths (which have significant horizontal components and many multiple strokes per flash) almost definitely do not follow this relationship -- and we don't differentially distribute vertically anyway. In the future, we can look at aggregated pdfs of path lengths available from single-storm measurements to make a more appropriate distinction (hopefully in conjunction with different vertical pdfs). This was already done for N MIdLats, but now for tropics too. > >**4. Tropical flashes at 260 mol/fl** -- from Randall's constraint of 4.4 Tg N in the tropics and the OTD-LIS climatology for the region he considered. (Versus 500 mol/fl currently in the model for N MidLat, as per Rynda's work). Both of these are within the range of values in the literature. The 500 is at the upper range. The 260 is very close to the mean/median (and will be applied to ~80% of all flashes). > >**5. New Local Scaling** -- Now monthly rather than seasonally, since we have the high res monthly climatology and there are significant intra-seasonal spatial variability in the lightning distribution -- particularly over the SE USA. Also, set the redist factor in boxes where the model parameterization calculates no lightning over the OTD-LIS window (May 1995-Dec 2005) but OTD-LIS saw some to 1.0 (I believe Bastien set them to 0.0), so as not to suppress future years that may want to put lightning there via the param. > >(For now, have inserted a logical trap to cancel the simulation if the regional redistribution is selected. Once my study is done, then we just remove the trap in a future version) > >**6. New input.geos mid-level scaling option** -- If turned on (may be used with or without any of the redistributions), it will multiply every box by a uniform factor determined such that the 11-year parameterized and observed average annual flash rates (~46 flashes per second) are equal. This will be a highly recommended feature. CTH does an okay job without it, but PRECON and MFLUX really need it to be brought to the correct order of magnitude (at least in GEOS4). However, leave it optional so that one can use the unmodified physical parameterizations as well if they so choose. In the future, this may be modified to be a year-specific scaling factor as determined by the LIS observations. > >**7. Recommended options in "input.geos"**

 => Use lightning NOx?  : T
    => Scale glb flrate : T
    => OTD reg redist?  : F
    => OTD local redist?: T
    => Use CTH param?   : T
    => Use MFLUX param? : F
    => Use PRECON param?: F