You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add automatic computation of spitzer and neoclassical resistivities with profiles #222
Once profiles are implemented and their API is stable, we can automatically compute spitzer and/or neoclassical resistivities. Classical/Neoclassical definitions in a way that is easy to compute from g-files and profiles can be found in [1] S. C. Jardin, M. G. Bell, and N. Pomphrey, Nucl. Fusion 33, 371 (1993). Eqns 16-18. This can be paired with the InnerLayer module to set up automatic inputs if desired and profiles are available.
This was an orphan issue with no assignee... it's dangerous to assign 2 people but I think both @matt-pharr and @d-burg do actually need to do this for the unified IO needed for resistive inner layer calculations we discussed. So hopefully you can coordinate to get it done and close this!
the existing function calculates it from the omegaE and diamagnetic rotations assuming zero poloidal rotation. There is also a wtfac for scanning it. You could add it as an optional column users can directly specify if you want and have the difference between chalked up to poloidal rotation. Or if wanting to be fancier, you could introduce a rotation_model toml param that has options that specify what the current rotation column gives. since we have the diamagnetic from n,T the options could be things like "we_from_wt" or "wt_from_we" or "wt_and_we_direct" etc. This could allow a user to specify an omega_poloidal column in the future, which would be a nice upgrade
Not opening a PR: this depends on the kinetic-profile API that #581 (draft) is still changing (equil.kinetic, kinetic_profile_splines), and Matt has it on the RPEC branch. Building it on today's develop would be rewritten twice. Revisit once #581 is out of draft; the Jardin Eqs. 16–18 form needs only n_e, T_e, Z_eff and q, all of which #581 attaches to the equilibrium.
Plan to close this (a small PR against develop once #602 has merged):
Reuse the one derivation that TearingProblem uses for MatchProblem. That means placing it where ForceFreeStates can reach it, next to ggj_parameters.
MatchProblemeta, rho and rotation default to "derive from equil.kinetic"; explicit values still override, and a run without kinetic data errors with what to supply.
The four matching decks keep their explicit η, ρ and f, so no harness rows move. Switching the DIII-D-like resistive decks to derived values can come with the example cleanup in Example Folder Cleanup #351.
One small testset on an existing matching fixture: the derived values equal the explicitly passed ones, and the no-kinetic-data error. Run the harness to confirm nothing moves.
@matt-pharr, flagging this so you're aware, since it builds directly on _ggj_layer_inputs in #602. If you'd like to take it on, that's welcome; otherwise we'll pick it up after #602 merges.
Activity
logan-nc commentedon Jun 19, 2026
This was an orphan issue with no assignee... it's dangerous to assign 2 people but I think both @matt-pharr and @d-burg do actually need to do this for the unified IO needed for resistive inner layer calculations we discussed. So hopefully you can coordinate to get it done and close this!
matt-pharr commentedon Jun 20, 2026
@d-burg @logan-nc I am doing this on the RPEC branch, just trying to figure out the best way to get total rotation
logan-nc commentedon Jun 20, 2026
the existing function calculates it from the omegaE and diamagnetic rotations assuming zero poloidal rotation. There is also a wtfac for scanning it. You could add it as an optional column users can directly specify if you want and have the difference between chalked up to poloidal rotation. Or if wanting to be fancier, you could introduce a rotation_model toml param that has options that specify what the current rotation column gives. since we have the diamagnetic from n,T the options could be things like "we_from_wt" or "wt_from_we" or "wt_and_we_direct" etc. This could allow a user to specify an omega_poloidal column in the future, which would be a nice upgrade
logan-nc commentedon Oct 27, 2026
Not opening a PR: this depends on the kinetic-profile API that #581 (draft) is still changing (
equil.kinetic,kinetic_profile_splines), and Matt has it on the RPEC branch. Building it on today's develop would be rewritten twice. Revisit once #581 is out of draft; the Jardin Eqs. 16–18 form needs only n_e, T_e, Z_eff and q, all of which #581 attaches to the equilibrium.logan-nc commentedon Oct 30, 2026
Reassessed now that #581 has merged. Most of this is done; the one remaining gap is the RPEC driven matching.
equil.kinetic)Utilities.NeoclassicalResistivity: Spitzer, Spitzer–Härm, Sauter 1999, Redl 2021; trapped fraction from the GGJ surface geometry)TearingProblemwitheta=nothing, rho=nothing): η from the same closure, ρ = m_i·n_i_ggj_layer_inputs)MatchProblem/[Match]): η, ρ and rotationPlan to close this (a small PR against develop once #602 has merged):
TearingProblemuses forMatchProblem. That means placing it whereForceFreeStatescan reach it, next toggj_parameters.MatchProblemeta,rhoandrotationdefault to "derive fromequil.kinetic"; explicit values still override, and a run without kinetic data errors with what to supply.@matt-pharr, flagging this so you're aware, since it builds directly on
_ggj_layer_inputsin #602. If you'd like to take it on, that's welcome; otherwise we'll pick it up after #602 merges.