Hi all,
I’m planning new nested configurations, building on INALT20 and VIKING20X respectively. Although I might build on those configurations directly, I was wondering whether there might be a way to improve the settings by going to some kind of “complex nest geometries” in certain ways which I describe below. Here I’d mainly like to get a feeling for whether or not it might be worth digging deeper.
NOTE: I am aware of the NEMO development strategy 2023-2027, in particular that complex nest geometries are on the list. Furthermore I read the NEMO-AGRIF user guide which says that overlapping nests “will technically “work”” but “should be avoided”.
-
In the first particular case, the configuration would consist of two neighbouring (or slightly overlapping) siblings with one larger (INALT20 extended eastwards to the southern tip of India) and a second small domain (covering the Arabian and Red seas) with the latter having three boundaries entirely located on land and the fourth boundary directly attached to (or slightly overlapping) with one of the boundaries of the large nest.
The idea here, knowing that both nests only communicate with the parent grid, would be to switch off the sponge layer dynamics for the small nest and make sure its solution is used to update the parent last (which order would be correct for that purpose?).
Am I missing something or could that work and avoid any damping of signals close to the common (slightly overlapping by the sponge layer width) boundary of the two nests? With baroclinic updates at each time step, would that also make sure, the nests receive proper boundary conditions from the host? -
In the second case, I only have one nest (VIKING20X) but want to exclude parts (the Pacific) of the rectangular domain from being refined. Could that be done by e.g. using a mask defining where the parent grid receives an update from the nest and where the update is “ignored”? Additionally, the location of the nest boundaries along which the nest receives its boundary conditions from the parent solution would need to be defined differently - maybe again, using a mask (or through some namelist parameters indicating where the BCs should be applied)?
I did some tests by excluding parts from the nest itself through regionally setting a few variables (top_ and bottom_level, bathy_metry and mbk[uvf]) in 1_domain_cfg.nc zero (plus some updates in domain_cfg.nc to rewind changes due to the updated bathymetry) and let the domain decomposition with suppressing land subdomains eliminate the unwanted part of the rectangular nest. However, with the update, the parent receives zeros in that region.
If case 2 is doable in a way, this would of course also be a solution for 1.
Thank you very much for any thoughts on this.
Franziska