Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support CAM hybrid sigma-pressure vertical coordinates #191

Open
spencerahill opened this issue Jun 14, 2017 · 0 comments
Open

Support CAM hybrid sigma-pressure vertical coordinates #191

spencerahill opened this issue Jun 14, 2017 · 0 comments
Labels

Comments

@spencerahill
Copy link
Owner

CAM uses a hybrid sigma-pressure coordinate system, essentially the same in spirit to what GFDL models use (and thus what we already support). However, there are a couple implementation differences:

  • GFDL's formulation for pressure level interfaces (a.k.a. "half levels") is p_k = a_k + b_kp_s, where p_k is the pressure at interface level k, a_k has units of Pa, b_k is dimensionless, and p_s is the surface pressure. But CAM's formulation is p_k = p_0a_k + b_k*p_s, where p_0 is a reference pressure (1000 hPa in the data I'm looking at) and a_k is dimensionless. p_0 is saved within the netCDF files as it's own variable.

  • GFDL only provides these a_k and b_k arrays for computing the pressure at half levels, i.e. the pressure at the tops and bottoms of the coordinate levels. We then manually compute the pressure at the "full levels", i.e. the cell centers where most variables are defined (as an aside, there's room for improvement there: see Implement Simmons-Burridge method for computing pfull, phalf levels #82). But CAM provides additional a_k,mid and b_k,mid arrays defined at mid-levels also. We should definitely use these rather than computing the mid-level values from the half-levels.

And of course, the variable names are all different: 'lev' for 'pfull', 'ilev' for 'phalf', 'hyai' for 'a_k', 'hybi' for b_k', 'P0' for the reference pressure, and 'hyam' and 'hybm' for the mid-level a_k and b_k coefficient arrays (the last three don't have GFDL counterparts).

Short of actually implementing #80, the most attractive option I see is to modify the existing logic under the 'sigma' vertical data type (which, as an aside, we should really change to 'eta' or 'hybrid'), attempting to infer based on the existence of these additional variables how to compute the full and half level values. What do other people think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant