Insert return calls right after offending call to subroutines if an error occurs

[matusmartini]

Description of Changes:

The issue: Some subroutines do not have return statements after an error occurs. Instead two variables errflg and errmsg are reset or re-initialized in subsequent calls, and if an error occurs it is not captured and the program continues without stopping. Please note that some calls already have if(errflg/=0) return in place.

This PR fixes an issue to return right after an error occurs. Subroutines that use errflg and errmsg should be checked for errflg and abort if necessary. Insert if(errflg/=0) return after such calls.

In addition the following is added:

1. Remove unnecessary return statements at the end of subroutines. In one case, there were actually two return statements right after each other.
2. Improve error messages and remove duplicate print statements if they are the same as the errmsg.
3. Change “can not” to “cannot” and other minor additions.

UPDATE: Thanks to reviewers' feedback, this PR also includes cleanup of GFS_phys_time_vary.fv3.F90 to remove copy_error calls from one-thread region (accessing errmsg and errflg directly).

Tests Conducted:

None with the current head of the repo. Only quick tests with an older hash with NEPTUNE. We would like to adopt this ccpp error (errflg and errmsg) handling on our next upgrade but we need this PR (once reviewed and approved) to be merged first.

Dependencies:

None

[matusmartini]

FYI @climbfuji and thank you for your input on these modifications

[climbfuji]

This is a great cleanup, thank you!

I know that some people consider a return before the end of a program unit as good programming, I don't have a strong opinion. It's up to the codeowners of these files, but if we can have it consistent then that's nice, of course.

[grantfirl]

@matusmartini Could you please merge the main branch into this branch?

[grantfirl]

@AnningCheng-NOAA Could you please review changes to the MG microphysics code here?

[grantfirl]

I've always wondered why there were return statements right before the end of a subroutine when the end of the subroutine returns anyway. Apparently, according to SO, this was once considered good practice? Seems strange to me.

[grantfirl]

@matusmartini All of these changes seem fine to me. The only push back that I could imagine is if some developer wanted their scheme to complete even if there is an internal error. I don't know why someone would want to though (perhaps debugging reasons?).

[grantfirl]

FYI, this passes the SCM RTs in NCAR/ccpp-scm#596

[matusmartini]

@matusmartini Could you please merge the main branch into this branch?

Done. No conflicts

[AnningCheng-NOAA]

@AnningCheng-NOAA Could you please review changes to the MG microphysics code here?

looks fine to me.

[AnningCheng-NOAA]

I prefer to see different solutions for different threads.

…

On Tue, Jun 24, 2025 at 2:10 PM Grant Firl ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In physics/Interstitials/UFS_SCM_NEPTUNE/GFS_phys_time_vary.fv3.F90 <#1141 (comment)>: > @@ -229,6 +229,7 @@ subroutine GFS_phys_time_vary_init ( myerrmsg = 'read_aerdata failed without a message' call read_aerdata (me,master,iflip,idate,myerrmsg,myerrflg) call copy_error(myerrmsg, myerrflg, errmsg, errflg) Would you like to see a different solution to all threads updating the same errmsg and errflag, overwriting each other? — Reply to this email directly, view it on GitHub <#1141 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALQPMILZIBZGHXKPKXSVR533FGH7TAVCNFSM6AAAAAB6WE6KISVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDSNJUHA2DKOJTGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[climbfuji]

Looks good to me now

[matusmartini]

@grantfirl I do not know what is the best course of actions. Feel free to let me know when this PR is good to go and I could merge main and resolve conflicts?

[grantfirl]

I've combined this into #1159, so I'm going to close it. There isn't anything left to do. All tests pass and all combined PRs have been approved, so will merge shortly.

[grantfirl]

Closing since combined with #1159