Set pressure PC in Taylor-Hood assembly test

[masaqif]

The Taylor-Hood nested assembly test explicitly selects LU for the velocity sub-KSP but leaves the pressure preconditioner at PETSc's default. This change also selects lu for the pressure sub-KSP, making both sub-solves explicit.

Related to #4359. The reported macOS hang was resolved with PETSc's --download-mumps-avoid-mpi-in-place build option, as confirmed in that issue. This PR is a test-configuration proposal; it does not establish an ILU defect or claim to fix the macOS build issue.

Validation:

• The previously reported Linux-container run at 974f756 passed all four Taylor-Hood cases with three MPI ranks, PETSC_ARCH=linux-gnu-real32-32, and nanobind==2.13.0.
• After rebasing to 717a15f following Adapt to nanobind@2.14.0 #4371, all executed CI checks passed, including real32/OpenMPI and macOS. SonarCloud was skipped.

AI assistance: OpenAI Codex assisted with the code change, testing, and PR text.

[garth-wells]

I don't see an inherent reason why the local ILU would fail. It doesn't in our tests. It would be good to know the root cause before we make a change. If there is an issue, it could lie elsewhere.

[masaqif]

Thanks, agreed that the PR should not claim more root cause than the evidence supports.

The first version used jacobi to avoid the default pressure-sub-KSP PC path, but CI showed that was too weak for the real32 3D cases:

• test_assembly_solve_taylor_hood[mesh2]
• test_assembly_solve_taylor_hood[mesh3]

both returned KSP_DIVERGED_ITS (-3) in linux-gnu-real32-32/openmpi.

I updated the PR to set the pressure split to lu instead. That keeps the test's sub-solves direct, matching the already-explicit velocity split configuration, while still avoiding an implicit PETSc default for the pressure split. This does not assert that local ILU is inherently broken; it only removes the test's dependence on an unspecified default pressure preconditioner.

If the next CI run still fails, I agree the better next step is to dig into the matrix/preconditioner state rather than keep changing solver options.

[masaqif]

Additional CI triage:

The current red checks appear to be blocked before this PR's solver path. The docs job and a local reproduction with the current dependency set both fail during form(...) construction with a Form_* constructor-conversion TypeError. The dependency delta I found is nanobind: the earlier PR run that reached the Taylor-Hood solve installed nanobind==2.13.0, while the current run installs nanobind==2.14.0. There is now a separate high-priority PR for that: #4371.

I also ran a targeted local container reproduction against this PR head (974f756) in ghcr.io/fenics/test-env:current-openmpi with PETSC_ARCH=linux-gnu-real32-32, matching the prior working nanobind version:

mpirun -np 3 python -m pytest -q python/test/unit/fem/test_assembler.py -k test_assembly_solve_taylor_hood

with nanobind==2.13.0 pinned. Result:

4 passed, 248 deselected in 2.97s

So the updated lu pressure split fixes the earlier jacobi regression in the focused 3-rank real32/openmpi case. The remaining red CI looks tied to the nanobind 2.14 compatibility issue rather than this one-line solver change.

[garth-wells]

Are you using macOS? If yes, try using --download-mumps-avoid-mpi-in-place when building PETSc. See

dolfinx/.github/workflows/macos.yml

Line 80 in 2fd387b

--download-mumps-avoid-mpi-in-place \

.

[masaqif]

Thanks for the pointer, and apologies for the delayed reply. The host machine is macOS, but the focused run I reported was inside the Linux image ghcr.io/fenics/test-env:current-openmpi, with PETSC_ARCH=linux-gnu-real32-32 and three MPI ranks. It was not a native macOS PETSc reproduction.

I also checked your resolution of #4359: --download-mumps-avoid-mpi-in-place fixes the reported macOS issue. I have corrected this PR's description to remove the claim that it fixes that hang or demonstrates an inherent ILU problem, and removed the stale statement that the focused test could not be run locally.

The remaining proposal is simply to select lu explicitly for the pressure sub-KSP, as the test already does for the velocity sub-KSP. All executed CI checks on 717a15f passed, including macOS and real32/OpenMPI. This confirms that configuration passes those tests, but does not diagnose the original default-PC failure. Would you still consider the explicit test configuration useful given that the platform issue is resolved?