E3SM-Project / E3SM-Project/scream

Gustiness parameterizations in EAMxx

Open
#2,426 4 comments 0 reactions 0 assignees View on GitHub
enhancement Surface Coupling
Dominant language
No language data
Stars
79
Forks
54
PR merge metrics
No merged PRs in 30d

Description

EAM versions 1-3 have a pair of gustiness parameterizations that are used to calculate unresolved horizontal wind variations, for the purpose of improving surface flux/stress calculations. EAMxx does not appear to have implemented any such parameterization, but it probably should.

As an up-front disclaimer, I am not a specialist in atmosphere-surface interactions, so I'm not going to claim to know what the state-of-the-art is. I'm just going to talk about what could go into EAMxx that's similar to what EAM has.

# Background/Motivation

GCM gustiness parameterizations typically account for two sources of gustiness that occur on different length/time scales.

First, there is gustiness due to precipitating convection, which can dramatically boost surface fluxes. This is regarded as a mesoscale effect, but more specifically occurs on the scales associated with deep convection. It may be possible to get by without it in SCREAM, but it should definitely be included in RRM and low-res runs. Unlike ZM itself, there is a scale-aware version of this parameterization to turn itself off at smaller scales, which would be useful for RRM, though I don't know how well it performs in practice.

The other source of gustiness is boundary-layer eddies. These can be relevant at scales down to 1 km or smaller, and are most influential for when the resolved wind speed is small (<3 m/s w.r.t. the surface), in which case surface fluxes are mainly driven by sub-grid-scale eddies. This type of gustiness should probably be accounted for even at SCREAM's resolution. One way of calculating this gustiness is to use a simple parameterization of convective motion that can be calculated by the surface model; the land model does this, but to my knowledge, the ocean and sea ice do not. The other alternative is for the atmosphere itself to provide an estimate of the characteristic speed of sub-grid-scale horizontal motion (e.g. a speed proportional to the square root of TKE). EAMv3 currently does both (meaning that possibly there is some double-counting of gustiness over land).

More on the current implementation of gustiness in the EAMv3 candidate (and some proposed changes I suggested) is in [this document](https://docs.google.com/document/d/1WbFOj82hV3lb6ALp9fZC3ZIDYURFt5bEZTdu3A2GwDo/edit?usp=sharing).

# Implementation

Gustiness associated with precipitating convection may not be worth implementing in EAMxx until there is a deep convection scheme to drive it (i.e. ZM is ported). It may be possible to adapt this gustiness parameterization to use a rain rate from SHOC, but if SHOC is running with no deep convection scheme, the horizontal resolution may be short enough that it's not necessary to include this kind of gustiness anyway? However, it should probably be implemented in the same way as in EAM when ZM is ported (or if an EDMF-type scheme is implemented, or whatever else might be done for handling deep convection).

For the boundary-layer eddies, we could get some diagnosis of gustiness out of SHOC and export it to the coupler. Or we could see if the ocean coupling code can apply its own parameterization of gustiness. I believe that the COARE and UA schemes (enabled by setting `ocn_surface_flux_scheme=1` or `2` in the coupler options, respectively) both have gustiness parameterizations; in either case, it's just a few lines of code that could be copied into the default E3SM scheme (`ocn_surface_flux_scheme=0`).

It may also be possible to get a rough idea of how increased gustiness might affect ocean fluxes by raising the value of `seq_flux_atmocn_minwind` in the coupler namelist (current default value is 0.5 m/s, it could be raised to maybe 1 or 2 m/s as a test). However, this is really a crude approximation to what gustiness should do, and not desirable as a long-term fix.

Although the gustiness parameterizations are present in the EAM Fortran code, they cannot be used by SCREAMv0 because the code is in `clubb_intr.F90`. In the event that tests with gustiness need to be tested in SCREAMv0, some code from clubb_intr would have to be copied to SHOC (or at least, somewhere where it would actually be called).

# Expected effects

The clearest direct effect of a gustiness implementation would be to increase surface stresses and reduce wind speeds, especially where the mean wind is already somewhat weak. With no gustiness, winds with a modest speed tend to "glide" almost frictionlessly over the ocean surface; gustiness adds friction that can help drive wind speeds of a few m/s toward zero. ~~This seems to be the main thing that motivated adding gustiness to EAMv1.~~ **Edit: Nope, it seems like an increase in evaporation/precipitation without increasing the resolved wind speed was the main goal.**

Gustiness also directly increases the magnitude of sensible and latent heat fluxes, but because it also slows down the mean winds, the net effect of increased gustiness may not be as large on these fluxes as on the stress. Therefore gustiness might make it easier to find a tuning where both near-surface winds and surface fluxes are reasonable. If there is no gustiness over the ocean, then larger wind speeds are necessary to achieve a given level of evaporation, so tuning the atmosphere to get the right amount of evaporation may result in near-surface wind speeds that are too high. A gustiness parameterization allows mean wind speeds to be reduced without pushing the evaporation rate down by as much. (I don't know if this actually would be beneficial in practice; it's just speculation for now.)

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.