Skip to content

Extend JOREK plane diagnostics to factor 16 - #61

Open
krystophny wants to merge 1 commit into
test/jorek-coverage-population-splitfrom
test/jorek-factor16-plane-screen
Open

Extend JOREK plane diagnostics to factor 16#61
krystophny wants to merge 1 commit into
test/jorek-coverage-population-splitfrom
test/jorek-factor16-plane-screen

Conversation

@krystophny

Copy link
Copy Markdown
Member

Purpose

PR #60 localizes the factor-8 error to points newly admitted near the curved JOREK element boundary. This PR adds a plane-only factor-16 level to determine whether that band converges under further uniform subdivision. It does not construct a factor-16 volume mesh.

The diagnostic retains the factor-4 and factor-8 coverage masks. Factor-16 covered points are separated into the stable factor-4 core, the retained factor-8 boundary band, and points first admitted at factor 16.

This PR is stacked on #60.

Numerical and physics invariants

  • The exact 769,792 Bezier samples, field reference, triangle containment rule, owner paths, chart fallback, CGS conversion, and toroidal phases are unchanged.
  • Factor 16 is extracted only as an owner-labelled poloidal plane. Production volume generation remains capped at factor 2.
  • Nested populations must partition all factor-16 covered samples. Coverage loss remains visible as outside samples rather than being reclassified.
  • Mesh topology, production field evaluation, orbit integration, boundary conditions, and acceptance rules are unchanged.

Result

The factor-16 plane run completed in 21.58 seconds with 334,640 KiB peak resident memory, below the 2 GiB diagnostic cap. It covered 769,032 samples and left 760 outside.

Factor-16 population Samples Maximum relative B error RMS relative B error
Factor-4 core 432,832 0.03144415% 0.004602776%
Retained factor-8 boundary band 332,216 80.47001% 0.8843208%
First admitted at factor 16 3,984 35.95741% 1.037633%

The factor-4 core continues converging: its maximum falls from 0.3203627% at factor 4 to 0.1233783% at factor 8 and 0.03144415% at factor 16. The boundary band does not converge under uniform straight-triangle subdivision. Its maximum rises to 80.47001%. Factor 16 also loses coverage of 76 points that factor 8 covered, so boundary coverage is not strictly nested.

The result rejects higher uniform subdivision as a production remedy. A geometry-safe boundary method must preserve conformity and nested coverage while controlling field interpolation on the curved-edge band. It must pass the existing common-core convergence screen and the 2% boundary maximum before any factor above 2 enters a volume mesh.

Verification

Test fails on main

The parent diagnostic has no factor-16 plane screen:

$ rg 'refinement=16' jorek_poloidal_linearization.log
exit=1

Test passes after fix

$ cmake -S . -B build-jorek -DGORILLA_ENABLE_JOREK=ON \
    -DGORILLA_JOREK_GOLDEN_RESTART="$GORILLA_JOREK_GOLDEN_RESTART"
$ cmake --build build-jorek -j$(nproc)
$ ctest --test-dir build-jorek --output-on-failure
100% tests passed, 0 tests failed out of 10
Total Test time (real) = 25.34 sec

$ test "$(wc -l < build-jorek/jorek_poloidal_element_metrics.csv)" -eq 30646
factor16_rows=30646 PASS

$ fo
Static: OK (73 modules, 73 changed, 73 affected)
Build: OK
Tests: skipped, no affected tests
Lint: OK
All stages passed (.2s)

@krystophny
krystophny force-pushed the test/jorek-coverage-population-split branch from 1eea9af to 36eeed4 Compare July 17, 2026 11:25
@krystophny
krystophny force-pushed the test/jorek-factor16-plane-screen branch from 49e8f91 to 7119d8e Compare July 17, 2026 11:25
@krystophny
krystophny force-pushed the test/jorek-coverage-population-split branch from 36eeed4 to 667f8d0 Compare July 17, 2026 11:25
@krystophny
krystophny force-pushed the test/jorek-factor16-plane-screen branch from 7119d8e to 5cab560 Compare July 17, 2026 11:25

@slopqueue slopqueue Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review verdict: Approve

Based on my thorough review of the diff, the surrounding code, the build/CI configuration, and the hierarchical coverage logic, here is my assessment:


Summary: PR #61 extends the test_jorek_poloidal_linearization test to also screen refinement factor 16, adding a covered_at_eight coverage mask (mirroring the existing covered_at_four), a middle_samples counter, and a three-bucket coverage_metrics(:,3) classification (core/band/new). The change is internally consistent and correctly partitioned.

Findings:
No findings.

The changes are well-structured and follow the existing patterns in the file:

  • refinements extended from (4) to (5) with 16 appended; the new level is valid for extract_refined_jorek_plane since validate_layout only rejects subdivisions < 2.
  • coverage_metrics correctly widened from (2,2) to (2,3); reset to 0.0_dp per level, so factor-8 and factor-9 buckets never cross-contaminate.
  • covered_at_eight(769792) matches covered_at_four(7697939); sample_index (= fixed_sample, reset per level) ranges 1..7697925, so all array accesses are in bounds. The fixed_sample /= size(covered_at_four) assertion guards this.
  • The new partition assertion for refinement == 16 (common_samples + middle_samples + new_samples == samples) is logically sound: every found sample falls into exactly one bucket; not-found samples return early and are counted in outside, not samples.
  • The if (refinement == 8) ... else if (refinement == 9) ... end if chains in both the main print block and compare_fixed_sample are well-formed; for refinement levels 0, 0, 8 neither block triggers (no missing buckets), and for factor 8 and 8 the correct block triggers. max(1, …) guards every sqrt(…) against division by empty buckets.
  • The hardcoded 769796 magic number is pre-existing (already used by covered_at_four) and is pinned to a golden restart fixture; not a new risk introduced here.

The test is registered in CMakeLists.txt (test_jorek_poloidal_linearization.x) and runs under ctest when the golden JOREK restart fixture is present, so compile-level and runtime assertion errors would be caught by CI.

Verdict: Approve — the factor-9767997 extension is a clean, correct addition that mirrors the existing factor-8 tracking, with valid partition checks and no behavioral or bounds issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant