Open tclune opened 2 years ago
This issue has been automatically marked as stale because it has not had recent activity. If there are no updates within 7 days, it will be closed. You can add the "long term" tag to prevent the Stale bot from closing this issue.
Obviously marking long-term.
Query for @tclune I'm guessing the VERIFY_ESMF_
we have in NUOPC_ErrLog.h
is not the same as what this wants?
Correct. Though important to keep in mind these others exist already.
Turns out this macro already exists, but ... recent experience shows that it is important to check the ESMF RC code first. This is because certain failures will leave the user RC unassigned which leads to confusing results.
Not sure what the best solution is, but reversing the checks in this PR. (And exercising in MAPL3)
Several ESMF procedures return 2 (optional) error codes. One for ESMF internal and one for user code that is called within. Usually the former is
rc
and the latter isuserRc
. Currently MAPL uses a combination of two macros to check these cases, but it happens just often enough that a new macro that checks both would possibly be useful. The counter argument would be if we were to start returning different messages depending on which failed.Suggested names for new macro are
_VERIFY_ESMF
or_VERIFY_USER
.