Other NEMO packages
Some useful tools that come with NEMO are available in the analog of the
TOOLS folder. These are built using the ARCH files as you would for
building an experiment with e.g.
./maketools -n REBUILD_NEMO -m HKUST_HPC2
Notes on the ones I have used may be found here.
REBUILD_NEMO
XIOS can combine the output-per-CPU cells into one global file, but by default the restart files and mesh_mask.nc files are output per CPU, so it is useful to recombine them. This can be done through the REBUILD_NEMO package.
Build as usual, and the resulting output should be a rebuild_nemo.exe in the folder, to be driven by the script rebuild_nemo. The way to use it is to call the script as, for example,
$BASE_DIR/tools/REBUILD_NEMO/rebuild_nemo ${MODEL}_${RES_TIMESTAMP}_restart $NUM_CPU
where $BASE_DIR is wherever the folder lives, the things to be combined look like ${MODEL}_${RES_TMESTAMP}_restart_0000.nc (e.g. mesh_mask_00??.nc, UNAGI_00051840_restart[_ice].nc, etc.), and $NUM_CPU are the number of files to combine (e.g. if we use 96 cores then we get mesh_mask_0000.nc to mesh_mask_0095.nc, and we should do export NUM_CPU=96).
Note
In NEMO 4.0 versions an error may come up with undefined reference to iarg_ and getarg_. This seems to arise from src/rebuild_nemo.f90 where both iarg and getarg are defined as extrinsic. With gfortran this seems to be fixed by simply changing the attribute to intrinsic.
SECTIONS_DIADCT
This is for diagnosing transport (volume, heat and/or salt) over some pre-defined sections, particularly if the section is not aligned with the grid facets (so that the diagnosed uoce or voce are oblique to the grid facets).
Build as usual and a sections_diadct.exe will be generated, which is subsequently called by run/job.ksh. The syntax in job.ksh should be reasonably self-explanatory, and the sections are already defined for the ORCA configuration. The thing that is needed is a path to a coordinate.nc file for the relevant configuration; this can be substituted by a mesh_mask.nc and probably even a domain_cfg.nc (latter not tried). Running the job.ksh will then generate a binary file section_ijglobal.diadct with a model tag, which is read by the NEMO binary to do the diagnoses.
For using it, do the following things:
Copy and/or link resulting binary into the run folder, but it must be called
section_ijglobal.diadct(because NEMOdiadctis build with that naming)In the later versions (NEMO v4.0 onwards probably), simply set
ln_diadct = .true.innamelist_cfg(seenamelist_ref); in the earlier versions,key_diadctneeds to be added to the NEMO modelcppfileChange the time-step to calculate and write (I usually set them to be the same; I assume if writing less often than calculating, then the written out values are appropriate time-averaged over the times where the calculations are done). Don’t have the values too low, because as written it is the CPU responsible for outputting to screen that handles this.
During run-time, text files called
[volume,salt,heat]_transportare generated with a time-stamp. Read and use these as appropriate.
Note
I have found that if the [volume,salt,heat]_transport files are still present before the start of the next run, NEMO would crash. My usual post-processing workflow usually moves this out, but the annoyance is when the run crashed for other reasons and these files are still lurking around then the run would not proceed…
Note
In the officially distributed version of NEMO v4.2.2 the diadct.F90 it comes shipped with doesn’t really work if key_xios is on (which is almost all the time). Proceeding as before will probably lead to an XIOS failure where mfo is not defined (it doesn’t seem to be in the shipped field_def_nemo-oce.xml). This is a not quite finished attempt of getting XIOS to take over the calculations for the sections. The simple way to fix it is to get rid of the appropriate lines of code, using either NEMO v4.0 or v5.0.
WEIGHTS
DOMAINcfg
This package generates the domain_cfg.nc file that encodes the grid locations and spacings, and is recommended for creating new configurations, mostly because the vertical grid spacings with partial steps correction are a bit weird to try and do manually. From the readme file in there, you seem to need to use xios1 to compile this; see the here for various things to watch out for.
When compiled the executable is called make_domain_cfg.exe, and it expects to read a bathy_meter.nc (links are ok) and a namelist_cfg file. The namelist_cfg file should contain the various settings for horizontal and vertical grid spacing, which should be consistent with the content in bathy_meter.nc. An example namelist_cfg is the following:
!-----------------------------------------------------------------------
&namcfg ! parameters of the configuration
!-----------------------------------------------------------------------
!
ln_e3_dep = .true. ! =T : e3=dk[depth] in discret sens.
! ! ===>>> will become the only possibility in v4.0
! ! =F : e3 analytical derivative of depth function
! ! only there for backward compatibility test with v3.6
! !
cp_cfg = "UNAGI" ! name of the configuration
jp_cfg = 100 ! resolution of the configuration
jpidta = 90 ! 1st lateral dimension ( >= jpi )
jpjdta = 26 ! 2nd " " ( >= jpj )
jpkdta = 31 ! number of levels ( >= jpk )
jpiglo = 90 ! 1st dimension of global domain --> i =jpidta
jpjglo = 26 ! 2nd - - --> j =jpjdta
jpizoom = 1 ! left bottom (i,j) indices of the zoom
jpjzoom = 1 ! in data domain indices
jperio = 1 ! lateral cond. type (between 0 and 6) [1 is EW periodicity]
/
!-----------------------------------------------------------------------
&namzgr ! vertical coordinate
!-----------------------------------------------------------------------
ln_zps = .true. ! z-coordinate - partial steps
ln_linssh = .true. ! linear free surface
/
!-----------------------------------------------------------------------
&namdom !
!-----------------------------------------------------------------------
jphgr_msh = 3 ! type of horizontal mesh
ppglam0 = 0.0 ! longitude of first raw and column T-point (jphgr_msh = 1)
ppgphi0 = -50.0 ! latitude of first raw and column T-point (jphgr_msh = 1)
ppe1_deg = 999999.0 ! zonal grid-spacing (degrees)
ppe2_deg = 999999.0 ! meridional grid-spacing (degrees)
ppe1_m = 100000.0 ! zonal grid-spacing (metres)
ppe2_m = 100000.0 ! meridional grid-spacing (metres)
ppsur = 999999.0 ! ORCA r4, r2 and r05 coefficients
ppa0 = 999999.0 ! (default coefficients)
ppa1 = 999999.0 !
ppkth = 18.0 !
ppacr = 10.0 !
ppdzmin = 10.0 ! Minimum vertical spacing
pphmax = 3000.0 ! Maximum depth
ldbletanh = .FALSE. ! Use/do not use double tanf function for vertical coordinates
ppa2 = 999999.0 ! Double tanh function parameters
ppkth2 = 999999.0 !
ppacr2 = 999999.0 !
/
Here, the configuration is called UNAGI. The jp[ijk]data is the number of grid cells in \((x,y,z)\), and I chose jp[ij]glo to be consistent with the choice of horizontal sizes. The jperio denotes the periodicities (see src/domcfg.f90 for the choices). The present model uses a Cartesian grid on a \(\beta\)-plane corresponding to jphgr_msh = 3 (see src/domhgr.f90 for choices), and is centred at longitude 0 and latitude 50 S (see ppglam0 and ppgphi0). The grid spacing here is 100 km, corresponding to ppe[12]_m; the values of 999999.0 are options that are not used.
For the vertical grid, ln_zps switches on the partial step correction and takes into account bathy_meter.nc. The vertical spacing is governed through the parameters ppkth, ppacr, ppdzmin and pphmax ([MI96]; unless you use the double tanh option).
Note
Note NEMO 4.2 seems to be using different namings and convention (see here). As of writing DOMAINcfg still reads the jperio option but separately defines the l_[IJ]perio and ldNFold logical flags for NEMO to read.