Inverse_darcy_permeability hardcoded to 0.0 in FSI assembly (fsi.cpp:211/238) — Brinkman drag not applied to porous fluid subdomains in FSI

Description

The Inverse_darcy_permeability (Navier-Stokes-Brinkman drag) term is applied
correctly in a standalone fluid equation, but is overridden with a hardcoded 0.0
inside the coupled FSI equation, so a porous fluid subdomain behaves as free
Navier-Stokes flow under FSI. Per the community forum thread linked below, the zero
appears to have been set intentionally for an unimplemented valve / FSI-contact case,
but the reasoning is undocumented.

No warning or error indicates that the permeability was discarded, so an FSI
simulation with a porous subdomain produces plausible-looking output that is not
solving the intended problem.

Measured

Same porous domain, same K^-1 = 2.747e8 mm^-2, same timestep (step 5), mean
velocity magnitude per domain:

Case	Equation	Lumen	Thrombus	Ratio
A	fluid	4.5298e+01 mm/s	8.4649e-04 mm/s	53513
B	FSI	3.0638e+01 mm/s	2.1966e+01 mm/s	1.39

Thrombus mean velocity is roughly 26000x too high under FSI.

Reproducer

https://github.com/dragos2314/svmp-brinkman-fsi-reproducer

• Control (fluid): fluid_only/solver_fluid.xml
• Bug case (FSI): fsi/solver_fsi.xml

The porous domain block is identical between the two XML files. The difference is
<Add_equation type="fluid"> versus <Add_equation type="FSI">, plus the solid wall
domain and mesh-motion equation the FSI case requires. Both are stripped to a constant
inlet flux, zero-pressure outlet, and 20 timesteps; the README documents the full
comparison and how to read the per-domain velocities.

Original forum thread:
https://simtk.org/plugins/phpBB/viewtopicPhpbb.php?f=188&t=26305&p=0&start=0&view=&sid=13249f51ea63f1610756c4aeaa95f4f2

Questions

1. Can the domain permeability be wired through to the FSI path the way the standalone
   fluid path does it, or are there coupling / ALE considerations that make this
   non-trivial?
2. If the 0.0 needs to be retained for a specific configuration, would gating it on
   that configuration - and warning when a nonzero permeability is set on an FSI fluid
   domain but not applied - be acceptable?
3. For porous-thrombus plus deformable-wall AAA modeling, would you recommend a
   partitioned scheme (FSI for wall motion, then a porous fluid solve on the deformed
   mesh for seepage), or a poroelastic treatment of the thrombus? Has either been done
   in svMultiPhysics?

Environment

• svMultiPhysics commit 042a1552 (git describe: March_2025-81-g042a1552)
• Built in an Apptainer container with the Trilinos/MueLu backend, 2026-06-16
• Linux, Open MPI, 24 ranks
• Both reproducer cases use the fsils linear algebra backend, so no Trilinos build
  is required to run them

Verified against the current source on GitHub - fsi.cpp:211 / fsi.cpp:238 still
pass 0.0.

Reproduction

Steps to reproduce

1. Clone the reproducer repository (contains both meshes and both solver XMLs).
2. Run the control case from inside fluid_only/:
   mpiexec -n 24 svmultiphysics solver_fluid.xml
3. Run the FSI case from inside fsi/:
   mpiexec -n 24 svmultiphysics solver_fsi.xml
4. Compare the per-domain velocity magnitudes at the same timestep:
   python check_velocity.py result_005.vtu in each case's 24-procs/ directory.

Both cases place the same porous domain (ModelRegionID 3, Inverse_darcy_permeability = 2.747e8 mm^-2) in the same flow, driven by the same constant inlet flux with a zero-pressure outlet, over 20 timesteps of 1e-3 s. The domain block is identical
between the two XML files. The difference is <Add_equation type="fluid"> versus <Add_equation type="FSI">, plus the solid wall domain and mesh-motion equation the FSI case requires.

Note that Domain_ID is written only into the first output VTU of a run, and the values written are a power-of-two encoding of the ModelRegionID set in the XML (1 -> 2, 2 -> 4, 3 -> 8). The porous thrombus is Domain_ID 8 in both cases.

The two cases cannot share a mesh, since an FSI equation requires a solid domain that a rigid-wall fluid case does not have. The 3-domain mesh is the 2-domain mesh with a wall layer added; lumen and thrombus geometry and thrombus material properties are unchanged.

Expected behavior

Expected behaviour

The Brinkman drag should be applied to any fluid domain carrying a nonzero Inverse_darcy_permeability, whether that domain is solved by a standalone fluid equation or as the fluid part of a coupled FSI equation. Velocity in the porous domain should fall by orders of magnitude relative to the free lumen in both cases.

Observed: the drop occurs only in the fluid case. Under FSI the porous domain carries velocities comparable to the free lumen, and no warning or error indicates that the permeability was discarded. Silent failure is the main concern here - an FSI simulation with a porous subdomain produces plausible-looking output that is not solving the intended problem.

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct and Contributing Guidelines

Start by inspecting fsi.cpp at lines 211 and 238, then compare the FSI assembly with the standalone fluid path for Inverse_darcy_permeability. Run both cases from the linked reproducer and use check_velocity.py on result_005.vtu to confirm the difference. Done means nonzero permeability is handled consistently in FSI, or the retained exception is gated and a warning is emitted.