1536 ib neighborhood radius automatic size checking

[danieljvickers]

Description

Immersed Boundary cases have one extra layer of tediousness due to the IB neighborhood radius needing ot be recomputed based upon the number of ranks. This causes significant problems when attempting to run the same case on CPUs vs. GPUs (because one may use more CPUs for the same case) and in strong scaling scenarios.

To address this, this PR allows users to let MFC automatically compute the IB Neighborhood radius. The code computes the largest width required for any IB in the simulation and the largest processor width. These are used to approximate a size, with an additional 10% safety factor on the neighborhood size for safety.

This is not ideal, as it does not consider things like the orientation of the IB for reducing the size further. If particle forces are desired, it is always recommended to compute the IB neighborhood radius that one desires. However, for uniform distributions of small IBs, this will often produce optimal results with no modification to the case file.

To enable automatic radius checking, just set ib_neighborhood_radius: 0 in the case file, which is also the new default.

Closes #1536

Type of change (delete unused ones)

• New feature

Testing

How did you test your changes?

2D ranks on GNU for increasing IB size.

Checklist

Check these like this [x] to indicate which of the below applies.

• I added or updated tests for new behavior
• I updated documentation if user-facing behavior changed

See the developer guide for full coding standards.

GPU changes (expand if you modified src/simulation/)

• GPU results match CPU results
• Tested on NVIDIA GPU or AMD GPU

AI code reviews

Reviews are not retriggered automatically. To request a review, comment on the PR:

• @claude full review — Claude full review (also triggers on PR open/reopen/ready)
• Or add label claude-full-review — Claude full review via label

[github-actions]

Claude Code Review

Head SHA: 2550966

Files changed:

• 5
• docs/documentation/case.md
• src/simulation/m_global_parameters.fpp
• src/simulation/m_ib_patches.fpp
• src/simulation/m_start_up.fpp
• toolchain/mfc/params/definitions.py

Findings:

• src/simulation/m_start_up.fpp (~line 902/915): s_get_neighbor_bounds() is now called before s_initialize_ib_airfoils(), but the new automatic-radius path inside s_get_neighbor_bounds() calls s_get_ib_bound(patch_ib(k), bound) for every IB (src/simulation/m_ib_patches.fpp ~line 476), and for geometry == 4 .or. geometry == 11 that reads ib_airfoil(patch%airfoil_id)%c. ib_airfoil is only populated by s_initialize_ib_airfoils(), which still runs afterward. When ib_neighborhood_radius defaults to 0 (auto mode) and any patch is an airfoil, max_ib_bound is computed from an uninitialized ib_airfoil array, silently producing a wrong (garbage) ib_neighborhood_radius and thus insufficient MPI neighbor coverage for that case. s_instantiate_STL_models() was correctly hoisted above s_get_neighbor_bounds() for the STL case (geometry 5/12), but the airfoil initializer was not.
• src/simulation/m_ib_patches.fpp line 484: in the new s_get_ib_bound, the geometry == 5 (STL model) branch computes bound from only lx/ly (0.5_wp*sqrt((lx(2)-lx(1))**2 + (ly(2)-ly(1))**2)), omitting the z-extent (lz) of the model's bounding box. The retained geometry == 5 branch in s_get_bounding_indices (and the geometry == 12 branch in s_get_ib_bound itself) both include the z dimension. Since this bound feeds directly into the automatic ib_neighborhood_radius selection in s_get_neighbor_bounds, a 3D STL immersed boundary with significant z-extent will silently produce an undersized max_ib_bound and thus too small a neighborhood radius, causing an IB to be missing on ranks it should reach.
• src/simulation/m_start_up.fpp line 1532: ib_neighborhood_radius = max(1, floor(1.1_wp*max_ib_bound/(0.5_wp*max_rank_width))) divides by max_rank_width, the largest per-rank domain width across all ranks (via s_mpi_allreduce_max). With non-uniform rank domain widths (e.g. stretched grids or uneven decomposition), a rank narrower than max_rank_width needs proportionally more hops to cover the same physical distance max_ib_bound; using the maximum width as the per-hop distance underestimates the required radius for narrower ranks. Using the minimum rank width (worst case) would be the conservative/safe choice for a single global radius applied uniformly to all ranks.

[codecov]

Codecov Report

❌ Patch coverage is 89.36170% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 61.62%. Comparing base (d4ffa29) to head (edc3ade).
⚠️ Report is 2 commits behind head on master.

Files with missing lines	Patch %	Lines
src/simulation/m_start_up.fpp	82.35%	0 Missing and 3 partials ⚠️
src/simulation/m_ib_patches.fpp	93.10%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1736      +/-   ##
==========================================
+ Coverage   61.59%   61.62%   +0.02%     
==========================================
  Files          84       84              
  Lines       21493    21518      +25     
  Branches     3176     3180       +4     
==========================================
+ Hits        13239    13260      +21     
  Misses       6078     6078              
- Partials     2176     2180       +4     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[danieljvickers]

Addressed AI comments. Comments 1 and 3 are valid. Correction 3 is not a concern on its own, but it helped me notice a nearby and more insidious issue with taking a floor that should have really been a ceiling. The airfoil response is sound.

The STL concern is nonsense, as the flags are for two different STL models. We should unify these, but it is still nonsense as written. I have ignored it..