# BDY segments with NEMO4.2+

**URL:** <https://nemo-ocean.discourse.group/t/bdy-segments-with-nemo4-2/632>\
**Category:** v4.2.x\
**Tags:** BDY\
**Created:** [1 March 2024 23:37 UTC](https://nemo-ocean.discourse.group/t/bdy-segments-with-nemo4-2/632 "2024-03-01T23:37:07Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![dupontf](https://avatars.discourse-cdn.com/v4/letter/d/bb73d2/32.png) [@dupontf](https://nemo-ocean.discourse.group/u/dupontf)\
**Post date:** [1 March 2024 23:37 UTC](https://nemo-ocean.discourse.group/t/bdy-segments-with-nemo4-2/632/1 "2024-03-01T23:37:07Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![lambertn](https://yyz2.discourse-cdn.com/free1/user_avatar/nemo-ocean.discourse.group/lambertn/32/13_2.png) [@lambertn](https://nemo-ocean.discourse.group/u/lambertn)\
**Post date:** [4 March 2024 17:15 UTC](https://nemo-ocean.discourse.group/t/bdy-segments-with-nemo4-2/632/2 "2024-03-04T17:15:39Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![smasson](https://avatars.discourse-cdn.com/v4/letter/s/eb9ed0/32.png) [@smasson](https://nemo-ocean.discourse.group/u/smasson)\
**Post date:** [4 March 2024 17:48 UTC](https://nemo-ocean.discourse.group/t/bdy-segments-with-nemo4-2/632/3 "2024-03-04T17:48:16Z")

</div>

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**

---

<div class="post-metadata">

**Author:** ![dupontf](https://avatars.discourse-cdn.com/v4/letter/d/bb73d2/32.png) [@dupontf](https://nemo-ocean.discourse.group/u/dupontf)\
**Post date:** [4 March 2024 17:51 UTC](https://nemo-ocean.discourse.group/t/bdy-segments-with-nemo4-2/632/4 "2024-03-04T17:51:26Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dupontf](https://avatars.discourse-cdn.com/v4/letter/d/bb73d2/32.png) [@dupontf](https://nemo-ocean.discourse.group/u/dupontf)\
**Post date:** [4 March 2024 17:54 UTC](https://nemo-ocean.discourse.group/t/bdy-segments-with-nemo4-2/632/5 "2024-03-04T17:54:44Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dupontf](https://avatars.discourse-cdn.com/v4/letter/d/bb73d2/32.png) [@dupontf](https://nemo-ocean.discourse.group/u/dupontf)\
**Post date:** [4 March 2024 20:46 UTC](https://nemo-ocean.discourse.group/t/bdy-segments-with-nemo4-2/632/6 "2024-03-04T20:46:42Z")

</div>

…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.

---

<div class="post-metadata">

**Author:** ![smasson](https://avatars.discourse-cdn.com/v4/letter/s/eb9ed0/32.png) [@smasson](https://nemo-ocean.discourse.group/u/smasson)\
**Post date:** [7 March 2024 16:31 UTC](https://nemo-ocean.discourse.group/t/bdy-segments-with-nemo4-2/632/8 "2024-03-07T16:31:38Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![smasson](https://avatars.discourse-cdn.com/v4/letter/s/eb9ed0/32.png) [@smasson](https://nemo-ocean.discourse.group/u/smasson)\
**Post date:** [7 March 2024 16:38 UTC](https://nemo-ocean.discourse.group/t/bdy-segments-with-nemo4-2/632/9 "2024-03-07T16:38:51Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![smasson](https://avatars.discourse-cdn.com/v4/letter/s/eb9ed0/32.png) [@smasson](https://nemo-ocean.discourse.group/u/smasson)\
**Post date:** [21 March 2024 10:17 UTC](https://nemo-ocean.discourse.group/t/bdy-segments-with-nemo4-2/632/10 "2024-03-21T10:17:04Z")

</div>