Support for initial conditions from WOA in situ temperature and practical salinity climatology, offline horizontally regridded to model grid

[matsbn]

With this PR, BLOM can start integration from initial conditions from WOA climatology of in situ temperature and practical salinity. The WOA climatology must be offline horizontally regridded to model grid, and only ALE vertical coordinates are supported for now. Eventually, this should be merged with the functionality in #573 for online regridding of the WOA climatology in the NUOPC framework.

The application of previous initial conditions are still supported. The variables in the file specified by the namelist variable icfile are inspected to detect the type of initial conditions. Currently, 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

For the conversion from in situ temperature to potential temperature, the Gibbs SeaWater (GSW) Oceanographic Toolbox of TEOS-10 has been incorporated as a git submodule.

[TomasTorsvik]

@matsbn - Thanks for the PR!

As I understand it, this PR should go before #573 , as it provides the library for reading in WOA18 standard variables that will be converted to model internal variables. Is that correct? I'm a bit uncertain if you really mean to merge the two PRs, as the current approach seems to be a two-step implementation (I think a two-step approach is cleaner).

I was looking for a tag for the TEOS-10/GSW-Fortran library, but I see that the last tag is from 2017 and last update on master is from 2 years ago. Perhaps this is not a problem since the TEOS-10 definitions do not change.

[mvertens]

I think given that there will be two ways to do the input - nuopc and what is implemented here - the vertical remapping should be split up into its own file - so that it an be leveraged by #573. Then there will be the read you have here and the read that is in #573. It would be helpful to have the modularity in place that could clarify what needs to be done in the nuopc interface to leverage the vertical remapping.

[mvertens]

@matsbn @TomasTorsvik - is the plan to have #573 in place for the June freeze?

[matsbn]

@matsbn - Thanks for the PR!

As I understand it, this PR should go before #573 , as it provides the library for reading in WOA18 standard variables that will be converted to model internal variables. Is that correct? I'm a bit uncertain if you really mean to merge the two PRs, as the current approach seems to be a two-step implementation (I think a two-step approach is cleaner).

I was looking for a tag for the TEOS-10/GSW-Fortran library, but I see that the last tag is from 2017 and last update on master is from 2 years ago. Perhaps this is not a problem since the TEOS-10 definitions do not change.

It could be that the right order is to merge this before #573 as a first step of a two-step process, but I am open to discuss this, particularly with @mvertens. I anyway want the ability to read in WOA data that are offline regridded to be able to do efficient development in standalone BLOM configurations.

I was not so happy with the tagging in the TEOS-10/GSW-Fortran library, as there are bugfixes in master which are not in any tags. Although not ideal, I think the master branch is the right one to use for now. Maybe there are som "fx*" lines missing in .gitmodules for git-fleximod?

[matsbn]

I think given that there will be two ways to do the input - nuopc and what is implemented here - the vertical remapping should be split up into its own file - so that it an be leveraged by #573. Then there will be the read you have here and the read that is in #573. It would be helpful to have the modularity in place that could clarify what needs to be done in the nuopc interface to leverage the vertical remapping.

I guess there are many ways to do this. I felt it was most natural to keep the vertical regridding out of the NUOPC interface. The mod_inicon.F90 here contains public arrays

  real(r8), allocatable, dimension(:,:,:) :: t_woa, s_woa
  real(r8), allocatable, dimension(:,:) :: depth_bnds_woa
  real(r8), allocatable, dimension(:) :: depth_woa 

and also a public logical variable woa_nuopc_provided which currently is hard-coded to .false.. If the above arrays are allocated and filled via the nuopc interface, woa_nuopc_provided should be set to .true. and the routine inicon_woa_file will proceed to use these arrays directly.

Probably another chat would be useful on this topic, @mvertens.

[mvertens]

@matsbn - definitely another chat would be useful. I was not suggesting that we should move the vertical regridding into the nuopc interface - only that it appear in a modular way not tied in to reading the offline regridding. This is a design issue that will keep coming up as online regridding is added for initial data. I just ran into this issue yesterday in terms of getting the riverin input working. I'm happy to talk this afternoon or tomorrow other than at 2-3.

[TomasTorsvik]

@matsbn - Yes, I meant to say that we should not use the tag version of the TEOS-10/GSW-Fortran library, as this is clearly outdated. I don't think we need "fx*" lines to pull the latest version of the master branch.

[mvertens]

