Repository navigation
PENTRC Kinetic Profile Splines Need Robustness #52
Description
The kinetic splines in PENTRC are currently interpolated to a regular grid in psi_n prior to the calculation of log(Lambda) and the collisionalities. This was done to fix spline oscillations observed (but currently undocumented) when using GA pfile inputs. However, recent NSTX-U inputs without data all the way to psi_n=1 see that the n,T extrapolations to ~0 cause spikes in the log(Lambda) and ringing in the splines.
A new robust way to check the spline integrity prior to attempting a run is needed.
Activity
logan-nc commentedon Oct 5, 2017
@zrwang2015 maybe your new splines can help me here? What I do now, I do because the old splines were oscillating when used with some of the profile data I got from Matt Lanctot and others at DIII-D. Would your new one be more robust to the data?
krystophny commentedon Oct 15, 2026
A concrete reproduction of the derived-collision-rate spline problem in #52 remains on current
develop(3e1946773db75aaf8e5ac5f4faa5110c636bb18c). Positive primitive density and temperature profiles can produce a negative off-grid collision rate becauseread_kincomputes rates on 101 uniform points and subsequently cubic-interpolates the nonlinear rates themselves.The attached independent native regression generates 200 samples through
psi_n=0.99485, withni=ne=1e19 m^-3,Ti=100+72000*(1-psi_n) eVandTe=1.2*Ti. Both input temperatures remain positive, including their linear continuation topsi_n=1. Atpsi_n=0.984411, current native interpolation givesnu_i=-91.35790498 s^-1; the original Coulomb model evaluated from those positive primitives gives284.40706355 s^-1. At0.985957, the values are-109.73892880versus325.72857983 s^-1.The regression compiles the production profile reader, native splines and exact torque query paths. It checks rates and analytic gradients against an independent Coulomb oracle, diagnostic/export positivity, and preservation of existing
nfac/tfaccollision semantics. It fails before the repair and passes afterward; maximum rate error is1.42e-7relative. Run the companion PR's registered test withmake -C install check-pentrc-collisionsin the normal compiler/NetCDF environment.The proposed repair evaluates the existing Coulomb model at each primitive-profile query and shares that result across torque and output consumers. It preserves primitive interpolation and model constants. This addresses interpolation of the derived rates; broader primitive-profile validity questions in #52 remain separate.
Chris&AI
logan-nc commentedon Oct 16, 2026
It looks like @krystophny and @StuartBenjamin are independently investigating this.
I think #300 should solve your issues @krystophny ... what do you think?
krystophny commentedon Oct 16, 2026
Thanks. I think #300 and #318 complement each other, and neither one covers the other.
#300 changes how the tabulated primitive profiles are fitted:
read_kinnow uses pchip in place of the "extrap" cubic spline. That stops n and T overshooting between table points, which fixes the oscillations this issue started from. But it leaves the second step alone: ν and logΛ are still computed on the regular 101-point ψ_N grid and then cubic-splined. Your PR description says this too ("PENTRC's regular-grid spline of ν (still a cubic spline) rings"). In my reproducer the profiles are linear in ψ_N (constant n, linear T). Cubic splines and pchip both reproduce linear data exactly, so #300 gives the same primitives. The negativenu_i=-91.36 s^-1atpsi_n=0.984411should therefore still appear with #300 alone.#318 removes that second interpolation. It evaluates the Coulomb model at each primitive-profile query, so a bad edge node can no longer make ν ring further inward. It keeps whatever primitive fit is in place, so it works with pchip as well.
So I'd suggest merging both. They touch neighbouring parts of
read_kin, so whichever goes in second will need a small rebase. I'm happy to rebase #318 onto #300 if that helps.One part of this issue would still be open after both: checking that the primitive profiles are valid where they are extrapolated past the last table point. For example, T → 0 near ψ_N = 1 gives logΛ < 0. After #318 that would be a local bad value rather than ringing, but PENTRC should probably still detect it and warn or stop before a run starts.
Chris&AI