Use ESMF_LOGKIND_MULTI_ON_ERROR for logging ESMF errors #137
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
GEOS sets
cap_options%esmf_logging_mode
via FLAP. Since we don't use FLAP we get the default value ofESMF_LOGKIND_NONE
. IIUC this means ESMF errors dont' get logged anywhere. I'm not exactly sure whether we will ever get any ESMF errors, butESMF_LOGKIND_MULTI_ON_ERROR
seems like a more reasonable default thenESMF_LOGKIND_NONE
. The "multi on error" means that each PET will dump errors to a PETXX file only if an error happens. If no error happens there are not PET* files.I came across this option when I was troubleshooting #134. I was wondering why the
ESMF_ConfigGetAttribute()
call wasn't reporting a useful error message. It turns out that was something else, but I figured I should update this default setting anyway in the hopes it will aid in improving error messages.Related