Repository navigation
Sync main with anuga-community/anuga_core (3.3.2 → 3.3.10) - #300
Merged
Merged
Conversation
GitHub's macos-latest is Apple Silicon, so the wheel matrix produced only arm64 mac wheels — PyPI has no Intel-mac ANUGA wheel, so `pip install anuga` fails on Intel Macs. Add a build-wheels-osx64 job that creates an osx-64 conda env (CONDA_SUBDIR=osx-64; x86_64 python + compilers run under Rosetta 2) on the same arm64 macos-latest runner and builds a native x86_64 wheel, delocate-repaired. Avoids the scarce macos-13 Intel runners. Artifacts use the wheel-* name so the publish job collects them; added to the publish job's needs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Build Intel macOS (osx-64) wheels on the arm64 runner
Bumps the github-actions group with 1 update: [actions/checkout](https://github.com/actions/checkout). Updates `actions/checkout` from 6 to 7 - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@v6...v7) --- updated-dependencies: - dependency-name: actions/checkout dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major dependency-group: github-actions ... Signed-off-by: dependabot[bot] <support@github.com>
…s/github-actions-640176b5ab Bump actions/checkout from 6 to 7 in the github-actions group
… large t store_quantities() raised "IndexError: index 0 is out of bounds for axis 0 with size 0" deep into long runs (e.g. t~6960 s). When the time being written is <= the last stored time (checkpoint resume, or a near-duplicate yield time), it searched for the existing slot with an absolute tolerance of 1e-14 and used check[0][0] with no guard. But 1e-14 is below the float64 ULP for any t beyond a few tens of seconds, so the match silently fails at large t and check[0] is empty -> the whole run dies at the write. Scale the tolerance to the time magnitude (1e-9*max(1,|t|)) so legitimate matches are found at large t, and fall back to appending (with a warning) instead of crashing when nothing matches. Verified with a reproduction at t~6960 s: previously IndexError, now overwrites the correct slot. Same code on main and develop; affects any sufficiently long simulation. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
fix(sww): don't crash storing a near-duplicate/checkpoint timestep at large t
…ructure logs Bring the parallel structure-operator logs up to the sequential ones: - Add the accumulated_flow column (already computed on the master proc, just never written) to the log header and timestepping_statistics(). - Fix the operator counter so every rank advances it in lockstep -- participants in the constructor, non-participants in the factory's `return None` branch -- so each operator gets a unique, rank-consistent number even when the culvert and trap have different master procs. Previously only the master advanced, which mis-numbered structures once rank counts grew. - Drop the _P<rank> suffix from the log filename so it matches the sequential name (culvert_0.log, trap_1.log); the log is already a single combined, master-written file. Verified np=4 and np=16 logs are bit-identical to the sequential run. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> (cherry picked from commit d55e198)
The trapezoid critical-depth Newton solve in weir_orifice_trapezoid_function hardcoded 9.81 (inconsistent with the anuga.g used elsewhere in the same function), so weir flow_area / reported velocity were wrong for any non-9.81 gravity. Add a `g` argument (default anuga.g for direct callers) and use it for every gravity term, replacing the hardcoded 9.81 and the module-global anuga.g; the serial and parallel discharge routines pass self.domain.g. Note: shifts weir results by ~0.034% in partly-full flow when domain.g != 9.81 (e.g. the 9.8 default), since the reference no longer uses the 9.81 literal. Backport of the Python portion of develop commit 467255f to the 3.3.x line; the develop commit also fixes the mode-2 GPU kernel, which does not exist here. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Legacy structure-operator fixes for 3.3.8 (parallel logging + weir gravity)
meson.build compiled the OpenMP extension modules with -march=native. As a meson project c_arg it takes precedence over the environment CFLAGS, so on a GitHub CI runner GCC expands it to the runner's exact microarchitecture and bakes that ISA into the .so files — including the Cython module-init function. A wheel built on a Sapphire Rapids runner therefore gets AVX-512 (x86-64-v4) and crashes with an illegal instruction at `import anuga` on any CPU without it. This broke the 3.3.8 PyPI Linux wheels (e.g. Google Colab), and is intermittent across releases because it tracks whichever runner built the wheel. Drop -march=native so the toolchain's portable default stands (conda-forge sets -march=nocona). This matches develop, whose wheels build as baseline/v2 with no AVX-512. Peak-performance builds should come from source or conda. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Fix non-portable PyPI wheels: drop -march=native from meson.build
`conda create ... python=3.14` on linux-64 resolves to the free-threaded build (python 3.14 ..._cp314t), so the Linux 3.14 wheel was tagged cp314-cp314t (free-threaded ABI) instead of the standard cp314. A normal GIL CPython 3.14 on Linux then finds no matching wheel and falls back to the sdist. macOS/Windows resolved to the standard build, so only Linux was hit. anuga's OpenMP extensions aren't declared free-thread-safe, so the standard GIL wheel is what we want. Constrain python_abi to the GIL build (*_cp<tag>) in the build-wheels and build-wheels-osx64 env-create steps. python_abi uses the cp3XX ABI tag consistently across versions (unlike the python package, whose build string is _cpython for 3.10-3.12 but _cp3XX for 3.13+), so this excludes cp3XXt, is a no-op for 3.10-3.13, and doesn't break the older builds. Verified by dry-run solve: 3.14 -> python 3.14.6 ..._cp314 (GIL), 3.10 -> python_abi 3.10 8_cp310. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
CI: build standard (GIL) cp314 wheels, not cp314t
All 20 wheel builds started failing on every platform:
anuga/utilities/sparse_matrix_ext.pyx:73:25:
Cannot assign type 'dict_items object' to 'list object'
Cython 3.3.0 landed in CI (conda-forge, 2026-08-23) and no longer permits
assigning a dict view to a `cdef list`. Nothing in ANUGA changed; my local
Cython is 3.2.5, which still accepts it, which is why local builds stayed green.
In _deserialise():
* `items = serial_dok.items()` was assigned and never used -- deleted rather
than fixed.
* `keys = serial_dok.keys()` needs an explicit list(), and would have failed
next: the build stopped at the first error, so only the items line was
reported.
* `xrange` -> `range` while here; it is a Python 2 builtin.
Verified by compiling the file with Cython 3.3.0 in a throwaway venv, before
and after: 'Cannot assign type' twice before, clean C output after. Local
rebuild, anuga/utilities tests (329) and the fast suite (2728 passed) are green
on 3.2.5, so the fix works on both.
Only this file was affected -- the other .pyx uses of .items() iterate rather
than assign, which remains legal.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
With the Cython 3.3.0 fix in place, Linux and macOS build again but all five
Windows jobs still fail, now in meson's compiler sanity check:
ld.exe: cannot find crt2.o: No such file or directory
ld.exe: cannot find default-manifest.o: No such file or directory
ERROR: Compiler x86_64-w64-mingw32-cc cannot compile programs.
Same root cause as PR #233 on develop: conda-forge's m2w64-sysroot rebuild
(build 11, 2026-08-20) is not self-consistent with the compilers that an
unpinned install now resolves to. main is unpinned, so it picked up gcc
16.2.0 against a sysroot that does not carry the matching CRT objects --
hence missing crt2.o rather than develop's "not runnable" / stack-smashing
signature. Both are the same incompatibility seen from different sides.
This lifts the pin block from develop verbatim into both workflows: gcc/gxx
16.1.0 build 2, the sysroot chain and libwinpthread at build 10, libstdcxx
16.1.0. Only the Windows compiler-install steps are taken -- develop's
workflow_dispatch/TestPyPI machinery is deliberately left behind, as it is
release-candidate tooling that does not belong on main.
TEMPORARY, exactly as on develop: remove once conda-forge admin-requests#2297
lands and the sysroot chain is coherent again.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fix the build on main (Cython 3.3.0 + Windows mingw toolchain)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Brings this repository's
mainup to matchanuga-community/anuga_core@main,which is the 3.3.10 release point. GA
mainwas last synced at 3.3.2.The 11 tags between those two points (
3.3.3…3.3.10, plus the older3.0.2,3.1.4,3.1.5that were also absent) have already been pushed tothis repository separately. No GitHub Releases were created for them, and none
should be — a bare tag does not trigger the PyPI publish workflow, which is
gated on
github.event_name == 'release'. Publishing to PyPI is done fromanuga-community, not from here.What changes
Seven non-merge commits, touching 8 files:
anuga/file/sww.pyanuga/parallel/parallel_operator_factory.pyanuga/parallel/parallel_structure_operator.pyaccumulated_flowin structure logsanuga/parallel/parallel_weir_orifice_trapezoid_operator.pyanuga/structures/weir_orifice_trapezoid_operator.pydomain.g, not hardcoded 9.81meson.build-march=nativefromopenmp_c_argsso wheels are portable.github/workflows/python-publish-pypi.yml.github/workflows/conda-setup.ymlNote on history
This is a merge rather than a fast-forward. GA
maincarries one commit thatanuga-community/maindoes not — merge 9a7ef66 ("Merge pull request #296 fromstoiver/main", 19 Jun). Its content is already present upstream via a
different route: no file exists on GA
mainthat is missing fromanuga-community/main, and the only content difference between the twobranches is the 8 files above, all of which are upstream-forward changes.
So nothing is lost by merging. A force-push would have made the two histories
identical as well as the content, but this repository's ruleset blocks
non-fast-forward pushes, hence the merge commit.
🤖 Generated with Claude Code