Update master from dtc/develop 2020/03/17

[climbfuji]

See ufs-community/ufs-weather-model#84 for a description of the changes.

Associated PRs:

NOAA-EMC/NEMS#43
NCAR/ccpp-physics#410
#268
NOAA-EMC/fv3atm#81
ufs-community/ufs-weather-model#84

See ufs-community/ufs-weather-model#84 for regression testing information.

[climbfuji]

@junwang-noaa @DusanJovic-NOAA

[gold2718]

This looks okay but in investigating the change, I came across this comment in ccpp_prebuild:

each variable can be passed to a subroutine only once, there can be no overlapping/conflicting

Does this mean there should be a check that no subroutine has two dummy arguments with the same standard_name property? I do not think I have such a check now. The only use cases I can think of are to do unit conversion or kind conversion but the framework should handle both of those.

[climbfuji]

This looks okay but in investigating the change, I came across this comment in ccpp_prebuild:

each variable can be passed to a subroutine only once, there can be no overlapping/conflicting

Does this mean there should be a check that no subroutine has two dummy arguments with the same standard_name property? I do not think I have such a check now. The only use cases I can think of are to do unit conversion or kind conversion but the framework should handle both of those.

Yes, that is correct - a standard_name can only appear once in the metadata for a specific subroutine. This would be a dangerous feature to have - what happens if both variables were modified inside in a different way?

[gold2718]

This would be a dangerous feature to have - what happens if both variables were modified inside in a different way?

That is obviously a bad thing but what if one was intent(in) and the other intent(out)? My point is not that we should not have the check but that we should make sure we remove any need to have something like this. Based on my limited imagination of the weird things scheme writers do, I think we have the bases covered but an explicit check is needed (which I will make sure is in the capgen version).

[gold2718]

Update: That check is already active because a scheme's variables are in a VarDictionary object and add_variable is only ever called with exists_ok=False (the default value).

As Emily Litella said, "Never mind"

[llpcarson]

approved