ALE sponge mask_z halo fixes #1495
Conversation
In the ALE sponge, the `mask_u` and `mask_v` masks are constructed from `mask_z`, but also require valid halo data on their E/W or N/S boundaries. Although a `pass_var` function is called on `mask_z` before computing these masks, this function will not populate the halos of `mask_z` if there is no adjacent data, e.g. a non-reentrant boundary or a land-masked tile. And even though `mask_z` was initialized to zero, this was undone by the internal dellocation/reallocation of the array inside of `horiz_interp_and_extrap_tracer` (although the actual result appears to be compiler dependent). There are two major changes in this patch: * The FMS-based `horiz_interp_and_extrap_tracer` function no longer does a deallocate/reallocate of its output arrays, and now simply assumes they are unallocated. The output arrays are also explicitly declared as intent(out). This change clarifies that only the compute domains of `mask_z` and associated fields are updated, although it doesn't fully resolve the issue described above. * The ALE sponge code now explicitly initializes the halo values of mask_z before interpolating the mask_u and mask_v masks. This ensures that `mask_[uv]` boundary values are disabled on points where no halo data is available (and hence no halo updates from `pass_var`. When the data is available, sensible values will replace these zeros. These changes prevent anomalous values of mask_z from entering the halos, and ensuring that `mask_[uv]` contain sensible values. A similar operation should not be required by the tracer fields, since the zero-halo values in the mask will correctly disable these values when no adjacent field is available for halo updates.
Codecov Report
@@ Coverage Diff @@
## dev/gfdl #1495 +/- ##
=========================================
Coverage 29.02% 29.03%
=========================================
Files 236 236
Lines 71515 71491 -24
=========================================
- Hits 20759 20756 -3
+ Misses 50756 50735 -21
Continue to review full report at Codecov.
|
|
I suppose this works for |
|
It looks like the Even though these values never get used when We may want to first build |
Currently, fields from `horiz_interp_and_extrap_tracer` are interpolated onto [uv] points under the assumption that halos have sensible values. This is generally true due to the preceding `pass_var` call, but it may not be valid if the halo is not updated, e.g. along a boundary or land-masked tile. The mask is designed to be set to zero when this happens, but it could still result in an assignment of an uninitialized value to the fields (`sp_val_[uv])`. Although the value is not used, it can produce compiler warnings and errors under strict debugging builds. This patch moves the calculation of `sp_val_[uv]` so that it is only conditionally computed when the mask is set to 1.
|
This PR has passed pipeline testing at https://gitlab.gfdl.noaa.gov/ogrp/MOM6/-/pipelines/13581. |
In the ALE sponge, the
mask_uandmask_vmasks are constructed frommask_z, but also require valid halo data on their E/W or N/Sboundaries.
Although a
pass_varfunction is called onmask_zbefore computingthese masks, this function will not populate the halos of
mask_zifthere is no adjacent data, e.g. a non-reentrant boundary or a
land-masked tile.
And even though
mask_zwas initialized to zero, this was undone by theinternal dellocation/reallocation of the array inside of
horiz_interp_and_extrap_tracer(although the actual result appears tobe compiler dependent).
There are two major changes in this patch:
The FMS-based
horiz_interp_and_extrap_tracerfunction no longer doesa deallocate/reallocate of its output arrays, and now simply assumes
they are unallocated.
The output arrays are also explicitly declared as intent(out).
This change clarifies that only the compute domains of
mask_zandassociated fields are updated, although it doesn't fully resolve the
issue described above.
The ALE sponge code now explicitly initializes the halo values of
mask_z before interpolating the mask_u and mask_v masks.
This ensures that
mask_[uv]boundary values are disabled onpoints where no halo data is available (and hence no halo updates from
pass_var. When the data is available, sensible values will replacethese zeros.
These changes prevent anomalous values of mask_z from entering the
halos, and ensuring that
mask_[uv]contain sensible values.A similar operation should not be required by the tracer fields, since
the zero-halo values in the mask will correctly disable these values
when no adjacent field is available for halo updates.