Mpi f08

.github/workflows/merge-validation.yml

@@ -465,6 +465,11 @@ jobs:
             python tools/print_pytest_failures.py "$report"
           done
 
+  openmpi-integration:
+    name: Open MPI Integration
+    needs: [unit-tests]
+    uses: ./.github/workflows/openmpi-integration.yml
+
   real-libraries-portability:
     name: Real Libraries Portability
     needs: [unit-tests, unit-tests-macos]
@@ -621,6 +626,7 @@ jobs:
       - compiler-smoke-macos
       - unit-tests
       - unit-tests-macos
+      - openmpi-integration
       - real-libraries-portability
       - documentation-benchmark
       - documentation-build
@@ -632,6 +638,7 @@ jobs:
       COMPILER_SMOKE_MACOS_RESULT: ${{ needs.compiler-smoke-macos.result }}
       UNIT_TESTS_RESULT: ${{ needs.unit-tests.result }}
       UNIT_TESTS_MACOS_RESULT: ${{ needs.unit-tests-macos.result }}
+      OPENMPI_INTEGRATION_RESULT: ${{ needs.openmpi-integration.result }}
       REAL_LIBRARIES_PORTABILITY_RESULT: ${{ needs.real-libraries-portability.result }}
       DOCUMENTATION_BENCHMARK_RESULT: ${{ needs.documentation-benchmark.result }}
       DOCUMENTATION_BUILD_RESULT: ${{ needs.documentation-build.result }}
@@ -647,6 +654,7 @@ jobs:
             "compiler-smoke-macos=$COMPILER_SMOKE_MACOS_RESULT" \
             "unit-tests=$UNIT_TESTS_RESULT" \
             "unit-tests-macos=$UNIT_TESTS_MACOS_RESULT" \
+            "openmpi-integration=$OPENMPI_INTEGRATION_RESULT" \
             "real-libraries-portability=$REAL_LIBRARIES_PORTABILITY_RESULT" \
             "documentation-benchmark=$DOCUMENTATION_BENCHMARK_RESULT" \
             "documentation-build=$DOCUMENTATION_BUILD_RESULT"

.github/workflows/openmpi-integration.yml