@matsbn - simply creating another subroutine in mod_inicon.F90 that reads in the offline data but does not do any vertial interpolation would address what I am suggesting. Other than that I agree with you that the noupc ocn_map_woa18.F90 in #573 could simply fill in the module public arrays

  real(r8), allocatable, dimension(:,:,:) :: t_woa, s_woa
  real(r8), allocatable, dimension(:,:) :: depth_bnds_woa
  real(r8), allocatable, dimension(:) :: depth_woa 

This same type of logic can equally be used for the riverin input.

[JorgSchwinger]

This same type of logic can equally be used for the riverin input.

@mvertens for the riverine input, isn't it probably best to follow closely what you have done for the dust-stream? The difference being that there is the special re-mapping files that are not necessary for the dust.

[mvertens]

@JorgSchwinger - that is exactly what I am sugggesting. I have a new module in driver/nuopc - ocn_map_river_nutrients.F90 and I think what we want to do is to fill in the array
real, allocatable, public :: rivflx(:,:,:)
and bypass ini_read_rivin.
Does that sound reasonable?
I have validated that the riverin mapping is working correctly. But that is in another PR that I'll bring in.

[jmaerz]

I am not entirely sure, but I would expect that git fleximod also supports the sha number of e.g. the master so that the behavior of the TEOS can at least be expected to be fixed. Maybe worth giving it a try.

[matsbn]

PR updated based on discussion with @mvertens:

• Reading of regridded WOA climatology separated out into own routine.
• blom_init split into blom_init_phase1 and blom_init_phase2 to allow specifying woa_nuopc_provided correctly based on namelist processing, before NUOPC mapping of WOA climatology.
• Made additional variables public in mod_inicon.F90 that must be specified when obtaining the WOA climatology. Those are: t_woa_fval, s_woa_fval, kdm_woa.
• Added woa_nuopc_provided in namelist. This is currently .false., also for NUOPC but this can be altered in namelist_definition_blom.xml when ready.

[mvertens]

@matsbn - I am trying to run the latest code here with the nuopc cap - but keeping woa_nuopc_provided=.false.
I've run into several problems.

• I started by only having the following in user_nl_blom
  icfile = /cluster/shared/noresm/inputdata/ocn/blom/inicon/woa18_decav_ts13_01_tnx1v4_20250514.nc
  I got an error - Initial conditions from WOA require sigref_spec == 'namelist'!
• I then added the following to user_nl_blom
  sigref_spec = 'namelist'
  I then got an error - because I did not specify sigref in my namelist

 readnml_vcoord: vertical coordinate variables:
   vcoord_type =            cntiso_hybrid
   dpmin_surface =             2.50000000000000
   dpmin_inflation_factor =    1.08000000000000
   sigref_spec =            namelist
   plevel_spec =            inflation
 readnml_vcoord: number of sigref values does not match vertical dimension!

So what values should I use for sigref? How do I get the current code to run with woa_nuopc_provided=.false. ?
Can you point me to a case you have that is working?

[matsbn]

@matsbn - I am trying to run the latest code here with the nuopc cap - but keeping woa_nuopc_provided=.false. I've run into several problems.

• I started by only having the following in user_nl_blom
  icfile = /cluster/shared/noresm/inputdata/ocn/blom/inicon/woa18_decav_ts13_01_tnx1v4_20250514.nc
  I got an error - Initial conditions from WOA require sigref_spec == 'namelist'!
• I then added the following to user_nl_blom
  sigref_spec = 'namelist'
  I then got an error - because I did not specify sigref in my namelist

 readnml_vcoord: vertical coordinate variables:
   vcoord_type =            cntiso_hybrid
   dpmin_surface =             2.50000000000000
   dpmin_inflation_factor =    1.08000000000000
   sigref_spec =            namelist
   plevel_spec =            inflation
 readnml_vcoord: number of sigref values does not match vertical dimension!

So what values should I use for sigref? How do I get the current code to run with woa_nuopc_provided=.false. ? Can you point me to a case you have that is working?

@mvertens, sorry that I did not inform about this earlier. Required namelist settings for sigref_spec and sigref can be found in the file:

/cluster/projects/nn9560k/matsbn/NorESM/cases/NOIIAJRA_TL319_tn14_3.0a3b_woainicon_20250520/user_nl_blom

[mvertens]

@matsbn - thanks. I have merged your changes here into #573 and have verified that with your suggested user_nl_blom settings and woa_nuopc_provided = .true. the results look very reasonable compared to the offline regridding results.