Managing UNDEF values in ESMF components #314
Replies: 4 comments
-
I don't think that we have a standard way to handle this. I'll bring it up at our next ESMF core meeting to see what people have seen in other systems. |
Beta Was this translation helpful? Give feedback.
-
Agree with Bob that there is no standard way of doing this. it is up to user's decision to decide how to use the field value and how to store that meta-data. Bill: CESM has similar use case. 2 use case: (1) value that needs to be flagged and causing model to abort. (2) value needs to be explicitly checked to have special handling. Therefore, if using "NaN" then it maybe tricker across platform. Dan: currently left for users to figure out in user code/user choice. we would recommend using "NaN" but is tricker (see Bill's comment section). may be able to leverage Fieldsfill -> fill entire array across processors with a static value). Regarding "setting an UNDEF value as an attribute in the Field info object." -> the downside is that there is transfering of value across components. Dan has been using global value as a solution, but this was that application choice, not standard way of handling this. Dan is also set connector on zeroregion = select for regridding use cases. (Default is unmapped action = ignore which cause silent failures -> silent ignores) Ufuk: may be tricky to use constant and then perform interpolation, because then the constant may not be the same... and therefore will have problem on the other side of the equation/operation. the workaround would be to leverage mask. |
Beta Was this translation helpful? Give feedback.
-
(1) Currently there is no official best practices to address this issue. this relies on user code. |
Beta Was this translation helpful? Give feedback.
-
the next step lives in this backlog feature ticket: #232 |
Beta Was this translation helpful? Give feedback.
-
I opened an issue about this as well, but subsequently realized that this is probably the better forum for my question.
Our model currently uses a constant value for UNDEF that is used to indicate locations where the field value is undefined. The typical use case is for values that fall below the surface on fixed pressure levels.
However, as we increasingly integrate with components developed elsewhere this approach feels fragile to me. Instead, I suspect we should be setting an UNDEF value as an attribute in the Field info object.
My question is: What do others see as the best practice along these lines?
Beta Was this translation helpful? Give feedback.
All reactions