add new mapping for woa18 input data

[mvertens]

New capability has been added to the BLOM nuopc cap code to use PIO and ESMF to read in and map input 3d or 2d data to the blom horizontal mesh. The input data vertical resolution is still kept.

• mod_io_input.F90: reads in and maps the data (currently supports bilinear and conservative and soon mapping files). The output is an ESMF field bundle.
• mod_io_output.F90: using as input an ESMF field bundle - create a new file with the output from mod_io_input.F90
• ocn_map_woa18.F90: call the above to map the t_an and s_an from the WOA18 data. @matsbn - there is still hard-wired data here - and I am wondering what part of it should be moved to a namelist.

You can see the output from the mapping in the directory
/cluster/work/users/mvertens/noresm/SMS_D_Ld1.T62_tn14.NOINYOC.betzy_intel.woa18/run
and the files
woa18_s_an.nc and woa18_t_an.nc
The output looks reasonable to me.

I will be adding a new option to mod_io_input.F90 that will address using mapping files for the mapping - and use this for the riverine input.

Notes:

• @matsbn - No global data is read in - so it is totally memory scalable. This approach would easily translate to using 0.25 degree versions of the WOA18 data.
• @JorgSchwinger - This approach might also be applicable to reading in
  ! Valid values of vname are:
  ! 'pho' - WOA phosphate
  ! 'nit' - WOA nitrate
  ! 'sil' - WOA silicate
  ! 'oxy' - WOA dissolved oxygen
  ! 'alk' - GLODAP alkalinity
  ! 'dic' - GLODAP dissolved inorganic carbon
  ! 'C13' - Dissolved inorganic 13C carbon isotope
  ! 'd13' - delta13C of dissolved inorganic carbon
  ! 'C14' - Dissolved inorganic 14C carbon isotope
  ! 'd14' - delta14C of dissolved inorganic carbon
  Currently BLOM reads in global 3d data and assigns regions. With the method that I am using for woa18 - no global data is ever read in.

@JorgSchwinger @matsbn - I would be happy to walk through this code to understand if there are new requirements that I could address that are not addressed in this PR.

Testing: Ran aux_blom_noresm test suite using noresm3_0_alpha03d with the following updates
BLOM - this PR
CDEPS - cdeps1.0.70_noresm_v6
CMEPS - cmeps1.0.39_noresm_v3
Compared to noresm3_0_alpha03d_dev1.9.0.17/

• Comparisons to baselines will fail for all tests that use CORE forcing for DATM (T62_tn14 and T62_tn21)
• Otherwise all tests passed except the following expected fails:
• expected fails:

    FAIL ERS_Ld3.T62_tn14_wtn14nw.NOINY_WW3.betzy_gnu.blom-wavice RUN time=57
    FAIL SMS_D_Ld1.T62_tn14_wtn14nw.NOINYOC_WW3.betzy_gnu.blom-wavice RUN time=67
    FAIL SMS_D_Ld1.T62_tn14.NOIIAOC20TR.betzy_intel RUN time=156

    FAIL ERP_Ld3_P256.T62_tn14.NOINYOC.betzy_gnu COMPARE_base_rest - the only two fields that fail this test are the following:

 plon   (x,y)
      10266   138600  (     9,     1) (   290,   305) (     1,     1) (     1,     1)
              138600   9.969209968386869E+36  -1.799967955192592E+02 1.0E+37 -1.095000000000000E+02 7.4E-02 -1.095000000000000E+02
              138600   9.969209968386869E+36  -1.799967955192592E+02          9.969209968386869E+36          9.969209968386869E+36
              138600  (     1,     1) (   290,   305)
          avg abs field values:    1.816180026708286E+36    rms diff: 2.7E+36   avg rel diff(npos):  7.4E-02
                                   1.708000432246137E+36                        avg decimal digits(ndif):  0.0 worst:  0.0
 RMS plon                             2.7132E+36            NORMALIZED  1.5398E+00

 plat   (x,y)
      10266   138600  (     9,     1) (     1,     1) (     1,     1) (     1,     1)
              138600   9.969209968386869E+36  -8.011491140591812E+01 1.0E+37 -8.011491140591812E+01 7.4E-02 -8.011491140591812E+01
              138600   9.969209968386869E+36  -8.011491140591812E+01          9.969209968386869E+36          9.969209968386869E+36
              138600  (     1,     1) (    57,     1)
          avg abs field values:    1.816180026708286E+36    rms diff: 2.7E+36   avg rel diff(npos):  7.4E-02
                                   1.708000432246137E+36                        avg decimal digits(ndif):  0.0 worst:  0.0
 RMS plat                             2.7132E+36            NORMALIZED  1.5398E+00

