TOC(heading=nemo_ConfigurationManager,nemo_ConfigurationManager/*, depth=1)?

nemo_ConfigurationManager

Last edited Timestamp?

This working group (and wiki pages) are under the responsibility of Julien Paul

The goals of this discussion is to define what will do or not the config manager in the next release of NEMO.

The first step is to define:

• what do we need to create regional configuration
• how each team do it now
  • methods
  • language
  • limits of these methods

Schedule:

1. list method used now (>23 Jan)
2. list idea to solve some limitations (> 03 Feb)
3. Define what will do or not the config manager in the next release of NEMO (> 20 Feb)

The schedule is voluntarily short. First, cause this part should have be done last year. Moreover, if we want to have something reliable to put in the next release of NEMO, we must start to merge tools and write skeleton of the config manager at least in Marsh.

1. What do we need to create regional configuration

• coordinates
• bathymetry
• boundary condition
• initial condition
• tide
• runoff
• surface forcing

2. How Mercator creates regional configuration

1. Hypothesis
   • orca grid to irca grid
   • odd refinement
   • free licence language
2. Limits
   • can't create domain on north pole or a band of latitude
   • don't create files to used TOP or LIM
   • get data from local space
3. Coordinates
   • extraction of the domain from an already existing coordinates file (Mercator Fortran code). Note that we keep boundary on U,V point.
4. Bathymetry
   • extraction of the domain from an already existing bathymetry file (Mercator Fortran code).
   • merged bathymetry at boundary (~1°) with weighted function (Mercator Fortran code)
5. Boundary condition
   • extrapolation of the above system output (Mercator Fortran code)
     • horizontally (first): distance weighted function using nearest 9 points
     • vertically: takes value of the upper point
   • interpolation to refine grid (T,S,U,V,SSH) (Mercator Fortran code)
     • horizontally: bilinear or bicubic
   • extraction at boundaries (Mercator Fortran code)
   • ouput in OBC form
   • before run NEMO, concatenated files over the period (nco)
6. Initial condition
   • from restart file (netcdf or dimg) or from a "standard" output (Mercator fortran code, nco):
     • extrapolation:
       • horizontally (first): distance weighted function using nearest 9 points
       • vertically: takes value of the upper point
     • interpolation to refine grid (T,S,U,V,SSH):
       • horizontally: bilinear or bicubic
7. Tide
   • interpolation and extraction of the domain from an already existing tide file (TPXO) (Mercator Fortran Code)
8. Runoff
   • as surface flux:
     • a global runoff file is created from Dai and Trenberth climatology. surface flux are spread on coastal points. Large rivers are spread over ocean masks.
     • interpolation and extraction of the domain from an already existing runoff file (Mercator Fortran code).
   • as boundary:
     • Large rivers are given as BDY.
9. Surface forcing
   • manage inside NEMO, using interpolation on the fly.

3. How NOC creates regional configuration

1. Boundary condition : BDY tools

The BDY subroutines can be employed to communicate information from out-side the regional model domain into the interior while supporting both outflow and inflow conditions. This set of tools was born out of a requirement to have a generic method by which to provide boundary data for use by these subroutines. The original code for these tools was written in Mathworks Matlab. It was subsequently translated into Python for wider distribution and to facilitate development. The Python port is 90% complete and should be finished at tested by the end of the month. At present the tools have only been tested by transferring data from global ORCA simulations to refined regional domains, although in principle could use non-ORCA input to generate BDY data.

• Works using a NEMO style namelist to initiate BDY configuration.
• Automatic identication of BDY points from a user chosen or predefined mask.
• KDTree nearest neighbour matchup between the identied BDY points and the associated locations on source grid.
• Data are rst interpolated (horizontally) from source grid to destination BDY points using:
  • Bilinear
  • Gauss like - distance weighted function using nearest 9 points with a decorrelation distance r0 proportional to dx*cos(lat(j,i))
  • Nearest - takes closest point on distance (for use with similar res src and dst grids)

• Then in the vertical
  • Linear
  • Cubic Spline
• Output in NEMO v3.2/3.3 and 3.4 forms Time stretching used to accommodate mismatch in source and destination calendars
• Optional smoothing of BDY boundary (post interpolation)
• Should be able to accept non NEMO netcdf src les, but not tested yet
• Handles rotation of vector quantities and can accommodate rotated grids (e.g. pan arctic)
• At present is only coded to use TPXO7.2 inverse tidal model to provide tidal boundary conditions

4. How MetOffice? creates regional configuration

1. Hypothesis
2. Limits
3. Coordinates
4. Bathymetry
5. Boundary condition
6. Initial condition
7. Tide
8. Runoff
9. Surface forcing

5. How INGV creates regional configuration

1. Hypothesis
2. Limits
3. Coordinates
4. Bathymetry
5. Boundary condition
6. Initial condition
7. Tide
8. Runoff
9. Surface forcing

6. Proposals to solve some limits

• to create orca grid all over the globe (north pole, band of latitude. . . ), we could use Gridgen tool which is already in NEMO.
• to create Bathymetry on this new grid we could use the GEBCO dataset with the OPABAT tool (already in NEMO).
• we could used SCRIPP3D to create boundary condition and inital state so :
  • we could change the number of vertical levels
  • we could change z-coordinaltes to s-coordinates
  • we could change grid orca to regular

However, It may not allow to keep U, V point on the boundary.

AM Treguier proposes to add the BMGtools as potential tools. The BMGtools (developped by Ifremer) allow to refine grid, to create bathymetry and to check it. Moreover she proposes to use AGRIF nesting tools, as there is common tasks for both tools. So it will be easiest to maintain codes.

7. What the config manager could do, with which file and tool

8. config manager demonstrator

I propose to build a demonstrator tool. This demonstrator will not be able to do all tasks listed in part III. However i will try to take it into account, in order to make it easy to plug in those tools. The demonstrator will allow to create 1/12° regional configuration, using 1/4° global climatology to initialised and forced the new configuration. Bathymetry and grid will be extract from already existing files. I hope do it before this summer, so you could test it before next fall NEMO meeting, and maybe we could add this demonstrator to the next release of NEMO. Then we could add, step by step, other tools to improve the capabilities of the cong manager.