翻译自WRF源码文档 WRF-4.1.4/doc/README.hybrid_vert_coord
---------------
v3.9
从WRF v3.9 发行版（2017年春季）开始，在WRF模式中将混合垂直坐标Hybrid Vertical Coordinate (HVC) 选项加入到了现有的地形跟随Terrain Following (TF) 垂直坐标。随着v3.9，HVC选项要求用户同时激活编译时和运行时标志。
v4.0
从WRF v4.0 发行版（2018年夏季）开始，混合垂直坐标Hybrid Vertical Coordinate (HVC) 和最初的地形跟随坐标Terrain Following Coordinate (TFC)都可以通过namelist设置可用。这两种选项的代码编译到了模式中。
“强烈”警告用户不要在WRF模型中添加任何直接使用柱气压cloumn pressure的代码（例如mu、mub等）。
---------------------------------
HVC选项是一个“混合”垂直坐标，因为eta层次是在近地面地形跟随，然后向高空等压面放松。此坐标选项的目的是减少地形对模式顶部的人为影响。real程序和WRF模式需要使用相同的运行时设置（要么TFC，要么HVC）。如果用户混用real和WRF之间（或ideal和WRF之间）的垂直坐标运行时设置，则代码将停止。
已将v4.0 WRF代码修改为使用v4.0之前的输入和横向边界文件，但仅用于选择TF（地形跟随）坐标选项的运行时。
所有ARW-WRF大气测试例子的都能使用HVC选项。自从第一次发布HVC选项以来，为所有ideal cases提供初始化的工作已经完成。对于v4.0，现在所有ideal和real cases都可以使用hybrid_opt=2。
---------------------------------
要打开HVC运行时选项，在namelist.input文件中设置一个开关：
&dynamics
hybrid_opt = 2
/
这是一个单条目值，默认情况下通过Registry将其设置为“2”（激活混合坐标选项）。为了完整起见，要显式关闭namelist.input文件中的HVC选项（打开TFC选项），请执行以下操作：
&dynamics
hybrid_opt = 0
/
第二个运行时选项可用于HVC功能，它允许用户选择WRF模式表面完全等压的eta 层。设置此值不是凭感觉的，已经把一个应该在全局范围内管用的合理值设置为默认值。为了对模式结果进行敏感性实验，使其达到模型eta坐标变为等压的水平，用户可以修改在namelist.input文件中定义的临界eta层次：
&dynamics
etac = 0.2
/
随着etac值的增加（从0增加到1），更多的eta层次随着层次（从模式顶向下）数量的增加受到影响。一方面，这是一件好事，这种“坐标曲面的展平”是HVC选项的全部目的。然而，在地势较高的地区（不一定陡峭或复杂），当etac值大于约etac=0.22时，垂直eta水平被过度压缩。在喜马拉雅高原上，使用10 hPa模式盖时，etac=0.25的值会导致模型故障。在全球范围内，0.2的值被认为是“安全的”。美国东海岸可以使用etac=0.30，而纯海洋区域可能使用etac=0.40。
------------------------------
对于v3.9版本，对HVC功能的源代码所需的最大修改块是在TF坐标中定义为柱气压的变量（通常称为“mu”）。这是一个既有扰动又有基本态值的变量，对于不同的变量，甚至不同的时间水平，也有交错。总共需要处理近30个“mu”变量。对于HVC修订版，2d“mu”场仍然保留了柱气压的含义，但d(p_dry))/d(eta)的定义已经被推广，现在是3d。
几乎所有二维“mu”场的实例都通过两个一维数组（乘法和加法）的应用而转换为三维场。对于基本态“mu”和总“mu”场，从功能上来说，这个新场定义为：
mu_new_3d(i,k,j) = c1(k) * mu(i,j) + c2(k)
对于扰动“mu”场，仅应用乘法缩放：
mu_new_3d(i,k,j) = c1(k) * mu(i,j)
即使“mu”的每个实例有缩放，并且“mu”的大多数实例都应用了偏移量，但是运行v3.9 TFC与v3.9 HVC所花费的时间还是相当小的。在更好的仿真逼真度和无时间惩罚的情况下，决定将HVC代码完全合并到v4.0中，并将默认行为设置为HVC。请注意，在V4.0中，代码仍然反映了各个1D数组的显式乘法和加法，以减少拥有这么多新的3D“mu”数组的需要。
---------------
用户还被警告，原来的基本态和干气压的定义不再普遍有效。大多数用户会发现p‘+pb或p_hyd是令人满意的气压替代品。
------------------------
有两种方法可以确定是否使用HVC选项运行模型输出（如前所述，还强制运行模型IC和BC文件）。
在视觉上，用一个简单的netcdf查看器（如ncview）观察地形区域中“PB”场的水平面。对于从模型盖向下的几个连续水平，特定水平上的每个值应几乎相同（即几乎等压）。对于TF方案，地形的特征即使在倒数第二层也很明显。
netcdf文件还包含元数据，用于指示是否使用了混合垂直坐标选项。
对于使用TFC运行时选项的代码：
>ncdump -h wrfinput_d01 | grep HYBRID
:HYBRID_OPT = 0 ;
对于使用HVC运行时选项的代码：
>ncdump -h wrfinput_d01 | grep HYBRID
:HYBRID_OPT = 2 ;
-------------------------------------
已经使用WRF系统的许多其他特征进行了测试：FDDA、自适应时间步长、DFI、全局域、嵌套、移动嵌套和ndown。所有物理参数化方案都完全支持HVC选项。WRF开发人员与其他主要WRF系统组件的开发人员一起工作。WRF-DA-3dVAR和WRF-Chem都在混合坐标系下完全工作。随着HVC选项的引入，标准WRF后处理工具也得到了完全支持：NCL、UPP和RIP。
------------------------------------------------
与HVC选项不起作用的一个功能是垂直优化。
--------------------
包含混合坐标的所有信息的Registry文件是Registry/Registry.hybrid。在本文件顶部的注释中，简要描述了构成新3d“mu”的组件：
d(p_dry)/d(eta).
源文件：
Hybrid Vertical Coordinate
--------------------------
v3.9
Starting with the WRF v3.9 release (Spring 2017), the option for a Hybrid Vertical Coordinate (HVC) has been added to the existing Terrain Following (TF) vertical coordinate in the WRF model. With v3.9, the HVC option requires that a user activate both a compile-time and a run-time flag.
v4.0
With the release of WRF v4.0 (Summer 2018), the Hybrid Vertical Coordinate (HVC) and the original Terrain Following Coordinate (TFC) are both available via namelist settings. The code for both options is compiled into the model.
Users are STRONGLY cautioned about adding any code into the WRF model that directly uses the column pressure (for example, mu, mub, etc).
HVC: What is it, what‘s available
---------------------------------
The HVC option is a "hybrid" vertical coordinate, in that the eta levels are terrain following near the surface, and then relax towards an isobaric surface aloft. The purpose of this coordinate option is to reduce the artificial influence of topography towards the top of the model.The real program and the WRF model need to consistently use the same run-time setting for either TFC or HVC. The code will stop if the user mixes the vertical coordinate run-time settings between real and WRF (or between ideal and WRF).
The v4.0 WRF code has been modified to use pre-v4.0 input and lateral boundary files, but only for the run-time choice of the TF (terrain following) coordinate option.
All of the ARW WRF atmosphere test cases are able to use the HVC option. The work to supply an initialization for all of the ideal cases has been completed since the first release of the HVC option. With v4.0, now all of the ideal and real cases are eligible to use hybrid_opt=2.
Choosing the TF vs the HVC Option
---------------------------------
To turn on the HVC run-time option, a switch is set in the namelist.input file:
&dynamics
hybrid_opt = 2
/
This is a single entry value, which is set to "2" (activating the hybrid coordinate option) by default through the Registry. For completeness, to explicitly turn off the HVC option (turn on the TFC option) in the namelist.input file:
&dynamics
hybrid_opt = 0
/
A second run-time option is available for the HVC capability, which allows the user to select the eta level at which the WRF model surfaces become completely isobaric. Setting this value is not intuitive, and a reasonable value that should work globally has been set as the default. For sensitivity testing of the model results to the level at which the model eta coordinates become isobaric, the user may modify the critical eta level defined in the namelist.input file.
&dynamics
etac = 0.2
/
As the value of etac increases (from 0 towards 1), more eta levels are impacted as increasing numbers of levels (downward from the model top) are flattened out. On the one hand, that is a good thing, and this "flattening of the coordinate surfaces" is the entire purpose of the HVC option. However, over areas of high topography (not necessarily steep or complex), the vertical eta levels get too compressed when etac values get larger than about etac = 0.22. Over the Himalayan Plateau with a 10 hPa model lid, a value of etac = 0.25 causes model failures. Globally then, a value of 0.2 is considered "safe". The east-coast of the US would be able to use etac = 0.30, and pure oceanic domains could probably use etac = 0.40.
How the code has been modified
------------------------------
For the v3.9 release, the largest block of modifications required to the source code for the HVC capability is with the variable defined as the column pressure in the TF coordinate (referred to generally as "mu"). This is one of the variables that has both a perturbation and a base-state value, also staggerings for different variables, and even different time levels. All together, nearly thirty "mu" variables needed to be processed. For the HVC modification, the 2d "mu" fields still retain the meaning of column pressure, but the definition of d(p_dry))/d(eta) has been generalized, and is now 3d.
Almost all instances of a 2d "mu" field have been transformed into a 3d field with the application of two 1d arrays (a multiplication and an addition). For the base-state "mu" and total "mu" fields, functionally this new field is defined as:
mu_new_3d(i,k,j) = c1(k) * mu(i,j) + c2(k)
For perturbation "mu" fields, only the multiplicative scaling is applied:
mu_new_3d(i,k,j) = c1(k) * mu(i,j)
Even with each instance of "mu" being scaled and most instances of "mu" getting an offset applied, the elapsed time to run the v3.9 TFC vs the v3.9 HVC was quite small. With better simulation fidelity and no timing penalty, the decision was made to incorporate the HVC code entirely into v4.0, and to have the default behavior be HVC. Note that with v4.0, the code still reflects the explicit multiplication and addition by the respective 1d arrays to reduce the need to have so many new 3d "mu" arrays.
Cautionary note
---------------
Users are also warned that the original definitions of base-state and dry pressure are no longer generally valid. Most users will find either p‘+pb or p_hyd as satisfactory pressure substitutes.
What to Notice on Output
------------------------
There are a couple of ways to determine if the model output (and as stated previously, mandatorially the model IC and BC files also) was run with the HVC option.
Visually, with a simple netcdf viewer (such as ncview), look at the horizontal levels of the field "PB" in an area of topography. For a few consecutive levels downward from the model lid, each value on a specific level should be nearly identical (i.e. nearly isobaric). For the TF option, the signature of the topography is evident even at the penultimate level.
The netcdf files also have metadata included to indicate if the hybrid vertical coordinate option was used.
For code that used the TFC run-time option:
>ncdump -h wrfinput_d01 | grep HYBRID
:HYBRID_OPT = 0 ;
For code that used the HVC run-time option:
>ncdump -h wrfinput_d01 | grep HYBRID
:HYBRID_OPT = 2 ;
What WRF capabilities are OK with HVC
-------------------------------------
Tests have been conducted with a number of the WRF system‘s other signature features: FDDA, adaptive time stepping, DFI, global domains, nesting, moving nests, and ndown. All physical parameterization schemes fully support the HVC option.
The WRF developers have worked in conjunction with the developers of the other major WRF system components. Both WRF DA 3dVAR and WRF Chem fully function with the hybrid coordinate. With the introduction of the HVC option, the standard WRF post-processing tools are also fully supported: NCL, UPP, and RIP.
What WRF capabilities are NOT supported with HVC
------------------------------------------------
The one capability that is not functioning with the HVC option is vertical refinement.
Registry information
--------------------
The Registry file that contains all of the information for the hybrid coordinate is Registry/registry.hybrid. In the comments at the top of this file is a brief description of the component pieces that constitute new 3d "mu":
d(p_dry)/d(eta).
WRF混合垂直坐标 README.hybrid_vert_coord
原文：https://www.cnblogs.com/jiangleads/p/12564830.html