Growth rate calculation functionality added to gslayer.f#173
Growth rate calculation functionality added to gslayer.f#173
Conversation
|
Thanks for making the PR @d-burg! |
slayer/gslayer.f
Outdated
|
|
||
| ! Slice out growth rates at layer_Q (Re(Q)) | ||
| CALL interpolate_slice_at_Q(REAL(deltas), | ||
| $ Q_range(w), inQs_log, slice) |
slayer/gslayer.f
Outdated
| $ Q_range(w), inQs_log, slice) | ||
|
|
||
| ! Match delta to delta prime to obtain growth rate | ||
| CALL gamma_from_delta_match(slice, iinQs, |
There was a problem hiding this comment.
|
How's it going @d-burg? Have |
|
@logan-nc it's going! Having some trouble parsing exactly which dependencies and function/routine calls are needed where (with all the nested equilibrium objects). My main questions are:
These questions all pertain to lines ~30-110 of the new |
slayer/layerinputs.f
Outdated
| @@ -0,0 +1,236 @@ | |||
| MODULE layerinputs_mod | |||
|
|
|||
| USE inputs, ONLY : kin | |||
There was a problem hiding this comment.
You need read_kin from this module as well
slayer/layerinputs.f
Outdated
| CALL initialize_pentrc(op_kin=.FALSE.,op_deq=.FALSE., | ||
| $ op_peq=.FALSE.) | ||
| ! manually set the pentrc equilibrium description | ||
| CALL set_eq(eqfun,sq,rzphi,smats,tmats,xmats,ymats,zmats, |
There was a problem hiding this comment.
I think the only equilibrium quantity the read_kin subroutine uses is chi1 (the normalization factor poloidal flux and psi_n). This is a public variable of the pentrc inputs module, so you should be able to set it more efficiently than having to do all this set_eq stuff with all the matrices. If that is hard for any reason (I think you might have to rename the variable like how dcon.F deals with overlapping names), then just add op_chi1 as an optional variable in the subroutine and use that if it is included in the inputs. See the progressbar in inputs.f for an example of how to use optional arguments.
slayer/layerinputs.f
Outdated
| c----------------------------------------------------------------------- | ||
| c Read and build equilibrium inputs | ||
| c----------------------------------------------------------------------- | ||
| CALL fourfit_action_matrix |
There was a problem hiding this comment.
I don't think you need the action matrices or to initialize_pentrc. You are not actually going to run pentrc. You literally just want to read that ascii table and make the kin spline.
slayer/layerinputs.f
Outdated
| CHARACTER(*) :: vmat_filename | ||
| INTEGER :: ising | ||
|
|
||
| OPEN(UNIT=debug_unit,FILE=TRIM(vmat_filename),STATUS="OLD", |
There was a problem hiding this comment.
You never assign anything to vmat_filename? Isn't it just blank then?
There was a problem hiding this comment.
Searching the repo for vmat_filename I only see it in rmatch/msing.f. It seems to be a special interface needed to do the eigenfunction inner/outer layer matching from resistive DCON. Not something standard. Not something in stride or normal dcon. It also doesn't seem to contain sq, which is what you need, right? Seems like you might be barking up the wrong tree here?
Thanks for checking in! Here are some quick replies
|
Overview@logan-nc -- this is a major extension of the SLAYER to support uncoupled and coupled multi-surface tearing growth-rate calculations via complex-plane dispersion scans with Adaptive Mesh Refinement (AMR). Previously, SLAYER only computed single-surface inner layer Delta/torque/b_crit; this branch adds the ability to find tearing mode growth rates by solving coupled dispersion relations across multiple rational surfaces. 17 files changed: +4,428 / -578 lines across 83 commits. Key ChangesNew Capabilities
New Files
Significantly Reworked Files
STRIDE Changes
Build System Fixes
Input/Namelist Changes (
|
|
@claude please review this pr |
|
Claude finished @logan-nc's task in 4m 50s —— View job PR Review: Growth Rate Calculation for SLAYERTasks:
This is a substantial PR that successfully implements uncoupled and coupled multi-surface tearing growth-rate calculations via complex-plane dispersion scans with AMR. The core physics logic, the AMR design, and the NetCDF I/O structure are well thought out and well documented. Below I've organized findings by severity. Definite Bugs1.
But the code sets: shr(ising) = shr_spl%f(1) ! line 395 — this is ln(q), NOT shear!This is then written to NetCDF as 2.
3. stat = nf90_open(path=ncfile, mode=NF90_WRITE, ncid=ncid)
4. tau_v = tau_r / pr ! line 131 — pr not initialized in new read_eq workflowThe module-level 5. REAL(r8) :: Qconv ! shadows sglobal_mod%Qconv
...
Qconv = lu**(1.0/3.0) * tau_h
tauk = Qconv ! tauk (=sglobal_mod%tauk) IS updated correctlyThe module-level 6. CALL sl_check( nf90_def_var(ncid, "n_amr_pts", NF90_INT,
$ (/qsing_dim/), var_npts_id) ) ! dimension = msing
...
CALL sl_check( nf90_put_var(ncid, var_npts_id, n_pts_arr) ) ! size = m_AMR
Design Issues / Code Quality7. CALL sl_check( nf90_def_var(ncid, "q_rational", nf90_int, qsing_dim, qr_id) )Safety factor values like 8. In sl_in%chi_p_arr = chi_p_prof ! implicit alloc to size 8 via F2003 semantics
sl_in%chi_t_arr = chi_t_prof
sl_in%kappa_arr = kappa_prof
CALL build_inputs(infile,ncfile,sl_in) ! accesses chi_p_arr(ising) for ising=1..msingThe Fortran 2003 automatic allocation makes the LHS array size 8 (from 9. WRITE(*,*) '$^$ opening netcdf file', ncfileThe 10.
11. The outer psi loop and rational-surface loop contain (now-removed?) debug Copilot Comments Addressed in Current CodeThe following Copilot comments appear to be false positives for the current state of the branch:
SummaryThe core AMR scan logic, dispersion determinant formulation, and NetCDF I/O framework are solid. The most critical issue before merge is bug #1 (shear stored as ln(q)), which affects the physics of every growth rate computed in |
|
@claude can you check whether all changes in the latest commit address your latest PR review? |
|
Claude finished @d-burg's task in 2m 49s —— View job Review of Latest Commit Against Previous IssuesTasks:
Commit All 6 Definite Bugs — FIXED ✅
All Design Issues — Resolved ✅
Copilot comment #15 ( One Remaining Issue
growthrates_flag=t ! Calculate growthrates on each rational surfaceThe flag est_gamma_flag=t ! Calculate estimated growth rates on each rational surfaceThis was flagged in both my previous review and Copilot comment #17 and was not addressed in Summary: 11/12 items addressed in |
|
@logan-nc STRIDE on this branch has broken for some reason despite scouring it for bugs and confirming that none of these changes are interfering with the ODE solve. Please hold off further action while I investigate |


The additions are structured as follows:
New block in
slayer.f:A simple block is added with approximate kinetic input data of the dimension(k) form that will be output by the upcoming
build_inputs.fmodule (to interface withequil.f). Here k=2 rational surfaces are included. This block calls thegamma_match()subroutine, which takes in kinetic input data and outputs growth ratesNew routines in
gslayer.f:The wrapper subroutine is
gamma_match(). This is called byslayer.f.gamma_match()calls these additional subroutines:gamma_match()isgamma_stability_scan(). This sets up grid packing and ouputs a Re(Q) by Im(Q) scan of inner layer deltasgamma_match()isinterpolate_slice_at_Q(). This subroutine outputs a deltas(Re(Q)=Q) column of growth ratesgamma_match()isgamma_from_delta_match(). This subroutine extracts the gamma corresponding to agamma_match()