Error with `SMS_D_Lh4.ne4pg2_ne4pg2.F2010-SCREAMv1.pm-cpu_gnu.eamxx-prod` Fortran runtime error: Pointer argument 'cospout' is not associated
With following GNU DEBUG test:
SMS_D_Lh4.ne4pg2_ne4pg2.F2010-SCREAMv1.pm-cpu_gnu.eamxx-prod
59: At line 502 of file /global/cfs/cdirs/e3sm/ndk/repos/ndk_mf_alvarez-module-updates-feb2025/components/eam/src/physics/cosp2/external/src/cosp.F90
59: Fortran runtime error: Pointer argument 'cospout' is not associated
The non-debug test completes.
Also, Intel compiler DEBUG completes.
xref: https://github.com/E3SM-Project/E3SM/issues/6951
Noting that after NERSC maintenance, and looking at the new issues with DEBUG cases, this case still fails in the same way.
Same error with June18th checkout
I think we can correct this error with:
if (associated(cospOUT%isccp_meantb)) then
if (size(cospOUT%isccp_meantb) .eq. stop_idx) lrttov_cleanUp = .true.
end if
It fixes this issue (will make PR), but then I think there may be other similar issues in other parts of the code that I could make another PR for. Ack, I now see this code is in external submodule so I can't easily make a PR.
Ben notes that with eam, we use components/eam/src/physics/cosp2/local/cosp.F90, but eamxx uses components/eam/src/physics/cosp2/external/src/cosp.F90.
Yeah, the fix seems simple. But the submodule org makes this a longer process. I'm ok switching to a local copy like EAM. Does it make sense to still have a cosp submodule then? Who uses it besides eamxx, given that EAM has its local copy?
Sorry I didn't look at this sooner, but yes we would still need the cosp submodule because this is only a very small piece of COSP, all the actual simulators are still used from the submodule, this is just interface code.
Also, it looks like this is fixed upstream in COSP, so we probably just need a PR to pull in the latest COSP dev. See https://github.com/CFMIP/COSPv2.0/blob/master/src/cosp.F90:
if (associated(cospOUT%isccp_meantb) .and. size(cospOUT%isccp_meantb) .eq. stop_idx) lrttov_cleanUp = .true.