ESCOMP / CCPPStandardNames

Repository for community-accepted CCPP Standard Names and search tools
Other
3 stars 16 forks source link

Units for relative humidity #26

Open climbfuji opened 2 years ago

climbfuji commented 2 years ago

Relative humidity in the ccpp-physics library / UFS / SCM takes all sorts of units, I found 1, frac, none, and even % so far. According to the standard name rules, the unit should be 1. Please confirm and I will make the corresponding changes.

If those quantities that have % are indeed percentages, then do we need another standard name, or do we simply define percent as a valid unit (the symbol can cause all sorts of trouble) and register a unit conversion from percent to one and vice versa?

climbfuji commented 2 years ago

Relative humidity in the ccpp-physics library / UFS / SCM takes all sorts of units, I found 1, frac, none, and even % so far. According to the standard name rules, the unit should be 1. Please confirm and I will make the corresponding changes.

If those quantities that have % are indeed percentages, then do we need another standard name, or do we simply define percent as a valid unit (the symbol can cause all sorts of trouble) and register a unit conversion from percent to one and vice versa?

Update. Those quantities are not percentages, they have an upper bound of 1. Leaves the question if we should use 1 as per the rules (my preference) or any of the other units that are in the metadata.

gold2718 commented 2 years ago

percent is a valid unit in UDUNITS so I vote for that for true percentages. We can have it be equivalent to 1 (although it would be responsible to see if that ends up making sense or is just a lazy way to get things to work).

climbfuji commented 2 years ago

Agreed. The quantities in the UFS/ccpp-physics library definitely range from 0 to 1 and are therefore not percentages. But we should add percent to the rules.

climbfuji commented 2 years ago

@gold2718 EMC would prefer fraction as unit for relative humidity that is not a percentage, i.e. that ranges from zero to one, rather than 1. I am ok with fraction, and I think we can also add an "identify" unit conversion from 1 to fraction to allow both versions. What do you think? Also asking @cacraigucar @ligiabernardet @grantfirl for their opinion.

gold2718 commented 2 years ago

I agree that a value that varies between zero and one is a fraction and not a percent so relative humidity should be represented as a fraction (1). The unit, percent should be reserved for quantities that range from zero to one hundred. fraction is not in UDUNITS and there is feeling among at least some of the maintainers that units should not include information about the physical quantity. I think we should stick with 1 rather than purposely ignore a standard.

junwang-noaa commented 2 years ago

Just a comment, I feel using unit "1" to represent fraction, not integer number is a little confusing. But If it is a specific standard, it's fine to me.

climbfuji commented 2 years ago

I am also not entirely sure about this. One can mean anything, it's got no information other than that the quantity in question is a number (which variable is not a number?). fraction, on the other hand, indicates that it is something of the form of A/B with 0<=A<=B. So, to me using 1 means losing information that fraction contains,

gold2718 commented 2 years ago

These are all good points, they get me thinking that we should be clear on the purpose of units in the CCPP world. One obvious purpose is to clarify a value when there can be different units for the same physical quantity and to provide a mechanism for converting when necessary. Is there a further purpose, especially for dimensionless physical quantities?

dudhia commented 2 years ago

Dimensionless would be a fair description of these types of variables. Perhaps a blank unit field or - could convey this.

On Wed, Nov 10, 2021 at 7:06 PM goldy @.***> wrote:

These are all good points, they get me thinking that we should be clear on the purpose of units in the CCPP world. One obvious purpose is to clarify a value when there can be different units for the same physical quantity and to provide a mechanism for converting when necessary. Is there a further purpose, especially for dimensionless physical quantities?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CCPPStandardNames/issues/26#issuecomment-965925397, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEIZ77GKDCAFSY5RBHPIA4LULMQL5ANCNFSM5HMY24RA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

cacraigucar commented 2 years ago

Values that can be fraction or percent are still used in calculations. Knowing whether a field (relative_humidity) in this case is specified as a fraction or percent would be useful and could be auto-converted by the CCPP if needed. That way, CCPP methods can specify these quantities in the way they see fit. So while technically this is "dimensionless", fraction vs percent does carry a mathematical qualifier that is useful for calculations. As such, I believe we should allow both names.

dudhia commented 2 years ago

I agree percent is definitely a unit and fraction would be a number in the 0-1 range. These are special cases.

On Thu, Nov 11, 2021 at 10:48 AM cacraigucar @.***> wrote:

Values that can be fraction or percent are still used in calculations. Knowing whether a field (relative_humidity) in this case is specified as a fraction or percent would be useful and could be auto-converted by the CCPP if needed. That way, CCPP methods can specify these quantities in the way they see fit. So while technically this is "dimensionless", fraction vs percent does carry a mathematical qualifier that is useful for calculations. As such, I believe we should allow both names.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CCPPStandardNames/issues/26#issuecomment-966499075, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEIZ77HMTG3A3CFV7UWIR2LULP6X5ANCNFSM5HMY24RA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

climbfuji commented 2 years ago

Let's talk about this at the next CCPP framework meeting 2021/11/18. I'll add it to the agenda. @dudhia if you are interested in participating at the discussion, please join us at 9.30am MT.

dudhia commented 2 years ago

I won't be there, but special types of numbers I can think of are fraction percent count index It would be good to know what numbers fall outside these categories, but I prefer dimensionless over 1 as a unit, Jimy

On Tue, Nov 16, 2021 at 8:38 AM Dom Heinzeller @.***> wrote:

Let's talk about this at the next CCPP framework meeting 2021/11/18. I'll add it to the agenda.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ESCOMP/CCPPStandardNames/issues/26#issuecomment-970396162, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEIZ77DSIR5DA6CBM7Q474LUMJ3IZANCNFSM5HMY24RA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

MarekWlasak commented 7 months ago

Hi all. Was there a conclusion to this debate?

cacraigucar commented 6 months ago

@MarekWlasak - I use the section on units in: https://github.com/ESCOMP/CCPPStandardNames/blob/main/StandardNamesRules.rst to get my units.

Also, in the dictionary: relative_humidity: Relative humidity real(kind=kind_phys): units = 1

I remember discussions about this. Based on how old this issue is, I believe it has been resolved and the information was updated in the Rules and Dictionary. Maybe the issue was forgotten to be closed? I will defer to @mkavulich for the final say on this though.

mkavulich commented 6 months ago

@cacraigucar This was before my time (or maybe right after I started on this team) so I don't recall how this was resolved! I think this might actually require at least a brief discussion next Monday, because even though the current dictionary shows units = 1 for relative humidity, based on my reading of the rules, the above discussion, and the current state of ufs-weather-model, it should actually either be "units = percent" or "units = frac".

mkavulich commented 6 months ago

@MarekWlasak I have opened #62 to clarify the rules regarding fraction vs percent. We have also discussed including a converter within the CCPP framework to automatically convert between the two with the proper metadata, but that will probably hinge on the resolution of this ccpp-framework discussion.