Well, as an aside, the code I can exercise normally looks like this:
call ESMF_MethodAdd(aero, label='aerosol_optics', userRoutine=aerosol_optics, __RC__)
and this works with Intel and GNU.
I’ve tried these three ways with PGI (14.7 in this case):
call ESMF_MethodAdd(aero, label='aerosol_optics', userRoutine="aerosol_optics", __RC__)
call ESMF_MethodAdd(aero, label='aerosol_optics', userRoutine="gocart_gridcompmod_aerosol_optics", __RC__)
call ESMF_MethodAdd(aero, label='aerosol_optics', userRoutine="gocart_gridcompmod_aerosol_optics_", __RC__)
All will compile, but none will run. The latter call has the userRoutine as I see when I ‘nm GEOSgcm.x | grep aerosol_optics’.
My next thought is that I need to do more. ESMF says:
Name of user-supplied subroutine to be associated with the label, specified as a character string.
The subroutine must have the exact interface shown in ESMF_MethodStateAdd for the userRoutine argument. Arguments in userRoutine must not be declared as optional, and the types, intent and order must match. The subroutine must be either a module scope procedure, or an external procedure that has a matching interface block specified for it. It must not be an internal procedure which is contained within another procedure.
Name of shared object that contains userRoutine. If the sharedObj argument is not provided the executable itself will be searched for userRoutine.
So, aerosol_optics is a subroutine that is only “contained” by the module GOCART_GridCompMod itself, not by a run method or anything.
My fear now is because we compile static not shared that this is just might be undoable within the bounds of ESMF until the F2008 interface is supported.