[release/v1] Remove "kind" from standard name entries

[mkavulich]

The current standard name entries include a "type" element that has information about the variable units, type and kind. As an example:

    <standard_name name="exner_function"
                   long_name="exner function, (p/p0)^(Rd/cp), where p0 is 1000 hPa">
      <type kind="kind_phys" units="1">real</type>
    </standard_name>

While units and type are both important to distinguishing the use of a variable, the "kind" entry is a vestige of this dictionary's origin in a UFS context for CCPP, and is not generalizable to other contexts. My opinion is that this information should be removed, but I am hoping to hear others' opinions.

[gold2718]

While I'm not sure "... vestige of this dictionary's origin in a UFS context ..." is accurate (I created it in 2020 without any UFS-specific variables), I agree that kind is a variable property, not a physical one.

On the other hand, it is a useful entry for CCPP users in that it indicates the 'normal' usage of the standard name. Use of standard kind and units properties lowers the cost of calling a scheme by avoiding unnecessary kind and unit conversions. Is there a way to generalize the dictionary beyond the CCPP without making it less useful to the CCPP community?

[mkavulich]

@gold2718 I agree that information about 'normal' usage can be useful, but I can't see what additional information is carried by this kind field that isn't covered by the type and units properties. The current kind entries (e.g. kind_phys) are UFS-specific and don't really offer much information outside of that context, and I am having trouble thinking of a reason why such specificity is useful in the standard names dictionary.

[gold2718]

@mkaulich, why do you say this is UFS specific? For instance, all the CESM real variables are also kind_phys. Using kind_phys helps ensure compatibility. If you do not want it listed with most of the standard names in the dictionary, perhaps replace it with a discussion about its use in the community and the reasons one might choose a different kind. Also, the kind options for character type standard names should be discussed.

[climbfuji]

I agreee with @gold2718 - kind_phys is a somewhat universal identifier for the kind of real variables used by the physics (and similar for dynamics). NEPTUNE also uses kind_phys, for example.

[dustinswales]

@gold2718 @climbfuji I'm also struggling to see the purpose of kind in the standard_name dictionary.
Isn't kind just the (parameterized) working precision set by the model, which could change from host-to-host? (it's coincidental that both CESM and UFS use the name kind_phys to define the working precision)
Also, what if a model uses fields in some mixed precision ecosystem (i.e. requiring some fields to be a higher/lower-precision than the working precision)? In this case, having the precision attached to the standard_name reduces portability. No?

[gold2718]

@dustinswales, good questions. A couple of responses:

it's coincidental that both CESM and UFS use the name kind_phys to define the working precision

Not really. This was discussed when we were a small group many years ago. There has always been a desire for more interoperability between WRF physics and CESM* and kind_phys emerged as a good standard.

Also, what if a model uses fields in some mixed precision ecosystem

In my mind, this is an advantage of the kind_phys ecosystem. If your parameterization uses kind_phys, you can usually be sure you are not going through precision conversion operations. By defining and using other kinds (fairly easy with capgen), you can be fairly sure how precision is going to be handled for your suite.

In this case, having the precision attached to the standard_name reduces portability

The idea is that kind_phys is the default, most portable precision to use. Using other kinds will potentially introduce precision shifts (which can kill a parameterization in some circumstances).

This is why I think an introductory paragraph about all this might be just as good if not better than the current method. On the other hand, I do not see the value of just removing all kind information.

---

• at least from the CESM side even though CESM-CAM physics is mostly 'upside down'.

[climbfuji]

@dustinswales, good questions. A couple of responses:

it's coincidental that both CESM and UFS use the name kind_phys to define the working precision

Not really. This was discussed when we were a small group many years ago. There has always been a desire for more interoperability between WRF physics and CESM* and kind_phys emerged as a good standard.

Also, what if a model uses fields in some mixed precision ecosystem

In my mind, this is an advantage of the kind_phys ecosystem. If your parameterization uses kind_phys, you can usually be sure you are not going through precision conversion operations. By defining and using other kinds (fairly easy with capgen), you can be fairly sure how precision is going to be handled for your suite.

In this case, having the precision attached to the standard_name reduces portability

The idea is that kind_phys is the default, most portable precision to use. Using other kinds will potentially introduce precision shifts (which can kill a parameterization in some circumstances).

This is why I think an introductory paragraph about all this might be just as good if not better than the current method. On the other hand, I do not see the value of just removing all kind information.

• at least from the CESM side even though CESM-CAM physics is mostly 'upside down'.

Thanks @gold2718 this is also my recollection from the old days in the window-less meeting room in FL2 :-)

[dustinswales]

Thanks @gold2718. I agree that using the same name for the working precision across hosts helps portability.
My concern was more about having kind in the standard_name library with the recent expanded use of this library.

For example, if/when ESMF contributes to the library, does it make sense for them to provide a kind for their fields, which could beholden to the precision and naming convention of the various ESMF enabled host(s)? (Maybe this is not an issue @DanRosen?)

@dustinswales, good questions. A couple of responses:

it's coincidental that both CESM and UFS use the name kind_phys to define the working precision

Not really. This was discussed when we were a small group many years ago. There has always been a desire for more interoperability between WRF physics and CESM* and kind_phys emerged as a good standard.

Also, what if a model uses fields in some mixed precision ecosystem

In my mind, this is an advantage of the kind_phys ecosystem. If your parameterization uses kind_phys, you can usually be sure you are not going through precision conversion operations. By defining and using other kinds (fairly easy with capgen), you can be fairly sure how precision is going to be handled for your suite.

In this case, having the precision attached to the standard_name reduces portability

The idea is that kind_phys is the default, most portable precision to use. Using other kinds will potentially introduce precision shifts (which can kill a parameterization in some circumstances).

This is why I think an introductory paragraph about all this might be just as good if not better than the current method. On the other hand, I do not see the value of just removing all kind information.

• at least from the CESM side even though CESM-CAM physics is mostly 'upside down'.

[mkavulich]

@dustinswales Thanks for chiming in and putting my thoughts into much better words. I do agree that this sort of "kind" interoperability needs to be documented better (maybe in the CCPP Technical documentation?) if it will truly realize its benefits. But I also still share the concerns of its specification here as its use expands to non-CCPP contexts that may have more "gotchas".

Mainly what I'm hearing from this discussion (and I could be wrong) is that it's beneficial for CCPP-based physics and hosts to all use this kind_phys to avoid potential precision problems when passing data around...but if that's what all components should be using for all reals, then isn't this redundant information anyway? In which case, removing this as a property in the XML and replacing it with more thorough documentation would be better, which is I think what @gold2718 was proposing here?

[mkavulich]

Resolved by #129; Documentation updates being tracked in NCAR/ccpp-doc#78