Open nadavis-ncar opened 3 years ago
gold2718
commented
1 year ago Here is a proposed API from @patcal: https://gist.github.com/gold2718/4b7b5d9ecedd71e3fbb08349e9da9f45#file-zonal_mean_api-f90 I also included some (lightly edited) example usage from @patcal there. Major points and/or conclusions should be documented on this issue.
patcal
commented
1 year ago The installed zonal_mean.F90 module provides a low level interface in that provides access to the spectral amplitudes but requires multiple calls to compute zonal mean values. Perhaps convienence functions can be added to directly return the zonal mean grid values if needed.
The usage description in the zonal_mean_api-f90 file above is for the the stand alone module for post-processing use. The API for the MPI/physgrid implementation installed here can be found at the beginning of the zonal_mean.F90 module.
Implemented in the pull request is functionality to apply a zonal mean filter to nudge the zonal mean of the model state to the zonal mean of the target data values. The images show ERAI temperature values at the surface layer, the compute zonal mean values for that layer, and the applied tendencies to nudge the zonal mean of the model's temperature.
An incomplete list of what still needs to be done:
Summary
There should be a feature to provide zonal mean history output for any dycore. There should also be a feature that supports zonal mean/eddy nudging within physics, as this expands the capability of CESM to support fundamental research into the atmospheric circulation.
Background
The capability to output pressure-interpolated zonal mean quantities supports rapid model assessment, reduces overhead on users, and reduces demand on disk space.
Model evaluation of dynamics and chemistry is often grounded in an analysis of the zonal mean climate. This is not just convenient but also physically motivated, as the governing physics of insolation and fluid dynamics vary fundamentally with latitude (and not with longitude). Zonal mean output reduces the disk space required to quantify basic wave-mean flow dynamics by several orders of magnitude by eliminating the longitude dimension and the need to sample instantaneous output at high time resolution. The finite volume dycore currently provides zonal mean output via the ctem.F90 module, so the ability to output zonal mean quantities can be seen as a regression test against existing functionality.
In addition to output capability, there is a scientific need to have access to the zonal mean of prognostic fields within physics modules. For example, nudging either the zonal mean or zonally-anomalous part of the flow can effectively constrain wave-mean flow feedbacks, supporting better research into the circulation response to climate forcings. This ability exists implicitly in the finite volume dycore and can be implemented with simple source modifications.
However, because the spectral element and other dycores employ non-rectilinear grids, these capabilities are absent.
Adoption of future dycores will be hindered by their current inability to support online zonal mean capability and zonal mean output, especially as the finite volume dycore possesses both.
Specification
“Zonal mean” is defined as an average over the longitude dimension with dimensions of pressure and latitude. It should be an average in physical units, and not an average with dimensions of, for example, model level.
A physics package should be able to call a function to retrieve the zonal mean of a meteorological/advected model field, defined on the local column(s). This implies the zonal mean, in dimensions of pressure and latitude, can be converted back to model level and (arbitrary) latitude appropriate for each column. For this specification, “meteorological” means variables like the wind vector (u, v, w) and temperature, while “advected” means any advected constituents such as ozone or water vapor.
It should also be possible to request history output of the zonal mean of these meteorological/advected fields and their eddy covariances. For example, it should be possible to output the zonal mean eddy covariance term [v’O3’], where primes denote deviations in longitude and brackets denote the zonal mean; and it should be similarly possible to output the zonal mean meridional wind, [v], and ozone, [O3].
Some thoughts on implementation
Calculating and outputting zonal mean quantities in the finite volume dycore is currently accomplished within ctem.F90 through a series of accumulation and broadcast steps. However, this process can be simplified and done purely through accumulation alone. As an example of the current implementation, suppose a user requests [u’v’]. In ctem.F90, u and v are interpolated to pressure locally on each processor. These values are then accumulated on a master processor, which calculates the zonal means [u] and [v]. The master processor then broadcasts the relevant values of [u] and [v] to each processor. Each processor locally calculates u’ and v’ via the decomposition u’ = u - [u]. The master processor then accumulates u’ and v’, and calculates their zonal average as [u’v’]. In sum, this requires the accumulation of four and broadcasting of two full 3-dimensional fields. It can be simplified so that the zonal mean is purely an accumulation process, using the identity [uv]=[u][v]+[u’v’]. A master processor could simply accumulate u, v, and uv and calculate the zonal mean covariance as [u’v’] = [uv]-[u][v]. This not only eliminates the need to broadcast back to each core, but also eliminates one accumulation process.
For online capability, however, there must still be a way to broadcast the relevant value of the zonal mean back to each column. On a rectilinear grid, if a column has values defined at latitude j and pressure level k, the zonal mean will also have a value defined at latitude j and pressure level k, with a direct mapping between the two by virtue of the grid. I do not sense there is an obvious way to map between a rectilinear zonal mean grid and a non-rectilinear grid in regions where neighboring latitudes (in the zonal mean) and columns (on the non-rectilinear grid) do not have defined values due to topography.
Implementing the online zonal mean capability within physics would ensure it can work with any dycore. It would be appealing to have the history output as a module that interfaces with any dycore, as well, but I don’t know enough about the architecture to know if this is possible.
A zonal mean nudging case should be developed as a regression test that new grids must satisfy.
For elements of atmospheric composition, mass-weighted zonal averages on model levels provides a consistent representation of the data. Interpolation to pressure, as proposed throughout this issue, may not generally conserve mass, though the zonal averaging in pressure will conserve mass. If pressure interpolation is used as part of the zonal averaging process, there may need to be some kind of mass fixer to ensure each constituent’s vertically-integrated mass is conserved.