New URL for NEMO forge!   http://forge.nemo-ocean.eu

Since March 2022 along with NEMO 4.2 release, the code development moved to a self-hosted GitLab.
This present forge is now archived and remained online for history.
WorkingGroups/ConfigurationManager (diff) – NEMO

Changes between Version 24 and Version 25 of WorkingGroups/ConfigurationManager


Ignore:
Timestamp:
2014-02-13T11:42:52+01:00 (10 years ago)
Author:
jpaul
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WorkingGroups/ConfigurationManager

    v24 v25  
    99 * Dave Storkey (Met Office) 
    1010 * Paolo Oddo (INGV) 
     11 * James Harle (NOC) 
     12 * Sebastien Masson (CNRS) 
     13 * Jean-Marc Molines (LEGI) 
    1114 
    1215 
     
    2124 
    2225 
    23 The goals of this discussion is to define what will do or not the config manager in the next release of NEMO. 
    24  
    25 The first step is to define: 
    26  
    27  * what do we need to create regional configuration 
    28  * how each team do it now 
    29    * methods 
    30    * language 
    31    * limits of these methods 
    32  
    33 == '''Schedule:''' == 
    34  1. list method used now (>23 Jan) 
    35  1. list idea to solve some limitations (> 03 Feb) 
    36  1. Define what will do or not the config manager in the next release of NEMO (> 20 Feb) 
    37  
    38 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. 
    39  
    40  
    41  
    42 == 1. What do we need to create regional configuration == 
    43   
    44  * coordinates == 
    45  
    46  * bathymetry 
    47  * boundary condition 
    48  * initial condition 
    49  * tide 
    50  * runoff 
    51  * surface forcing 
    52  
    53 ==  2. How Mercator creates regional configuration  == 
    54  1. Hypothesis 
    55    * orca grid to irca grid 
    56    * odd refinement 
    57    * free licence language 
    58  1. Limits 
    59    * can't create domain on north pole or a band of latitude 
    60    * don't create files to used TOP or LIM 
    61    * get data from local space 
    62  1. Coordinates 
    63    * extraction of the domain from an already existing coordinates file (Mercator Fortran code). Note that we keep boundary on U,V point. 
    64  1. Bathymetry 
    65    * extraction of the domain from an already existing bathymetry file (Mercator Fortran code). 
    66    * merged bathymetry at boundary (~1°) with weighted function (Mercator Fortran code) 
    67  1. Boundary condition 
    68    * extrapolation of the above system output (Mercator Fortran code) 
    69      * horizontally (first): distance weighted function using nearest 9 points 
    70      * vertically: takes value of the upper point 
    71    * interpolation to refine grid (T,S,U,V,SSH) (Mercator Fortran code) 
    72      * horizontally: bilinear or bicubic 
    73    * extraction at boundaries (Mercator Fortran code) 
    74    * ouput in OBC form 
    75    * before run NEMO, concatenated files over the period (nco) 
    76  1. Initial condition 
    77    * from restart file (netcdf or dimg) or from a "standard" output (Mercator fortran code, nco): 
    78      * extrapolation: 
    79        * horizontally (first): distance weighted function using nearest 9 points 
    80        * vertically: takes value of the upper point 
    81      * interpolation to refine grid (T,S,U,V,SSH): 
    82        * horizontally: bilinear or bicubic 
    83  1. Tide 
    84    * interpolation and extraction of the domain from an already existing tide file (TPXO) (Mercator Fortran Code) 
    85  1. Runoff 
    86    * as surface flux: 
    87      * 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. 
    88      * interpolation and extraction of the domain from an already existing runoff file (Mercator Fortran code). 
    89    * as boundary: 
    90      * Large rivers are given as BDY. 
    91  1. Surface forcing 
    92    * manage inside NEMO, using interpolation on the fly. 
    93  
    94 == 3. How NOC creates regional configuration == 
    95  1. Boundary condition : BDY tools 
    96  
    97 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. 
    98  
    99  * Works using a NEMO style namelist to initiate BDY configuration. 
    100  * Automatic identication of BDY points from a user chosen or predefined mask. 
    101  * KDTree nearest neighbour matchup between the identied BDY points and the associated locations on source grid. 
    102  * Data are rst interpolated (horizontally) from source grid to destination BDY points using: 
    103    * Bilinear 
    104    * Gauss like - distance weighted function using nearest 9 points with a decorrelation distance r0 proportional to dx*cos(lat(j,i)) 
    105    * Nearest - takes closest point on distance (for use with similar res src and dst grids) 
    106  * Then in the vertical 
    107    * Linear 
    108    * Cubic Spline 
    109  * Output in NEMO v3.2/3.3 and 3.4 forms Time stretching used to accommodate mismatch in source and destination calendars 
    110  * Optional smoothing of BDY boundary (post interpolation) 
    111  * Should be able to accept non NEMO netcdf src les, but not tested yet 
    112  * Handles rotation of vector quantities and can accommodate rotated grids (e.g. pan arctic) 
    113  * At present is only coded to use TPXO7.2 inverse tidal model to provide tidal boundary conditions 
    114  
    115 == 4. How MetOffice creates regional configuration == 
    116  1. 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. 
    117  1. Limits 
    118    * Only handles latitude/longitude grids (with possible rotation). 
    119    * Does not make use of flexibility of BDY module - only handles regular rectangular boundaries at edge of the domain. 
    120  1. 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. 
    121  1. 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. 
    122  1. 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. 
    123  1. 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. 
    124  1. 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. 
    125  1. Surface forcing 
    126  
    127 Surface forcing is derived from Met Office atmosphere model fields and interpolated to model points using bilinear interpolation. 
    128  
    129 == 5. How INGV creates regional configuration == 
    130 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-[wiki:InitialCondition]-Forcing. 
    131  
    132  1. Grid 
    133    1. required input files: high resolution bathymetry (usually 1/2km), coast line (100m resolution); 
    134    1. define the region and the discretization step (lat, lon, delta-lat, delta-lon); 
    135    1. define kind of vertical discretization, zeta, sigma; 
    136    1. we usually define a regular horizontal mesh; 
    137    1. interpolate bathymetry into the model mesh (biliniar interpolation); 
    138    1. 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; 
    139    1. define minimum depth; 
    140    1. 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; 
    141  1. Initial Condition 
    142    1. required input file: observations, already existing mapped climatology (SeaDataNet, MedAtlas), or parent model results; 
    143    1. 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; 
    144    1. after the IC file is created we check for vertical stability and correct if necessary; 
    145  1. Forcing 
    146    1. surface forcings; No specific tools are used here, just convert grib into netcdf according NEMO needs; 
    147    1. 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. 
    148  
    149 == 6. Proposals to solve some limits == 
    150  * to create orca grid all over the globe (north pole, band of latitude. . . ), we could use Gridgen tool which is already in NEMO. 
    151  * to create Bathymetry on this new grid we could use the GEBCO dataset with the OPABAT tool (already in NEMO). 
    152  * we could used SCRIPP3D to create boundary condition and inital state so : 
    153    * we could change the number of vertical levels 
    154    * we could change z-coordinaltes to s-coordinates 
    155    * we could change grid orca to regular However, It may not allow to keep U, V point on the boundary. 
    156  
    157 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. 
    158  
    159 == 7. What the config manager could do, with which file and tool '== 
    160  1. Coordinates 
    161  
    162 || input || function || tool || advantage || inconvenience || 
    163 || '''low resolution coordinates''' || refine ORCA grid || AGRIF_create_coordinates || || || 
    164 || || || GRIDGEN || || || 
    165 || || || BMGtools || || || 
    166 || '''high resolution coordinates''' || extract ORCA grid || Mercator Fortran code || || || 
    167 || || || GRIDGEN || || || 
    168 || || || BMGtools || || || 
    169 || '''low resolution bathymetry''' || create regular grid || MetOffice IDL tools || || || 
    170  
    171  2. Bathymetry 
    172  
    173 || input || function || tool || advantage || inconvenience || 
    174 || '''bathymetry dateset''' || create bathymetry on grid || OPABAT || || || 
    175 || || || MetOffice IDL tools || || || 
    176 || || || BMGtools, based on SCRIPP3D || || || 
    177 || || || AGRIF_create_bathy || || || 
    178 || '''low resolution bathymetry''' || refine bathymetry || BMGtools || || || 
    179 || || || AGRIF_create_bathy || || || 
    180 || '''high resolution bathymetry''' || extract bathymetry || Mercator Fortran code || || || 
    181  
    182  3. Boundary Condition 
    183  
    184 || input || function || tool || advantage || inconvenience || 
    185 || '''low resolution climatolgy or analysis''' || interpolation to rectangular boundaries || SCRIP and MetOffice IDL tools || || || 
    186 || || || Mercator Fortran code || || || 
    187 || || interpolation to unstructured boundary || NOC python tools || || || 
    188  
    189  4. Initial Conndition 
    190  
    191 || input || function || tool || advantage || inconvenience || 
    192 || '''low resolution climatolgy or analysis''' || interpolation of T, S and start from rest || MetOffice IDL tools || || || 
    193 || '''low resolution climatolgy, analysis or restart''' || split restart and/or interpolation of T, S, U, V, SSH || Mercator Fortran code || || || 
    194  
    195  5. Runoff 
    196  
    197 || input || function || tool || advantage || inconvenience || 
    198 || '''low resolution climatology''' || as surface flux, on nearest coastal point, large rivers spread over ocean points || MetOffice Fortran code || || || 
    199 || || as surface flux, spread on coastal points, large rivers spread over ocean masks. || Mercator Fortran code || || || 
    200 || || as surface flux, spread on coastal points, and as BDY large rivers. || Mercator Fortran code || || || 
    201  
    202  6. Surface Forcing 
    203  
    204 || input || function || tool || advantage || inconvenience || 
    205 || '''low resolution climatology or analysis''' || interpolation on the fly || fldread || || || 
    206  
    207 == 8. config manager demonstrator == 
    208 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. 
    209  
    210 I should have built a config manager demonstrator for this autumn. [[BR]]Unfortunately, even if I'm close to do it, there is still some bugs in  the code i wrote. [[BR]]I will not have time to fix these bugs, and to check that everything is  ok before the NEMO merge party 2013. [[BR]]However I will continue to work on it, and next year, I will add a  config manager to the NEMO tools. ''' '''