Skip to content

Reject unsupported periodic collision models#184

Closed
krystophny wants to merge 1 commit into
fix/flux-pumping/wp5-recompute-z0from
fix/flux-pumping/wp5-periodic-collision-guard
Closed

Reject unsupported periodic collision models#184
krystophny wants to merge 1 commit into
fix/flux-pumping/wp5-recompute-z0from
fix/flux-pumping/wp5-periodic-collision-guard

Conversation

@krystophny

@krystophny krystophny commented Jul 13, 2026

Copy link
Copy Markdown
Member

The periodic-Fourier driver currently assembles the restored Krook kernels regardless of collision_model. Reject every model except Krook until a continuum Fokker-Planck kernel is implemented, so an input cannot silently claim different collision physics.

Invariant: the supported Krook periodic assembly, Fourier convention, CGS units, grid, dense solve, and boundary behavior are unchanged.

Verification

Failing before, using the parent binary with collision_model = FokkerPlanck:

parent_exit=0
Collision Model............. FokkerPlanck
...fourier_periodic solve finished with 257 modes.

Passing after, using the same input:

fixed_exit=1
ERROR STOP fourier_periodic: only collision_model = Krook is implemented

100% tests passed, 0 tests failed out of 30
Static: OK
Build: OK
Tests: OK
Lint: OK
All stages passed

Relation to Markus's Fokker-Planck periodic branch

This guard closes a real semantic hole in the independent stack: a Krook kernel must not run under a Fokker-Planck label. Keep the guard until #187 verifies the FP kernel and #190 accepts the FP benchmark. #191 must replace the blanket rejection with explicit Krook/FP dispatch, not remove collision-model validation.

@marjohma

Copy link
Copy Markdown
Member

Closing: the wp5 flux-pumping stack is retired, and this guard protects a driver (rt_fourier_periodic.f90) that exists only in that stack. Its invariant — an input must not silently claim different collision physics — is being ported to the forced-periodicity run type (which currently consumes the FP susceptibilities regardless of collision_model), alongside the extraction of #182/#183.

@marjohma marjohma closed this Jul 15, 2026
marjohma added a commit that referenced this pull request Jul 15, 2026
)

## Summary

Extracts the two salvageable pieces of the retired wp5 flux-pumping
stack onto the forced-periodicity lineage. The rest of that stack
(#177#181, #184) is closed as superseded.

## Krook argument `z0` (was #183)

`interpolate_plasma_backs` interpolated the **derived** `z0` alongside
the primitives. `z0` carries a `1/|k_parallel|` singularity at the
resonance, so a four-point Lagrange stencil spanning `k_parallel = 0`
returns values that violate its own defining formula. The fix
interpolates primitives only and recomputes

    z0 = -(omega_E - omega - i nu) / (|k_parallel| sqrt(2) v_T)

on the target grid — the same invariant the periodized-background path
already follows.

**Scope:** `z0` is consumed only by `Krook_kernel_plasma_prefacs.f90`.
The Fokker-Planck path recomputes `x1/x2/A1/A2/I^{kl}` after
interpolation and never reads `z0`, so **FP results are bit-unchanged**.
This repairs the Krook hat path, whose nml still marks it `(unstable)` —
plausibly part of why.

## Collision-frequency scale (was #182)

New positive `&KIM_CONFIG` key `collision_frequency_scale` multiplying
the calculated electron and ion collision frequencies before `z0` and
the FP susceptibility inputs are assembled. Default `1.0` leaves every
collision formula, profile, unit, and output unchanged. Non-positive
values are rejected at startup; the value is displayed when it differs
from 1.0 and stored in HDF5 provenance. Same shape as the existing
`ion_flr_scale_factor` knob. No benchmark-acceptance claim — it is a
sensitivity parameter.

## Tests

`test_collision_scale_z0` (new) asserts the `z0` invariant on a stencil
straddling `k_parallel = 0` and away from it, and that the scale reaches
both `nu` and `z0` (including the imaginary part of `z0` tracking it).

Developed red-first: against the pre-fix code the test fails with a
**36% relative `z0` error at k_par = 2e-4** (`got (-0.0983, 0.0129)` vs
`want (-0.4543, 0.0599)`), growing without bound toward the resonance.

## Validation

- `make` — clean build
- `ctest -E
'test_rhs_balance|test_periodic_convergence|test_periodic_vs_global'` —
**32/32 passed**

Known red gates excluded as usual: the pre-existing `test_rhs_balance`
baseline failure, the periodization-deformation gate, and the
periodic-vs-global 5% gate — none touched by this change.

Supersedes #182, #183.
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.

2 participants