src/simulation/m_ib_patches.fpp contains the NACA 4-digit airfoil coordinate-table generation block twice, near-verbatim:
s_ib_airfoil (2D): lines 160-216s_ib_3D_airfoil: lines 318-371
Both compute Np1/Np2/Np, @:ALLOCATE(airfoil_grid_u/l), seed endpoints, run the do i = 1, Np1 + Np2 - 1 camber/thickness loop (the yt = (5._wp*ta)*(0.2969_wp*xa**0.5_wp - ...) formula, sin_c/cos_c, upper/lower surface points), set the trailing endpoints, and GPU_UPDATE(device=[airfoil_grid_l, airfoil_grid_u]). The loop bodies (171-207 vs 328-362) are identical. The 2D copy even carries an explicit TODO:
! TODO :: This allocates the upper and lower airfoil arrays, and does not need to be performed each time the IB
! markers are updated. Place this as a separate subroutine.
Why it's friction: the airfoil table math is duplicated; the marker-marking loops below each block (which legitimately differ between 2D and 3D) are the only parts that should remain distinct.
Safe refactor: extract a s_generate_airfoil_grid(patch_id, ...) helper holding the duplicated block and call it from both. Pure extraction, no numerical change.
Golden-file risk: low if extracted verbatim — same arithmetic, same airfoil_grid_u/l population. Airfoil-IB tests should still be run.
Coordination note: related to #1451 ("STL and Airfoil Memory Structs"), which plans to move airfoil/model params off the IB patch type into dedicated data types — a deeper data-layout refactor that will rewrite how airfoil_grid_u/l are stored. This grid-gen extraction is adjacent (it de-duplicates the generation code, not the storage); it should be coordinated with / possibly folded into #1451 to avoid touching the same code twice.
Filed from a repo-wide code-cleanliness review; verified against master @ 40dde5e.
Code references
src/simulation/m_ib_patches.fppcontains the NACA 4-digit airfoil coordinate-table generation block twice, near-verbatim:s_ib_airfoil(2D): lines 160-216s_ib_3D_airfoil: lines 318-371Both compute
Np1/Np2/Np,@:ALLOCATE(airfoil_grid_u/l), seed endpoints, run thedo i = 1, Np1 + Np2 - 1camber/thickness loop (theyt = (5._wp*ta)*(0.2969_wp*xa**0.5_wp - ...)formula,sin_c/cos_c, upper/lower surface points), set the trailing endpoints, andGPU_UPDATE(device=[airfoil_grid_l, airfoil_grid_u]). The loop bodies (171-207 vs 328-362) are identical. The 2D copy even carries an explicit TODO:Why it's friction: the airfoil table math is duplicated; the marker-marking loops below each block (which legitimately differ between 2D and 3D) are the only parts that should remain distinct.
Safe refactor: extract a
s_generate_airfoil_grid(patch_id, ...)helper holding the duplicated block and call it from both. Pure extraction, no numerical change.Golden-file risk: low if extracted verbatim — same arithmetic, same
airfoil_grid_u/lpopulation. Airfoil-IB tests should still be run.Coordination note: related to #1451 ("STL and Airfoil Memory Structs"), which plans to move airfoil/model params off the IB patch type into dedicated data types — a deeper data-layout refactor that will rewrite how
airfoil_grid_u/lare stored. This grid-gen extraction is adjacent (it de-duplicates the generation code, not the storage); it should be coordinated with / possibly folded into #1451 to avoid touching the same code twice.Filed from a repo-wide code-cleanliness review; verified against
master@40dde5e.Code references
src/simulation/m_ib_patches.fpp:160-216— s_ib_airfoil grid-gensrc/simulation/m_ib_patches.fpp:318-371— s_ib_3D_airfoil grid-gen