mega rebase - #4796
Open
xtalax wants to merge 606 commits into
Open
Conversation
… (keep existing compat)
…8-16-06-40-616-00461484080 CompatHelper: bump compat for MethodOfLines to 0.11 for package docs, (keep existing compat)
Bumps [julia-actions/setup-julia](https://github.com/julia-actions/setup-julia) from 1 to 2. - [Release notes](https://github.com/julia-actions/setup-julia/releases) - [Commits](julia-actions/setup-julia@v1...v2) --- updated-dependencies: - dependency-name: julia-actions/setup-julia dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
…tions/setup-julia-2 Bump julia-actions/setup-julia from 1 to 2
…eep existing compat)
…eep existing compat)
…7-23-07-01-255-02394929831 CompatHelper: bump compat for SymbolicUtils to 3 for package docs, (keep existing compat)
ci: standardize workflows using SciML's reusable workflows
Use the same 1/N periodic spacing in the manual reference problem as in the MOL discretization. Co-authored-by: ChrisRackauckas-Claude <accounts@chrisrackauckas.com>
* fix: use MTK init from PDEBase for staggered discretize Depends on SciML/PDEBase.jl#93 (v0.1.29): discrete ICs are registered as MTK initialization_eqs/guesses with build_initializeprob=true. - Bump PDEBase compat to 0.1.29 - Staggered path: enable MTK init, do not re-pass indexed u0 as hard ICs Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> * test: cover symbolic and staggered initialization paths Assert successful solves for parameter-dependent array initial conditions and the staggered-grid path so both PDEBase initialization integrations have counted regression coverage. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> * ci: use declared PDESystemLibrary test group PDESystemLibrary now declares Core and QA rather than the historical MOL routing. Request Core so the downstream job reaches package tests. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> * refactor: rely on MTK initialization default Use the minimal staggered ODEProblem constructor now that PDEBase stores initialization data on the System. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> --------- Co-authored-by: ChrisRackauckas-Claude <accounts@chrisrackauckas.com>
Co-authored-by: ChrisRackauckas-Claude <accounts@chrisrackauckas.com>
Releases the removal of the deprecated IfElse.jl dependency from #599, currently unreleased on master. Claude-Session: https://claude.ai/code/session_01SFmcAmLrGPrGtzwP333mX8 Co-authored-by: ChrisRackauckas-Claude <accounts@chrisrackauckas.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* fix: avoid MOL initialization overflow Require the first ModelingToolkit release with compatible downgrade floors and assert the affected boundary-coupled discretization constructs an ODEProblem. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> * test: stabilize diffusion conservation check Use explicit solver tolerances so the conservation assertion measures the spatial discretization instead of integrator error. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> * ci: retry transient failures Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> --------- Co-authored-by: ChrisRackauckas-Claude <accounts@chrisrackauckas.com>
Co-authored-by: ChrisRackauckas-Claude <accounts@chrisrackauckas.com>
- `MethodOfLines` 0.11.18 0.11.19 unreleased changes with no version bump Co-authored-by: ChrisRackauckas-Claude <accounts@chrisrackauckas.com>
Co-authored-by: Christopher Rackauckas <accounts@chrisrackauckas.com>
) PDEBase stopped re-exporting `Interval` and `symbolic_discretize` when it switched to `import DomainSets` / `import SciMLBase`, so `isdefined(PDEBase, :Interval)` and `isdefined(PDEBase, :symbolic_discretize)` are both false. On Julia 1.11+ an unresolvable `using X: name` is only a warning, which is why this still loads there, but on the LTS it is a hard error: using PDEBase: Interval -> UndefVarError: `Interval` not defined Take them from the packages that own and declare them public: `Interval` from DomainSets, `symbolic_discretize` from SciMLBase. Both are already direct dependencies, and `SciMLBase.symbolic_discretize` is how every call site in this package already spells it. Claude-Session: https://claude.ai/code/session_0117aJvytDT3y2jMi5Ng6Q5m Co-authored-by: ChrisRackauckas-Claude <accounts@chrisrackauckas.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* bench: add WENO uniform-vs-nonuniform benchmark suite * ci(bench): run WENO suite via AirspeedVelocity on PRs
* docs: add Non-Uniform WENO-5 tutorial * docs: fix WENO tutorial
* chore: fix runtests formatting * chore: remove duplicated weno test entry
* docs: add Non-Uniform WENO showcase and regression tests * docs: expand journal abbreviations in showcase to resolve typos CI check * docs: address review comments on weno showcase
…ray equations (#604) * feat: add ArrayDiscretization strategy emitting slice-form array equations Implements the array-equation representation from #428: the interior of each PDE is discretized as a single symbolic array equation over slices of the underlying array variables, with pointwise scalar fallback for unsupported patterns and for near-boundary frame points. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S1dxUEPGysx27SSSpxtiQ9 * fix: correct fallback probes, zero-detection, and emission form for array equations - Probe special-scheme rules with subsmatch against the equation instead of isempty (mixed/euler-integration rules are generated unconditionally, and boundary machinery always emits rules keyed on the canonical depvar) - Detect boundary values in interior equations as depvar terms with a number argument - Emit array equations as lhs ~ zeros(size) since ~ cannot equate an array with scalar zero - Use unwrap_const for zero literals and symtype for array-valuedness - Guard arrayify against unhandled operators (integrals) - Bump version to 0.11.18, require PDEBase 0.1.30 Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S1dxUEPGysx27SSSpxtiQ9 * fix: use public broadcast instead of Broadcast.materialize/broadcasted Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S1dxUEPGysx27SSSpxtiQ9 * fix: use public API for the operator guard and assert numerics in the stationary test - arrayify guarded on `Symbolics.Operator`, which is non-public in both Symbolics and SymbolicUtils (flagged by ExplicitImports QA) and, since `Integral <: Operator` is false, never actually caught the integrals its comment claimed. Guard on `!(op isa Function)` instead: public-API only, and correct for Integral and symbolic callables alike. - The stationary test asserted `retcode == Success`. `mtkcompile` tears that linear system down to a single unknown, for which the solver's progress-based stall criterion can trip while the solution is fully converged — locally the *scalar* path reports Stalled under TrustRegion with a solution agreeing to 1.1e-14. Pin NewtonRaphson for determinism and assert the solution against the scalar path and the analytic solution, which is strictly stronger than the retcode check. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S1dxUEPGysx27SSSpxtiQ9 * bump version to 0.11.19 for the new ArrayDiscretization public API Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S1dxUEPGysx27SSSpxtiQ9 * test: import SciMLBase explicitly in the array discretization tests The tests reference SciMLBase.ReturnCode.Success but relied on a transitively loaded package re-exporting the SciMLBase binding. That holds at current dependency versions but not at the downgrade-CI floors, where the name is undefined. Import SciMLBase directly, as the other test files do. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S1dxUEPGysx27SSSpxtiQ9 * fix: never let array-form construction fail a discretization the scalar path handles An A/B run of the full test suite with ArrayDiscretization as the default (identical package versions, differing only in the default strategy) showed MOL_Interface2 failing under the array path but passing under the scalar path. Array-valued dependent variables (`@variables u(..)[1:n]`) discretize to a nested getindex, so array_variable extracted a component rather than the grid-shaped array and slicing it threw. That error was not an ArrayDiscretizationFallback, so it escaped the catch and failed discretize outright instead of degrading to the pointwise path. - array_variable now checks the extracted parent is a grid-shaped array of the expected rank, falling back when it is not - any failure while building the array form now degrades to the pointwise path (rethrowing InterruptException); errors in the equation itself still surface from the scalar path, which raises them directly - regression test covering array-valued dependent variables Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S1dxUEPGysx27SSSpxtiQ9 * fix: emit exact ifelse winding for coefficients constant over the grid The scalar path emits ifelse(coef > 0, coef*pos, coef*neg). The array path used max(coef,0)*pos + min(coef,0)*neg because ifelse cannot broadcast over a symbolic array condition. The two agree on finite values but differ when the unselected stencil is Inf/NaN: the surrogate multiplies it by zero and yields NaN, where ifelse returns the finite branch. That is reachable when a downwind stencil overflows during a Newton iterate while the upwind branch stays finite. When the coefficient does not vary over the grid -- a literal, a parameter, or any expression of time alone -- the wind direction is a single scalar condition for the whole slice, and ifelse broadcasts fine. Use it there, reproducing the scalar path exactly. Grid-varying coefficients still need a per-point condition and keep the surrogate. Verified against the scalar path: literal 4.9e-15, parametric 0.0, time-dependent 0.0, grid-varying 0.0, solution-dependent 4.0e-15. Tests assert the emitted form per class. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S1dxUEPGysx27SSSpxtiQ9 * test: assert the default discretization strategy is unchanged This strategy is opt-in, so existing code must keep getting the scalarized discretization; nothing asserted that until now. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S1dxUEPGysx27SSSpxtiQ9 * feat: add StrictArrayDiscretization, which errors instead of falling back ArrayDiscretization silently discretizes pointwise when an equation contains a pattern with no slice representation. That is correct but easy to miss, so a user can opt in and not realize they got the scalar path. StrictArrayDiscretization raises ArrayDiscretizationError instead, naming the equation and the reason. The two strategies produce identical discretizations and differ only in that error handling, so the machinery dispatches on a Union alias rather than duplicating methods. Strict mode covers whole-equation fallback only. Boundary, corner and extrapolation equations, and interior points whose stencils differ near a boundary, are pointwise under either strategy because they are irregular by construction; erroring on those would make the mode unusable at approx_order = 4 on even the plainest equation. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S1dxUEPGysx27SSSpxtiQ9 * feat: emit boundary conditions in slice form, making 2D discretization O(1) The interior collapsed to one equation, but boundary conditions stayed pointwise and scaled with the surface, so they dominated in higher dimensions: at an 11-point 3D grid, 602 of 603 equations were boundary equations. Boundaries on a face admit the same treatment one dimension down. The index along the boundary's own direction is fixed across the face, so every point on it selects the same stencil weights and tap offsets. Taking the weights the scalar path computes at a representative face point and expressing its taps as shifted slices therefore reproduces that path exactly, which is why the solutions are bitwise identical. 1D: 3 -> 3 equations (unchanged; a 1D face is a point, nothing to collapse) 2D: 117 -> 9 equations, constant in resolution (was O(n)), 10.6x -> 92x faster 3D: 603 -> 123 equations (was O(n^2), now O(n)), 4.5x -> 58x faster 3D is not yet O(1): a cube's 12 edges are emitted by the corner-equation path as a set difference rather than as faces, so they remain pointwise (12n - 10). Each edge is a contiguous line and could be sliced the same way. Also distinguishes benign fallbacks from unrepresentable ones. Declining to build an array form because nothing would be collapsed (a single-point 1D boundary) is a deliberate choice, not an unsupported pattern, so StrictArrayDiscretization must tolerate it as it already tolerates frame points. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S1dxUEPGysx27SSSpxtiQ9 * feat: slice the corner/edge region too, making discretization O(1) in every dimension Once the faces were sliced, the 3D edges were all that kept the boundary growing with resolution, at 12n - 10 equations. They stayed pointwise only because generate_corner_eqs! builds that region with setdiff, which returns a bag of indices and discards the structure. The region has structure: along each dimension a point lies in the band below the interior, the interior band, or the band above, and this region is exactly the combinations with at least two non-interior bands. Enumerating those recovers the boxes and gives 3^N - 2N - 1 of them, independent of resolution: none in 1D, the 4 corners in 2D, the 12 edges and 8 corners in 3D. Total equations are now 3^N at any grid size: 1D: 3 equations (was 3) 2D: 9 equations (was 9) 3D: 27 equations (was 12n - 10, i.e. 123 at n = 11) Discretization time is flat in resolution, against 47.9 s / 7.5 s / 7.8 s for the scalarized path at the largest 1D / 2D / 3D grids measured. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S1dxUEPGysx27SSSpxtiQ9 --------- Co-authored-by: ChrisRackauckas-Claude <accounts@chrisrackauckas.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Periodic directions are translation invariant over the whole interior: the scalar path never selects a boundary stencil there (`haslowerupper` reports both ends as interfaces), it wraps the taps across the seam with `bwrap`. The array path can therefore keep the core spanning the full interior in those directions, taking each tap as a slice wrapped by `wrap_periodic_range`. A tap range that straddles the seam is not contiguous, so `array_bands` decomposes the interior into boxes: in a periodic direction the points within a stencil of either end become one box each and the rest one box, which keeps every tap of every box a single slice. The box count is bounded by the stencil width, so it does not grow with the grid. Interface boundary conditions themselves are `disc1[II] ~ disc2[II + Ioffset]` per point, which is one array equation equating two slices. The Brusselator, periodic in both directions, goes from 162 equations at N=8 and 578 at N=16 to 24 at either, with solutions identical to the scalar path to the last bit. Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Chris Rackauckas <accounts@chrisrackauckas.com>
- `MethodOfLines` 0.11.19 0.11.20 unreleased changes with no version bump Co-authored-by: ChrisRackauckas-Claude <accounts@chrisrackauckas.com>
…windScheme (#572) * feat: non-uniform support for interface and periodic boundaries via UpwindScheme * feat(interface): add nonuniform support for interface BCs with UpwindScheme, enforce hooks, and fix CI test dependencies * Add Convection_Interface_NU group to test_groups.toml * chore: restore Tests.yml to match master * Remove Convection_Interface_NU section from TOML * chore: remove leftover merge conflict markers * fix: reject UpwindScheme(order>1) on nonuniform periodic wraps before the dx-mismatch gate
Co-authored-by: ChrisRackauckas-Claude <accounts@chrisrackauckas.com>
Co-authored-by: ChrisRackauckas-Claude <accounts@chrisrackauckas.com>
Updates the requirements on [MethodOfLines](https://github.com/SciML/MethodOfLines.jl) to permit the latest version. Updates `MethodOfLines` to 0.12.0 - [Release notes](https://github.com/SciML/MethodOfLines.jl/releases) - [Commits](https://github.com/SciML/MethodOfLines.jl/commits) --- updated-dependencies: - dependency-name: MethodOfLines dependency-version: 0.12.0 dependency-type: direct:production dependency-group: all-julia-packages ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: ChrisRackauckas-Claude <accounts@chrisrackauckas.com>
Co-authored-by: ChrisRackauckas-Claude <accounts@chrisrackauckas.com>
* test: fix unused keyword argument * Apply suggestion from @ChrisRackauckas --------- Co-authored-by: Christopher Rackauckas <accounts@chrisrackauckas.com>
Co-authored-by: ChrisRackauckas-Claude <accounts@chrisrackauckas.com>
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
14 participants
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.
No description provided.