Last minute NUOPC Connector items for ESMF 8.7

[theurich]

Adding connection options support for regridding method "conserve_2nd" and extrapolation method "nearest_d". NRL NEPTUNE developers are hoping to use "conserve_2nd" with ESMF 8.7.

This PR also removes old code from NUOPC_Connector that has been inactive for several releases now. This is code that had been under the #ifdef USE_ESMF_RHL #else branches.

[danrosen25]

Looks good as long as the tests pass. We don't have explicit tests for remapMethod and they would be located with the NUOPC app prototypes. I didn't know that type RHL was moved into the ESMF library as ESMF_RHL. We should consider moving this to ESMF_RouteHandleList in the future but that's a bigger cleanup.

[danrosen25]

@theurich @billsacks
I looked at the failure and it's an issue I've seen before and I still approve this PR with this failure. There was an issue for it but it was closed without resolving.

20240910 215612.746 INFO             PET4  FAIL  Check time delay on non-blocking Component D Finalize/wait, ESMF_CompTunnelUTest.F90, line 1283:  Incorrect time delay
20240910 215612.746 INFO             PET4  delayTime (wait) =    2.9923109999999973

What's happening is that the time between ESMF_GridCompFinalize and ESMF_GridCompWait is less 3 seconds but the test assumes it will take greater than 3 seconds. Mac OS systems are finishing too quickly!

esmf/src/Superstructure/Component/tests/ESMF_CompTunnelUTest.F90

Line 1255 in 9379ba6

call ESMF_GridCompFinalize(dualCompD, syncflag=ESMF_SYNC_NONBLOCKING, &

esmf/src/Superstructure/Component/tests/ESMF_CompTunnelUTest.F90

Line 1267 in 9379ba6

call ESMF_GridCompWait(dualCompD, userRc=userRc, rc=rc)

A possible solution could be to change the test to be something much smaller, like 1 second. I'm not sure why it's 3 seconds.

esmf/src/Superstructure/Component/tests/ESMF_CompTunnelUTest.F90

Line 1283 in 9379ba6

call ESMF_Test(delayTime > SLEEPTIME-2*precTime, name, failMsg, result, ESMF_SRCLINE)

[theurich]

There are several reasons the CompTunnelUTest can fail. #237 discusses the socket issues. Here it is a timing issue - which is different.
There is a call to ESMF_VMWtimeDelay with 3 seconds in the test. The 3s are set by macro SLEEPTIME. For some reason either the clock precision is not determined correctly or there is some drifting of the clock or the WtimeDelay.. but just sometimes. I guess we could build in a larger tolerance than just 2x the clock precision. But it is a strange thing why Macs would need that.

[oehmke]

Looks good to me.

[danrosen25]

@theurich
Okay, I see. I did think it was odd that finalize was expected to take longer than 3 seconds but now I see the call to ESMF_VMWtimeDelay. I assume that the ESMF_VMWtimeDelay calls sleep under the hood? It doesn't seem possible that the time between ESMF_VMWtime calls is less than 3 seconds. So I assume there's something going on within the system. I believe the runners are VMs so it's possible that the VM server messes around with the system clock?