Skip to content

Add automatic computation of spitzer and neoclassical resistivities with profiles #222

Description

@matt-pharr

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.

Activity

  1. added this to the GPEC v2.0.0 milestone on Jun 17, 2026
  2. logan-nc commented on Jun 19, 2026

    @logan-nc
    Collaborator

    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!

  3. added theissue type on Jun 19, 2026
  4. matt-pharr commented on Jun 20, 2026

    @matt-pharr
    CollaboratorAuthor

    @d-burg @logan-nc I am doing this on the RPEC branch, just trying to figure out the best way to get total rotation

  5. logan-nc commented on Jun 20, 2026

    @logan-nc
    Collaborator

    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

  6. logan-nc commented on Oct 27, 2026

    @logan-nc
    Collaborator

    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.

  7. logan-nc commented on Oct 30, 2026

    @logan-nc
    Collaborator

    Reassessed now that #581 has merged. Most of this is done; the one remaining gap is the RPEC driven matching.

    Piece Status
    Profiles on the equilibrium (equil.kinetic) done, #581
    Spitzer / neoclassical η (Utilities.NeoclassicalResistivity: Spitzer, Spitzer–Härm, Sauter 1999, Redl 2021; trapped fraction from the GGJ surface geometry) done on develop. Sauter and Redl supersede the Jardin 1993 forms, so Jardin will not be added.
    SLAYER growth rates and the layer-overlap cap: η from n_e, T_e, Z_eff per surface done on develop
    GGJ tearing (TearingProblem with eta=nothing, rho=nothing): η from the same closure, ρ = m_i·n_i in #602 (_ggj_layer_inputs)
    RPEC matching (MatchProblem / [Match]): η, ρ and rotation still required by hand, on develop and in #602

    Plan to close this (a small PR against develop once #602 has merged):

    1. Reuse the one derivation that TearingProblem uses for MatchProblem. That means placing it where ForceFreeStates can reach it, next to ggj_parameters.
    2. MatchProblem eta, rho and rotation default to "derive from equil.kinetic"; explicit values still override, and a run without kinetic data errors with what to supply.
    3. Rotation is the E×B frequency, f = ω_E/2π, not the electron-fluid ω_E + ω_*e: GGJ is single-fluid resistive MHD and has no diamagnetic physics. This is the same frame SLAYER and Tearing - BUGFIX - Doppler-shift each GGJ surface into its own E×B frame in the coupled growth rates #612 use. One test pins the sign: for a static field, the layer sees s = i·n·Ω_E.
    4. 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.
    5. 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.

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

Metadata

Metadata

Labels

featureNew capability

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions