Charles Pelletier 65b7d3829b nemo bdy vor 3 Jahren
..
generate_new_bdy_dta.py 65b7d3829b nemo bdy vor 3 Jahren
generate_new_bdy_dta_onefile.py 65b7d3829b nemo bdy vor 3 Jahren
generate_new_bdy_geom.py 65b7d3829b nemo bdy vor 3 Jahren
nn_interp.py 65b7d3829b nemo bdy vor 3 Jahren
prepare_ecearth_paraso.sh 65b7d3829b nemo bdy vor 3 Jahren
prepare_oras5_paraso.sh 65b7d3829b nemo bdy vor 3 Jahren
readme.md 65b7d3829b nemo bdy vor 3 Jahren

readme.md

Generating lateral NEMO ocean boundary condition.

Scripts for generating lateral ocean boundary condition from EC-Earth ORCA1 outputs.

Steps:

  1. Run python generate_new_bdy_geom.py. All inputs are defined on top of the script with explicit comments.
  2. Run prepare_ecearth_paraso.sh. All inputs are defined on top of the script with explicit comments. Be sure to use the "geometry" file that the script in 1. created.

Then you should be settled, i.e. have boundary geometry and data files. Both scripts defined above are commented.

Step 2. is quite long, because one intermediate step is to remap the EC-Earth data to the full NEMO grid. It's an overkill (in the end, we're only interested in the boundary), but it's not straightforwartd to make a simple (in terms of code readability) implementation which would work without that. For example, on pelican, generating one year of monthly boundary data for PARASO will take about several hours. If you want to have daily data for PARASO (I haven't done that), you'll thus need about more than a day per year, and you'll generate intermediate files (which will be cleant off) of about 150GB. In terms of CPU, the bottleneck is mostly drowning the full 3D fields (cdo setmisstonn in prepare_ecearth_paraso.sh), so if you want to speed things up, start with that.

It may be worth saying that N. Jourdain (IGE, Grenoble) has a more general tool for building configs which is called BUILD_CONFIG_NEMO.