[mvertens]

@matsbn - I think if we want to still have 'icfile' denote the pre-mapped climatological conditions - then I would suggest that the following two files be merged into one:
filename_t = '/cluster/work/users/matsbn/WOA18/woa18_decav_t13_01.nc'
filename_s = '/cluster/work/users/matsbn/WOA18/woa18_decav_s13_01.nc'
Does that sound reasonable? If so - what should the name be and where should I place it?

[matsbn]

@mvertens ,

@matsbn - I think if we want to still have 'icfile' denote the pre-mapped climatological conditions - then I would suggest that the following two files be merged into one: filename_t = '/cluster/work/users/matsbn/WOA18/woa18_decav_t13_01.nc' filename_s = '/cluster/work/users/matsbn/WOA18/woa18_decav_s13_01.nc' Does that sound reasonable? If so - what should the name be and where should I place it?

Indeed, this is what I have already done when testing offline regridded WOA climatology. As mentioned in #576, climatologies have been regridded for the tnx1v4 and tnx2v1 grids and are available on Betzy here:

/cluster/shared/noresm/inputdata/ocn/blom/inicon/woa18_decav_ts13_01_tnx1v4_20250514.nc
/cluster/shared/noresm/inputdata/ocn/blom/inicon/woa18_decav_ts13_01_tnx2v1_20250514.nc

Here in situ temperature and practical salinity are combined in one file.

[mvertens]

@matsbn - thanks - that makes sense.

[matsbn]

Thanks for the changes, @mvertens! I guess a namelist group for this mapping is a final required step. Will the routine read_map_input_data accept other interpolation methods than 'bilinear', where the method could be specified in the namelist group? Some options for proceeding:

• Merge #576 into master now and then finalise namelist and further testing in this PR.
• Merge these changes into #576 and I can better help finalise namelist and further testing there before merging to master.
• Finalise everything in this PR and abandon #576.

I'm mostly in favour of the first option, since I'm working intensely on #536 where the WOA initial condition is good to build on.

[mvertens]

@matsbn - yes - read_map_input_data accept other interpolation methods than 'bilinear'. Currently it accepts bilinear and conservative. In terms of PR #583 I have also added 'mapfile' and that works fine. I can also add many others that are supported by cmeps - .e.g.

mapnstod          nearest source to destination
mapnstod_consd    nearest source to destination followed by conservative dst
mapnstod_consf    nearest source to destination followed by conservative frac
mappatch_uv3d     rotate u,v to 3d cartesian space, map from src->dest, then rotate back
mapbilnr_uv3d     rotate u,v to 3d cartesian space, map from src->dest, then rotate back
mapfillv_bilnr    fill value followed by bilinear
mapbilnr_nstod    bilinear with nstod extrapolation

I am definitely think the best way forwards is your first option as well:
Merge #576 into master now and then finalise namelist and further testing in this PR.

I think we need a new namelist for the hard-wired variables in ocn_map_woa.F90

mesh_input_file = '/cluster/projects/nn9560k/matsbn/WOA_mesh/WOA_1.00_degree_ESMFmesh_20250506_cdf5.nc'
filename_t = '/cluster/work/users/matsbn/WOA18/woa18_decav_t13_01.nc'
filename_s = '/cluster/work/users/matsbn/WOA18/woa18_decav_s13_01.nc'
fldlist_input_t(1) = 't_an'
fldlist_input_s(1) = 's_an'

What would you suggest for the new namelist group name - or should this go into an existing namelist group?

[TomasTorsvik]

