doc: correct INS.jl solver description and exclusion rationale

[agdestein]

Following up on the invitation in agdestein/IncompressibleNavierStokes.jl#197 — thanks for including INS.jl! This first PR only corrects a few statements about the solver; the companion upgrade PR is #103.

Suggested label: benchmark:none — strings and metadata only, no behavior change.

Changes

• INS_JL_NO_OBSTACLE exclusion text. The current text says the cylinder "cannot be represented in INS.jl" and that its "spectral/LU pressure projection is also periodic-only". Neither is accurate:

  • psolver_direct (LU) assembles the pressure Laplacian for any supported BC combination — it is the general-BC fallback that default_psolver selects for non-periodic setups. psolver_transform (DCT) supports Dirichlet BCs, as this repo's own channel code uses. Only psolver_spectral (FFT) is periodic-only.
  • Brinkman volume penalization is a momentum forcing term, and a finite penalization −(χ/η)·u added to the RHS before projection is smooth and stable. What diverges is this tesseract's hard-zero masking after each projection (an infinite-penalization clamp the projection cannot see). INS.jl also natively supports the channel configuration (DirichletBC(f) inflow, PressureBC outflow, periodic lateral BCs).

  The exclusion itself stays (that route isn't implemented in the tesseract); only the attribution is corrected.

• discretization: FD → FV. INS.jl is a staggered finite-volume (energy-conserving) discretization; FV is among the documented options for this field.

• "CPU-only" description. The wrapper runs on CPU, but the library's kernels are KernelAbstractions.jl and run on CUDA (including the spectral pressure solver and the differentiable path). Reworded so readers don't take the cost tables as a solver property; uses_gpu: false is kept as a property of this tesseract.

No results change; the generated solver/results pages pick these up on the next docs build.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Gdif1Cu1pdCJENe2hNUaF1

[PasteurBot]

CLA signatures confirmed

All contributors have signed the Contributor License Agreement.
_{Posted by the CLA Assistant Lite bot.}

[agdestein]

@PasteurBot I have read the CLA Document and I hereby sign the CLA

[dionhaefner]

Thanks @agdestein ! Do you think enabling GPU execution would be valuable here, if only as an example for the community as to how to do so?

[agdestein]

Yes, I think that would be valuable. INS.jl's kernels are written with KernelAbstractions.jl, so the entire path this tesseract exercises already runs on CUDA in the library: the RK time stepper, the FFT pressure solver (CUFFT), and the hand-written adjoint kernels behind the Zygote rrules. The wrapper just never enabled it — it's a backend = CUDABackend() flag in the Setup plus host↔device transfers at the tesseract boundary, and adding CUDA.jl to the container.

I've started a branch for this. Concretely:

• backend selection via CUDA.functional(), falling back to CPU so the same image still works on hosts without a GPU (hopefully useful as the "how to" example);
• arrays moved to the device once per apply/vector_jacobian_product call, results copied back to host — same convention as the JAX-based tesseracts;
• uses_gpu: true, everything else unchanged.

Since #103 already makes the solve genuinely float32 end-to-end (which you want anyway before turning on a GPU backend), I'd suggest landing that first and doing GPU as a follow-up PR on top — that keeps the two benchmark re-runs interpretable (algorithmic fixes vs. hardware change). I'll validate forward + VJP on a local RTX 4090 before opening it.

[PasteurBot]

📊 View the full benchmark results

No benchmarks ran for this PR, so there is no status report.

---

[dionhaefner]

@agdestein That follow-up PR sounds awesome! Merging this in the meantime.