MAC velocity not getting filled correctly at the low boundary

[mukul1992]

Bug description

I am using u_mac (MAC velocity in x-direction) as an example. The index i=0 lies at the boundary for u_mac, but does not get filled by fillpatch_sibling_fields called from preadvect in icns_advection.H.

Steps to reproduce

Steps to reproduce the behavior:

1. Compiler used
   • [x] GCC
   • [ ] LLVM
   • [ ] oneapi (Intel)
   • [ ] nvcc (NVIDIA)
   • [ ] rocm (AMD)
   • [ ] with MPI
   • [ ] other:
2. Operating system
   • [ ] Linux
   • [x] OSX
   • [ ] Windows
   • [ ] other (do tell ;)):
3. Hardware:
   • [x] CPU
   • [ ] GPU
4. Machine details: Apple M3 laptop
5. Input file: rankine.inp

I am commenting out my originally reported test and have added a new test in the next comment below.

AMR-Wind information

==============================================================================
                AMR-Wind (https://github.com/exawind/amr-wind)

  AMR-Wind version :: d6d42205
  AMR-Wind Git SHA :: d6d422058c48cf378117e1ab61c3c5d499ac5a2a
  AMReX version    :: 24.05-20-g5d02c6480a0d

  Exec. time       :: Fri May 24 12:09:29 2024
  Build time       :: May 24 2024 09:19:32
  C++ compiler     :: GNU 13.2.0

  MPI              :: ON    (Num. ranks = 1)
  GPU              :: OFF
  OpenMP           :: OFF

  No additional third-party libraries enabled

           This software is released under the BSD 3-clause license.
 See https://github.com/Exawind/amr-wind/blob/development/LICENSE for details.
------------------------------------------------------------------------------

Additional context

Apart from the fact that technically i=0 lies at the boundary and hence should be filled, the main issue arises for me while implementing the inflow-outflow BC which can have cells with Dirichlet treatment on both the low and high boundaries. The MAC velocity at the high boundary (e.g. u_mac at the xhi boundary) does get filled in the above function and this creates an unexpected asymmetry. For example, if there are 16 cells in the x-direction, i=0 and i=16 would lie on the low and high boundaries respectively. i=0 does not get filled, but i=16 does get filled, hence breaking the symmetry.

Also, I think this issue would only surface for a time-varying boundary condition.

My guess is that the nodal nature of MAC-velocities (in the respective directions) is not accounted for in the backend fillpatch routines and hence the index i=0 is not filled as it lies inside the domain for a cell-centered variable.