Address review: infinity norm, drop dead tolerance term, trim comments

- test_matrix_assembly_rectangular compares element-wise now, with
  PETSc.NormType.INFINITY on both the difference and the norm the
  tolerance scales with, and SAME_NONZERO_PATTERN in the axpy: the nest
  submatrix and the monolithic matrix are assembled from the same form,
  so a differing pattern would itself be a failure worth seeing.

- The 'max(1.0e-10, 1.0e6 * eps**2)' in the interpolation tests is gone.
  The reviewer is right that it does no work: the term wins only in
  single precision, where it gives 1.4e-8, but the worst residual
  measured there is 9.75e-12, already inside the plain 1e-10. The
  original constants are restored unchanged -- the parametrisation over
  the scalar type is what those tests gained, not a new tolerance. 174
  pass.

- The vtkhdf comment is replaced by a reference to issue #4415, which
  records the degree-3 round-trip discrepancy properly.

- Comments trimmed throughout, per AGENTS.md: an explanation that runs to
  five lines beside a one-line assertion is noise, and the reasoning
  belongs in the pull request or an issue.

mypy still passes on all three targets, verified in a container matching
the CI leg.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: garth-wells

.github/workflows/ci.yml

@@ -214,16 +214,10 @@ jobs:
           spack env activate ci
           python -c "import dolfinx; assert dolfinx.has_petsc is ${{ matrix.petsc && 'True' || 'False' }}, dolfinx.has_petsc"
 
-      # mypy runs in ccpp.yml only in a build without PETSc, where it
-      # excludes 'fem/petsc.py' and 'io/utils.py' because they need
-      # petsc4py. Those modules are therefore type-checked nowhere. This
-      # leg has petsc4py, gmsh and pyvista installed, so it checks them.
-      #
-      # The two disabled codes are the accepted limitation recorded in
-      # AGENTS.md: petsc4py ships no stubs, so every signature touching it
-      # degrades to 'Any'.
-      #
-      # One leg only: the result does not vary with the scalar type.
+      # ccpp.yml runs mypy only in a build without PETSc, which excludes
+      # the modules needing petsc4py. This leg has petsc4py, gmsh and
+      # pyvista, so it checks them, on the project config alone. One leg
+      # only: the result does not vary with the scalar type.
       - name: mypy checks (with petsc4py)
         if: ${{ matrix.petsc && matrix.mpi == 'openmpi' && matrix.scalar == 'float64' && matrix.index == 'int32' }}
         shell: spack-bash {0}

.github/workflows/spack-config/gh-actions-env-test.yml

@@ -13,28 +13,13 @@ spack:
     all:
       require:
       - target=x86_64_v3
-    # Use the reference BLAS/LAPACK rather than OpenBLAS.
-    #
     # OpenBLAS 0.3.34 built by the container's gcc 15.2 faults in its Zen
-    # kernels: on an AMD EPYC 9V74 runner the dispatcher selects
-    # 'Core: Zen' and the first large dgemm of high-degree hexahedral
-    # H(curl) element creation jumps to address zero. The same binary
-    # selects 'Core: Haswell' on an Intel host and is fine, and valgrind
-    # reports no memory error, so the fault is a miscompilation of those
-    # kernels rather than a bug in the caller. netlib-lapack is the
-    # implementation the crash was bisected against: LD_PRELOADing it on
-    # the affected runner builds the element that OpenBLAS dies on.
-    #
-    # It is also the only provider that survives this toolchain. Building
-    # OpenBLAS with gcc 13 is not an option -- the concretizer resolves
-    # one compiler for most of the DAG, and mixing gcc 13 with cached
-    # gcc 15 C++ libraries fails to link ('undefined reference to
-    # __cxa_call_terminate' from llvm) -- and BLIS/libflame does not
-    # build either, as libflame 5.2.0's f2c output is rejected by gcc
-    # 15's C23 default ('too many arguments to function').
-    #
-    # The cost is speed: this is unblocked reference code with no tuned
-    # kernels. Revisit when OpenBLAS is fixed for gcc 15.
+    # kernels: high-degree hexahedral H(curl) element creation jumps to
+    # address zero on an AMD EPYC runner, while the same binary picks
+    # 'Core: Haswell' on Intel and is fine. netlib-lapack is the
+    # implementation the crash was bisected against. Revisit when
+    # OpenBLAS is fixed for gcc 15; see PR #4414 for the alternatives
+    # that do not build under this toolchain.
     blas:
       require:
       - netlib-lapack