Hi all, I have a sort of philosophical question regarding the convention for BDY segments in NEMO4.2+.
Reading the documentation (that mostly applies to global configurations) and the code, jpiglo is now calculated from Ni0glo (read from domaincfg file) by adding twice the halo size jpiglo = Ni0glo + 2 * nn_hls, which has led me to believe that Ni0glo is the bare or inner domain valid for both global or regional configurations. In the latter case, without the rim of unused points in regional configurations (in NEMO3.6 output, those points are just zeros anyway) . However, in BDY all index conditions are now done with jpiglo being substituted by the new Ni0glo and BDY is not happy if I put nbdyind=1 (instead of 2 in pre NEMO4.2 versions) as I try to give the position relative to the inner domain without the halos (hardcoded to one in the pre-NEMO4.2 input files if I understand the logic correctly).
A simple solution would be to ignore trying to fit my configuration to the inner domain and just produce a domcfg.nc file with the same dimensions as in prior versions. It would be a waste of halos at the rim of the domain but at least BDY would still happy.
Users might be a little less if you consider an already highly optimized domain for NEMO < 4.2. If your “old” domain used to be jpiglo=1002 long for 20 cpus and halo=1, it would give you jpi=52 exactly on all cpus. The “inner” domain Ni0glo would be 1000 long, jpiglo=1002 and jpi would still be again 52. However, if I follow the BDY logic, I would have to declare a domcfg of 1002 long, which internally means 1004, and jpi would be a mix of 52 and 53 instead to match the increased size of the domain, i.e., less optimum.
Am I wrong? cc @jchanut @lambertn
1 Like
So just that I understand your domain pre and post NEMO 4.2. Before 4.2 you had a domain with jpiglo=1002 and the first and last columns being just zeros. The west boundary was set with nbdyind=2 and the east boundary with nbdyind=1001.
Now, with 4.2, you had a domain with jpiglo=1000 because you remove the first and last columns and nbdyind=1 does not work. Am I understanding your problem correctly?
In the 4.2 (an later) all “closed boundaries” are part if the “inner domain” defined in the domcfg file.
When I say « closed boundaries », this is from an MPI point of view, i.e. processes located at the border of the domain that have no neighbor toward the outside of the domain. This means neither I or J periodicity nor North pole folding.
If you switch “on” BDY, your boundary are not closed from the ocean dynamics point of view, but from the code point of view, you still have closed boundaries (“land points” with a 0 value on the sides) + a flow applied on prescribed points.
→ from 4.2, the land points on each side must be part on the inner domain. The halos are added in addition of these land points.
→ with “closed boundaries”, we have
Ni0glo_v4.2 = jpiglo_v4.0
jpiglo_v4.2 (+nn_hls = 1) = jpiglo_v4.0 + 2
jpiglo_v4.2 (+nn_hls = 2) = jpiglo_v4.0 + 4
=> with closed domain, you must use the same input file before and after v4.2
yes, correct for the western OBC! To be exact, for the eastern OBC, nbdyind would have been 1000 in pre 4.2 world, but same idea, 999 will stop the model in 4.2.x where I try to declare in domcfg,nc only the inner domain from 1 to 1000.
Merci Seb! That was what I suspected. So, no way to avoid the addition of more halo points on the MPI tiles along the outer rim of the domain.
…although, to my mind, this could be considered a defect. I am thinking of how open boundaries are treated in CICE, which also has a concept of no-halo policy when declaring the input grid, the rule is simple: if is the row of points along the rim of the declared domain are all land, it is a closed boundary, otherwise, it is a cyclic or open boundary (and then it depends on some other namelist parameters). I am pretty sure I can get BDY to work as well on this assumption.
1 Like
yes from >= 4.2, the input files concerns only the inner domain. The total domain (inner + MPI halos) is used only internally by NEMO and should not be considered by the users. It depends of the size of nn_hls which is defined in the namelist and will therefore be defined on-line and not from the input file as it was the case in versions <= 4.0 (because nn_hls was always equal to 1).
no, believe me, we tried to remove the band of “land” points located along the points where we apply the open boundary condition and it is not working with NEMO as it is written. For example, you need some grid informations (such as the horizontal scale factors) on the points next to the OBC points. As the grid geometry can have any shape, you need to provide these scale factors in the input file.
1 Like