Version 20 (modified by jpaul, 11 years ago) (diff) |
---|
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:
- list method used now (>23 Jan)
- list idea to solve some limitations (> 03 Feb)
- 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
- Hypothesis
- orca grid to irca grid
- odd refinement
- free licence language
- 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
- Coordinates
- extraction of the domain from an already existing coordinates file (Mercator Fortran code). Note that we keep boundary on U,V point.
- 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)
- 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)
- extrapolation of the above system output (Mercator Fortran code)
- 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
- extrapolation:
- from restart file (netcdf or dimg) or from a "standard" output (Mercator fortran code, nco):
- Tide
- interpolation and extraction of the domain from an already existing tide file (TPXO) (Mercator Fortran Code)
- 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.
- as surface flux:
- Surface forcing
- manage inside NEMO, using interpolation on the fly.
3. How NOC creates regional configuration
- 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
- Hypothesis Regional models at the Met Oce up to now have been based on a standard latitude/longitude grid, sometimes rotated (ie. north pole of grid not at geographical north pole). Open boundaries are handled using the NEMO BDY module. The code for generating the grid definition and model input files is a mixture of IDL and Fortran. Most model input files are generated by 3D linear interpolation. Horizontal interpolation weights are calculated using the SCRIP code developed at Los Alamos. Met Office Fortran routines are used to calculate the vertical interpolation weights and perform the interpolation in 3D using the horizontal and vertical interpolation weights. The interpolation routine can handle full 3D interpolation required for eg. s-coordinate models. The interpolation routine rotates vector fields where necessary.
- Limits
- Only handles latitude/longitude grids (with possible rotation).
- Does not make use of flexibility of BDY module - only handles regular rectangular boundaries at edge of the domain.
- Coordinates An IDL routine takes the model bathymetry as input (see 4.3) and generates the NEMO coordinates.nc file as well as the grid definition files required by the SCRIP routines. Note that this routine can only handle latitude/longitude grids with possible rotation.
- Bathymetry Bathymetry on the model domain is derived from the GEBCO dataset using a box-averaging algorithm, ie. all data points within a model gridbox are averaged to find the model depth at that point. IDL code. Bathmetry at open boundaries is matched to the bathymetry of the low-resolution model supplying the boundary data. Sometimes hand editing of the bathymetry is performed, eg. to remove nearly-enclosed inlets on the coast. Bathymetry for the North-West Shelf domain is derived from the NOOS 1 nautical mile bathymetry using grid-box averaging.
- Boundary condition + Tide An IDL routine takes the model coordinates.nc le as input and generates the coordinates.bdy.nc file (definition of boundary in BDY module) as well as the grid definition files required by SCRIP. Note that this routine can only handle regular open boundaries around the edge of a rectangular domain, so doesn't make use of the flexibility of the boundary zone definition in BDY. Boundary data is generated using 3D linear interpolation. Tidal harmonic forcing data is interpolated from output from a tidal model.
- Initial condition Regional models are spun up from rest. Initial temperature and salinity fields are either taken from climatology or from a low-resolution FOAM analysis. The temperature and salinity fields are interpolated to the model grid using 3D linear interpolation.
- Runoff Runoff is generated from the GRDC climatological dataset using a set of bespoke scripts and fortran code. For each river the data point nearest to the coast is selected and applied to the nearest coastal point in the model. For large rivers the runoff is spread over a number of ocean points. Runoff is applied as a surface flux.
- Surface forcing
Surface forcing is derived from Met Office atmosphere model fields and interpolated to model points using bilinear interpolation.
5. How INGV creates regional configuration
Most of the steps are done using matlab/f90 codes; We deal only with regional configuration regular configuration, no global. Our procedure is divided into 3 steps: Grid-InitialCondition?-Forcing.
- Grid
- required input files: high resolution bathymetry (usually 1/2km), coast line (100m resolution);
- define the region and the discretization step (lat, lon, delta-lat, delta-lon);
- define kind of vertical discretization, zeta, sigma;
- we usually define a regular horizontal mesh;
- interpolate bathymetry into the model mesh (biliniar interpolation);
- define number of vertical levels and they distribution: we usually make use of zeta coord with partial step. For this case, in order to fix the vertical levels distribution we use ocean observations (CTD, XBT and ARGO). We interpolate the obs data into several vertical grids generated using NEMO algorithm and then back to the original grid (usually 1m resolution); we check for the vertical grid providing smaller interpolation error and able to reproduce the vertical water mass distribution; when sigma coordinates are used we compute hydrostatic consistency factor and smooth (simple laplacian filter) the topography accordingly;
- define minimum depth;
- refine land-sea mask on the base of the coast-line dataset (matlab GUI); The idea is to preserve realistic coast line despite the minimum depth;
- Initial Condition
- required input file: observations, already existing mapped climatology (SeaDataNet?, MedAtlas?), or parent model results;
- In case of sparse observation we do Objective Analysis to map the data into the model grid. in case of already existing mapped data we do a simple linear interpolation;
- after the IC file is created we check for vertical stability and correct if necessary;
- Forcing
- surface forcings; No specific tools are used here, just convert grib into netcdf according NEMO needs;
- Lateral open boundary condition (up to now only OBC, simple test with BDY); up to now only ad-hoc scripts; The only common point are the integral constrains we apply. I.E. Preserve transport before and after the interpolation.
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
- Coordinates
input | function | tool | advantage | inconvenience |
low resolution coordinates | refine ORCA grid | AGRIF_create_coordinates | ||
GRIDGEN | ||||
BMGtools | ||||
high resolution coordinates | extract ORCA grid | Mercator Fortran code | ||
GRIDGEN | ||||
BMGtools | ||||
low resolution bathymetry | create regular grid | MetOffice? IDL tools |
- Bathymetry
input | function | tool | advantage | inconvenience |
bathymetry dateset | create bathymetry on grid | OPABAT | ||
MetOffice? IDL tools | ||||
BMGtools, based on SCRIPP3D | ||||
AGRIF_create_bathy | ||||
low resolution bathymetry | refine bathymetry | BMGtools | ||
AGRIF_create_bathy | ||||
high resolution bathymetry | extract bathymetry | Mercator Fortran code |
- Boundary Condition
input | function | tool | advantage | inconvenience |
low resolution climatolgy or analysis | interpolation to rectangular boundaries | SCRIP and MetOffice? IDL tools | ||
Mercator Fortran code | ||||
interpolation to unstructured boundary | NOC python tools |
- Initial Conndition
input | function | tool | advantage | inconvenience |
low resolution climatolgy or analysis | interpolation of T, S and start from rest | MetOffice? IDL tools | ||
low resolution climatolgy, analysis or restart | split restart and/or interpolation of T, S, U, V, SSH | Mercator Fortran code |
- Runoff
input | function | tool | advantage | inconvenience |
low resolution climatology | as surface flux, on nearest coastal point, large rivers spread over ocean points | MetOffice? Fortran code | ||
as surface flux, spread on coastal points, large rivers spread over ocean masks. | Mercator Fortran code | |||
as surface flux, spread on coastal points, and as BDY large rivers. | Mercator Fortran code |
- Surface Forcing
input | function | tool | advantage | inconvenience |
low resolution climatology or analysis | interpolation on the fly | fldread |
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 config manager.
I should have built a config manager demonstrator for this autumn.
Unfortunately, even if I'm close to do it, there is still some bugs in the code i wrote.
I will not have time to fix these bugs, and to check that everything is ok before the NEMO merge party 2013.
However I will continue to work on it, and next year, I will add a config manager to the NEMO tools.