Add miscellaneous atmosphere variables #71
Conversation
svahl991
requested review from
nusbaume,
mkavulich,
climbfuji and
gthompsnJCSDA
|
Tagging @BenjaminTJohnson since some of these variables are used with CRTM. |
|
@mkavulich My interpretation is that surface variables try to be at the surface, not 2m or 10m above the surface if something closer is available. We do frequently use 2m or sometimes 10m variables to replace surface variables, but the strict definition of "surface" is the value exactly at the boundary (e.g., the temperature of the land, ocean, ice, snow, etc.). Having said that, "surface wind speed" is subject to all sorts of qualifications of what the actual physical interpretation is, but my understanding is that "surface wind speed" should be: "the available wind speed information that is closest to the surface". If one only has 2m and 10m wind speed from the model, then you should probably use the 2m as the surface wind speed. If we want to get into semantics, and maybe we do, then we may wish to differentiate "near surface" from "surface" and "surface on the atmosphere side" vs. "surface on the surface side". If you think of the surface as a boundary: one can approach that boundary "below" (e.g., from the ocean depths toward the ocean surface) vs. approaching it from "above" (e.g., from the atmosphere down to the ocean surface). One clear example is temperature profile in the upper ocean, vs. temperature profile in the lower atmosphere. |
|
For RTTOV the explanation @BenjaminTJohnson has given is also true. The surface T for instance is used to calculate the near surface layer contribution to the radiance. The model generally produces 2m values apart from winds which are normally 10m. As discussed previously RTTOV also has a skin temperature which can vary per channel and represents the temperature of the surface. |
|
Given the responses above , I think it's been established that the "surface" variables, at least in principle, represent a different concept than the "2m" and "10m" variables, and so are worthy of their own names being added to CCPP. And having |
|
We had a discussion between the CCPP standard names maintainers and the suggestion was to avoid the inconsistency that variables at the "surface" (whatever that is) have |
|
So, to make sure I understand, rather than change this PR, the plan is to accept it as it is for now, and then if/when #72 is accepted, all the variables that currently start with On a related note, I have been wondering about the status of the issue regarding the tagging of the naming standards since they seem to be pretty fluid. |
|
As far as I understand, you hardcode the CCPP standard names into the actual C++ code. Therefore, you need to decide whether you want to have this merged and then change your standard names later when/if #72 is merged, or you want to do this all at once. (I don't have a preference, but if you want to merge this PR first then I will approve with a note that those names will liekly be changed alongside others.) |
Given that we do hardcode CCPP names into JEDI C++ code, and that it takes non-trivial coordinated effort to change them, and that it is only going to become more difficult to change them as JEDI becomes operational in more organizations, I would prefer do this all at once if #72 is going to be merged. We will be having a code sprint the week of Oct. 7 where we will updating many variable names in JEDI. So if it is highly probable that #72 will go through, we will probably want to switch to the new names during that sprint. If it is possible for us to know the fate of #72 before our sprint (even if it is not fully completed), that would be helpful. Tagging @shlyaeva |
|
Given the ongoing discussion regarding #72, I have now removed all variables with the |
|
Can we have one more approval before we merge, please? |
This adds some new variable names, used in the JEDI system, that are mostly usual variants of existing CCPP variable names. They concern winds, temperature, and relative humidity.
Perhaps the newest concept introduced here isremoved from this PRsurface_wind_from_direction. I did not find any other existing CCPP variable names with direction expressed in degrees like this one.