Hello!
I’m trying to create a new configuration based on the AMM12 reference configuration but with a nested child domain in the North Sea. I’ve successfully recompiled AMM12 with the nesting module and used the NESTING tool to create new coordinate, flux, and restart files for the child domain.
I am now attempting to use the DOMAINcfg tool to create a consistent set of domain files for the parent and child, which appears to have worked as I get a “Averaged Bathymetry matches parent” message in 1_ocean.output. However, I get stuck with a “Child Bathymetry is NOT correct near boundaries” error. I’ve tried both creating the child domain using the parent bathymetry and using an external source (GEBCO) and run into the problem either way.
Any ideas on where I could be going wrong here?
Hi David,
I don’t have a solution for this but I just wanted to push this because I have exactly the same problem you described.
I’m working with NEMO 4.2.2 on an embedded zoom using AGRIF on a pre-existing Mediterranean domain. I need to create a subdomain for the child area and I’m using the DOMAINCcfg tool with an external GEBCO bathymetry.
The child domain is correctly generated but I also get “Child Bathymetry is NOT correct near boundaries”. I added some debug and I can confirm that the calculated differences between parent and child scale factors are often greater than the hard-coded tolerance 10^-3. Funnily enough in my case the bathymetry check is actually correct, but the error message is the same for both bathymetry and scale factor checks.
I tried to remove the check by setting ln_chk_bathy = .false. in the child namelist, but I get a seg fault later on, so I reckon the issue cannot be ignored.
I also tried to calculate the child bathymetry from the parent (nn_bathy=3) but the issue persists.
I think I’m missing something here, any suggestions are very welcome!
If it can be of any use to anyone, I fixed the child-parent domain inconsistency when generating a child subdomain and a reworked parent domain with DOMAINcfg.
The problem in my case was that the original domain vertical coordinates and the child domain generated coordinates weren’t identical.
Initially a big issue was that I was using a different bottom of the ocean depth value. Child and parent must have the same identical last gdepw_1d. This can be checked in the original parent domain file or in the ocean.output of the DOMAINcfg. The child namelist parameter is pphmax. It may be also useful to check ppdzmin.
Once that was fixed, I still had some minimal differences in the vertical coordinates between child and parent. To overcome this issue I regenerated the parent vertical coordinates using the following namelist options for the parent:
&namdom ! space and time domain (bathymetry, mesh, timestep)
!-----------------------------------------------------------------------
ln_read_cfg = .false.
nn_bathy = 1 ! = 0 compute analyticaly
! ! = 1 read the bathymetry file
! ! = 2 compute from external bathymetry
! ! = 3 compute from parent (if "key_agrif")
cn_domcfg = 'med_domain.nc'
cn_fcoord = 'med_domain.nc' ! external coordinates file
cn_topo = 'med_domain.nc' ! external topo file
cn_bath = 'bathy_metry' ! topo name in file
cn_lon = 'nav_lon' ! lon name in file
cn_lat = 'nav_lat' ! lat name in file
In my case all the info to regenerate the vertical coordinates were in the parent domain file called med_domain.nc. Before I was using the existing vertical coordinates in the parent domain file with the option ln_read_cfg = .true., but after discovering the remaining (small) inconsistencies I changed to ln_read_cfg = .false and set the various cn_* names to trigger the regeneration.
Hope this helps.
1 Like
Hi, yes, this is something that I haven’t fully investigated yet, but creating nesting meshes must be performed with ln_read_cfg=.false.
for parent (and of course identical vertical parameters for all grids if not using vertical nesting).
Thank you both for the responses.
@jdallaglio I also found small inconsistencies in the vertical coordinates, and changing to ln_read_cfg = .false. fixes that 
1 Like