@mvertens - should be fine, but I have left some comments to be addressed before merging.

[TomasTorsvik]

user_nl_blom~ looks like a backup file that has made it into the commit

[mvertens]

Thanks for catching this.

[TomasTorsvik]

For consistency, when defining file names, we have introduced a character length parameter fnmlen that is defined in mod_utility.

Suggested change

	character(len = 256) :: &
	woa_nuopc_icfile_mesh, & ! mesh for woa_nuopc_icfile_data,
	woa_nuopc_icfile_data ! woa file for temperature and salinity
	use mod_utility, only: fnmlen
	...
	character(len = fnmlen) :: &
	woa_nuopc_icfile_mesh, & ! mesh for woa_nuopc_icfile_data,
	woa_nuopc_icfile_data ! woa file for temperature and salinity

[mvertens]

Thanks. I fixed this with your suggestion.

[mvertens]

@matsbn - I think this PR is ready for your review and to be brought into master hopefully before June 15.

[matsbn]

@mvertens, thanks for the recent changes and sorry for responding slowly.

I think it would be clean with a separate namelist group for this. A suggestion is:

&map_woa
  mesh_woa = '$DIN_LOC_ROOT/share/meshes/WOA_1.00_degree_ESMFmesh_20250506_cdf5.nc'
  filename_t = '$DIN_LOC_ROOT/ocn/woa/woa18_decav_t13_01.nc'
  filename_s = '$DIN_LOC_ROOT/ocn/woa/woa18_decav_s13_01.nc'
  varname_t = 't_an'
  varname_s = 's_an'
/

Some comments:

• Not sure if group name map_woa can be identical to subroutine name.
• I suggest to place the WOA mesh together with all the other meshes ($DIN_LOC_ROOT/share/meshes)
• For transparency and traceability I would prefer that we read from the original WOA files, so using the separate files for t and s. For the premapped WOA climatology I did indeed combine t and s in one file, but those were anyway already different from the original. It also makes it easier if we choose to use any other WOA release, e.g. WOA23.
• I would place the WOA files in a folder outside of the BLOM folder since they are not BLOM specific (e.g. $DIN_LOC_ROOT/ocn/woa as suggested above).
• I think the namelist group could be read within the map_woa subroutine, similar to how the stream_* namelist groups are read. The limits namelist group is just very messy as it is and it is an ongoing effort to break it up into more logical subgroups.
• Great that the conserv method is now used. The mapping method could also be a namelist option, but I'm happy with how it is for now.

[mvertens]

@mvertens, thanks for the recent changes and sorry for responding slowly.

I think it would be clean with a separate namelist group for this. A suggestion is:

&map_woa
  mesh_woa = '$DIN_LOC_ROOT/share/meshes/WOA_1.00_degree_ESMFmesh_20250506_cdf5.nc'
  filename_t = '$DIN_LOC_ROOT/ocn/woa/woa18_decav_t13_01.nc'
  filename_s = '$DIN_LOC_ROOT/ocn/woa/woa18_decav_s13_01.nc'
  varname_t = 't_an'
  varname_s = 's_an'
/

Some comments:

• Not sure if group name map_woa can be identical to subroutine name.
• I suggest to place the WOA mesh together with all the other meshes ($DIN_LOC_ROOT/share/meshes)
• For transparency and traceability I would prefer that we read from the original WOA files, so using the separate files for t and s. For the premapped WOA climatology I did indeed combine t and s in one file, but those were anyway already different from the original. It also makes it easier if we choose to use any other WOA release, e.g. WOA23.
• I would place the WOA files in a folder outside of the BLOM folder since they are not BLOM specific (e.g. $DIN_LOC_ROOT/ocn/woa as suggested above).
• I think the namelist group could be read within the map_woa subroutine, similar to how the stream_* namelist groups are read. The limits namelist group is just very messy as it is and it is an ongoing effort to break it up into more logical subgroups.
• Great that the conserv method is now used. The mapping method could also be a namelist option, but I'm happy with how it is for now.

@matsbn - I have implemented these changes with some minor modifications to the naming.

[matsbn]

Looks good now @mvertens, thanks!