@@ -0,0 +1,93 @@
+name: Open MPI Integration
+
+on:
+  workflow_call:
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+concurrency:
+  group: openmpi-integration-${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  openmpi:
+    name: Open MPI mpi_f08 · ${{ matrix.version }} · Ubuntu 24.04
+    runs-on: ubuntu-24.04
+    timeout-minutes: 90
+    strategy:
+      fail-fast: false
+      matrix:
+        include:
+          # One release per module layout: 4.1 declares the handle types in
+          # mpi_f08_types, 5.0 re-exports them from a configured mpi_types.
+          - version: "4.1.8"
+            series: "v4.1"
+          - version: "5.0.11"
+            series: "v5.0"
+    env:
+      OPENMPI_VERSION: ${{ matrix.version }}
+      OPENMPI_SERIES: ${{ matrix.series }}
+      PRIK_GFORTRAN_BINARY: gfortran-13
+      PRIK_GFORTRAN_PACKAGE: gfortran-13
+      PYTHONPATH: .
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+      - name: Set up Python 3.12
+        uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+      - name: Install test dependencies
+        run: |
+          python -m pip install --upgrade pip
+          python -m pip install -e ".[qa]"
+      - name: Install pinned GFortran
+        shell: bash
+        run: |
+          if ! command -v "$PRIK_GFORTRAN_BINARY" >/dev/null 2>&1; then
+            sudo apt-get update
+            sudo apt-get install --yes "$PRIK_GFORTRAN_PACKAGE"
+          fi
+          compiler_dir="$RUNNER_TEMP/prik-gfortran"
+          mkdir -p "$compiler_dir"
+          ln -sf "$(command -v "$PRIK_GFORTRAN_BINARY")" "$compiler_dir/gfortran"
+          echo "$compiler_dir" >> "$GITHUB_PATH"
+          "$compiler_dir/gfortran" --version
+      - name: Restore the Open MPI source, configured build, and installation
+        id: openmpi-cache
+        uses: actions/cache@v4
+        with:
+          path: ~/prik-openmpi/${{ matrix.version }}
+          key: openmpi-${{ matrix.version }}-ubuntu-24.04-gfortran-13-v1
+      - name: Build and install Open MPI
+        if: steps.openmpi-cache.outputs.cache-hit != 'true'
+        shell: bash
+        run: |
+          root="$HOME/prik-openmpi/$OPENMPI_VERSION"
+          mkdir -p "$root/build"
+          curl -fsSL "https://download.open-mpi.org/release/open-mpi/$OPENMPI_SERIES/openmpi-$OPENMPI_VERSION.tar.bz2" \
+            | tar -xj -C "$root"
+          mv "$root/openmpi-$OPENMPI_VERSION" "$root/source"
+          cd "$root/build"
+          ../source/configure --prefix="$root/install" --enable-mpi-fortran=usempif08 FC=gfortran
+          make -j"$(nproc)"
+          make install
+          # The test reads sources and generated headers from these trees and
+          # links the installation, so build objects are not cached.
+          find . \( -name '*.o' -o -name '*.lo' -o -name '*.a' -o -name '*.la' \) -delete
+          find . -type d -name .libs -prune -exec rm -rf {} +
+      - name: Run the Open MPI mpi_f08 workflow test
+        shell: bash
+        env:
+          PRIK_OPENMPI_REQUIRED: "1"
+        run: |
+          root="$HOME/prik-openmpi/$OPENMPI_VERSION"
+          export PATH="$root/install/bin:$PATH"
+          export LD_LIBRARY_PATH="$root/install/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"
+          export PRIK_OPENMPI_SOURCE="$root/source"
+          export PRIK_OPENMPI_BUILD="$root/build"
+          export PRIK_OPENMPI_MPIFORT="$root/install/bin/mpifort"
+          export PRIK_OPENMPI_LAUNCHER="$root/install/bin/mpirun"
+          python -m pytest -q -rs tests/fortran/assumed_types/end_to_end/test_openmpi_f08.py

AGENTS.md

@@ -36,10 +36,70 @@ Ignore:
 - *.json
 
 Do not spend context window or analysis on those files unless explicitly requested.
+Keep one path for one question. When two entry points answer the same
+question -- one file and a project, a library route and its CLI wrapper, source
+discovery and compile ordering, a source build and a contract replay -- they
+must call the same owner and differ only in the inputs they pass, such as which
+files or modules are in scope. Do not write a second loop, list, inventory,
+regex, lexer, or conversion route that re-derives what an existing owner
+decides, even as a fast path: a fast path may narrow what the owner reads, but
+the owner's answer stays the only answer. Before adding a helper that
+enumerates or classifies something -- a module's procedures, a file's program
+units, a `use` nature, the intrinsic modules, Fortran source suffixes, a
+submodule's identity -- find the existing owner and extend it. When two copies
+are found, merge them into one owner instead of fixing only the copy that
+failed, and prove the merge with a test that runs both entry points on one
+input and compares their results.
+
 When asked to change or move an API, import path, command, feature, or behavior, do not add or keep compatibility layers, aliases, shims, fallback paths, or legacy entrypoints unless explicitly requested. A requested change means the old behavior should be removed.
 When updating tests, remove obsolete tests that only assert removed/old implementation behavior does not exist. Do not preserve rejection or absence checks for API/features that were intentionally removed unless explicitly requested.
 Do not add tests whose purpose is only to prove that removed or nonexistent features are rejected. Test supported behavior and meaningful validation boundaries instead. For example, if `ArrayCategory` is removed, delete its tests; do not add a test asserting that `ArrayCategory` now fails.
 
+Optimize the test suite for maximum confidence per test and minimum
+maintenance burden, not for test count. Treat end-to-end tests as the primary
+proof that a feature works: where practical, demonstrate a feature through the
+real workflow (source, preprocessing, parsing, semantic IR, `.pyi` contract,
+replay or build, generated wrapper, compile and link, import, runtime call) and
+finish by checking a concrete, repeatable result such as runtime values, native
+state, generated contract or source text, or the native build plan. One strong
+end-to-end test that covers several cooperating features should replace
+several lower-level tests that only repeat pieces of the same behavior.
+
+Delete a test, rather than preserve it because it exists, when its only
+purpose is to check implementation details, trivial getters, constructors,
+dataclass fields, or plumbing; to repeat behavior a stronger end-to-end test
+already proves; to assert an intermediate object only because it currently
+exists; to test a tiny helper that is exercised thoroughly elsewhere; to repeat
+one case at several stages; to lock internal architecture without protecting
+user-visible behavior; or to add near-identical permutations that do not
+represent distinct failure modes.
+
+Keep a focused isolated test only when it is the cheapest or clearest way to
+protect a boundary that end-to-end tests do not cover economically, and when
+it has a clear answer to: **what realistic regression does this catch that
+would otherwise be difficult, expensive, or ambiguous to detect?** Typical
+answers are parser grammar edge cases; preprocessing and source-discovery
+rules; semantic transformations with many meaningful combinations; export and
+re-export resolution; diagnostics and error locations; contract round trips;
+compiler-independent behavior that would otherwise need many native builds;
+subtle regressions whose end-to-end failure would not say which rule broke;
+and negative validation paths that are cumbersome or unsafe to reproduce
+through a full build. If there is no good answer, remove the test. In PRIK,
+scrutinize especially tests of parser internals, semantic IR details,
+policy and planning intermediates, generated-code string fragments,
+source-versus-build route parity, and duplicated source-versus-generated-`.pyi`
+assertions; where the two routes are meant to agree, prefer one shared parity
+test over the same behavioral assertions in both.
+
+When fixing a real bug, first ask whether an existing end-to-end test can be
+strengthened to cover the regression. If not, add the smallest focused
+regression test at the layer where the bug reproduces clearly. Do not add a
+unit test merely because production code changed. Before testing a subsystem
+in isolation, list the distinct realistic ways it could fail and test those
+behavioral boundaries with a small table of meaningful cases instead of
+mirroring the implementation line by line. Do not change production behavior
+to make a test easier to delete.
+
 Treat tests as evidence for a named invariant, not as specifications merely
 because they already exist. Add or retain automated tests when they protect at
 least one of the following:
@@ -72,7 +132,10 @@ and the earliest stage that can prove it. Keep the resulting evidence concise:
 - One test may assert several related consequences of the same setup and
   invariant. Do not create one test function per field or incidental detail.
 - Use parametrization when cases exercise the same operation and assertion
-  shape with different inputs, and give every row a descriptive ID.
+  shape with different inputs, and give every row a descriptive ID. Keep only
+  the rows that exercise distinct code paths instead of a full matrix.
+- Prefer one end-to-end workflow that exercises several cooperating features
+  over a separate native build for every small operation.
 - Do not repeat the same invariant at adjacent stages. Add another stage test
   only when it protects a real handoff, completed decision, generated artifact,
   ABI mechanism, or runtime behavior.
@@ -239,6 +302,9 @@ compilation should use the focused owners under
 `tests/fortran/infrastructure/building/compiling/` as applicable. Include the
 relevant end-to-end feature tests whenever a generated or compiled mechanism
 changes; run a broader suite when behavior spans multiple stages.
+Run ad-hoc compiler and build commands outside the repository root, for example in a temporary
+directory, so no `.mod`, object, or library file lands there; the test session refuses to start
+while native build artifacts sit in the root, since a stale one silently shadows a later build.
 Run pytest with at most `-n 2`. Never `-n 4`, `-n 8`, or `-n auto`. The development machine has 12 cores but only about 7 GB of RAM, and every xdist worker loads NumPy while the Fortran end-to-end tests fork gfortran and cc per test on top of `pytest-monitor` profiling each one. Higher parallelism exhausts memory and thrashes swap, which has hard-frozen the machine and forced a reboot. Prefer the narrowest owning test path over a full suite run, and commit verified work promptly rather than batching it behind a long run.
 Do not run LAPACK wrapper tests locally unless the user explicitly asks for them. Local verification may run everything else, including BLAS-only real-library tests; leave LAPACK coverage to GitHub Actions by default.
 Do not run the full coverage workflow for routine changes. Run focused tests plus the required static-analysis suite. Reserve the complete CI-style coverage workflow for explicit pre-merge or pull-request verification, or when the user specifically requests it.