Issue with refactored regridding code and FV_PRECISION=R8

[mathomp4]

The recent updates to the regridding code in v1.4.1 have issues with the GEOSctm. The GEOSctm is built with FV_PRECISION=R8 but much of the regridding code assumes R4 (and/or R4R8??).

See GEOS-ESM/GEOSctm#42 for where this was first detected.

[mathomp4]

The first error was simple:

/root/project/GEOSctm/src/Components/GEOSctm_GridComp/@FVdycoreCubed_GridComp/fv_regridding_utils.F90:76:16-47:

   76 |        allocate(this%ptr2d(is:ie,js:je),source=0.0)
      |                1                              2
Error: The allocate-object at (1) and the source-expr at (2) shall have the same kind type parameter

These can be fixed with changing code like that in fv_regridding_utils.F90 to:

allocate(this%ptr2d(is:ie,js:je),source=0.0_FVPRC)

Good enough. But then I hit another issue:

/discover/swdev/mathomp4/Models/GEOSctm-UpdateToGCMmain/GEOSctm/src/Components/GEOSctm_GridComp/@FVdycoreCubed_GridComp/fv_regrid_c2c.F90(350): error #6633: The type of the actual argument differs from the type of the dummy argument.   [GZ0]
         call read_topo_file(fname1,gz0(is_i:ie_i,js_i:je_i),gridIn)
------------------------------------^
/discover/swdev/mathomp4/Models/GEOSctm-UpdateToGCMmain/GEOSctm/src/Components/GEOSctm_GridComp/@FVdycoreCubed_GridComp/fv_regrid_c2c.F90(358): error #6633: The type of the actual argument differs from the type of the dummy argument.   [PHIS]
         call read_topo_file('topo_dynave.data',atm(1)%phis(is:ie,js:je),gridOut)
-------------------------------------------------------^

Okay, I can fix that by changing the input to read_topo_file from:

   real(real4), intent(inout) :: output(:,:)

to:

   real(FVPRC), intent(inout) :: output(:,:)

Once I do that I get:

/discover/swdev/mathomp4/Models/GEOSctm-UpdateToGCMmain/GEOSctm/src/Components/GEOSctm_GridComp/@FVdycoreCubed_GridComp/fv_regrid_c2c.F90(478): error #6285: There is no matching specific subroutine for this generic subroutine call.   [MAPL_VARREAD]
                        call MAPL_VarRead(formatter,vname,gslice_r4,lev=k,offset2=n_ungrid)
-----------------------------^
/discover/swdev/mathomp4/Models/GEOSctm-UpdateToGCMmain/GEOSctm/src/Components/GEOSctm_GridComp/@FVdycoreCubed_GridComp/fv_regrid_c2c.F90(1897): error #6285: There is no matching specific subroutine for this generic subroutine call.   [ARRAYSCATTER]
                        call ArrayScatter(local_array=output,global_array=input,grid=grid,rc=status);if(MAPL_Verify(status,"fv_regrid_c2c.F90",1897 ,rc)) return
-----------------------------^

Oooh boy. I think I'm out of my depth. I think my other changes now change the interface to MAPL calls to ones that don't exist.

Time for @bena-nasa I think. Maybe some "if R8 cast to R4" sort of trick is needed?

[mathomp4]

Query for @mmanyin: Do users of the GEOSctm ever run regrid.pl? I want to say these routines are only used for that (@bena-nasa can answer more correctly), so maybe if the CTM doesn't need the code, we could avoid building it? Not a solution, but in case something is needed for the CTM, it's a workaround.

[mmanyin]

@mathomp4 : Is regrid.pl equipped to handle a single file, e.g. gmichem_internal_rst, or tr_internal_rst? That is the type of regridding that CTM users would benefit from.

[mathomp4]

@mathomp4 : Is regrid.pl equipped to handle a single file, e.g. gmichem_internal_rst, or tr_internal_rst? That is the type of regridding that CTM users would benefit from.

Ooh. I am not sure. My guess is "No", but @bena-nasa can probably answer better for us when he gets back. I think that regrid.pl assumes that users will need the "required" restarts and so looks for them.

Now, this might be more doable in the upcoming Python-based regrid that @weiyuan-jiang is creating as we have more freedom there to add functionality more easily.