-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New refit without contouring #36
Conversation
Does this make use of the recent auto differentiation capabilities in TEQUILA? |
Is there a comparison yet of profile variation of shape coefficients between GACODE and the various FUSE components? I would like to see this. |
@jcandy Not yet, but we could do it. Do you have a specific case you'd like to look at? |
I have used JuMP in the past and it worked. However I find the metaprogramming associated with it to be a bit clunky. I am thinking that perhaps we could easily write a optimization function that has a similar API to This thought aside, looks good to me and I have no comments. Merge when you are ready. |
@jcandy See the edited description at the top of the issue now that describes what's happening here. |
@bclyons12 maybe comment why you chose to go with this new method ;) |
@orso82 Yes, JuMP is a little weird, but I found it's great for nonlinear constraints. I need pretty much the exact (R,Z) extrema points and JuMP gives it to me. I'm not sure JuMP is optimal, but this is so fast [milliseconds instead of O(second) before] I don't think we need to worry about it. I'm just testing for robustness now, but so far, so good. |
@orso82 Good call. The old method is fundamentally limited by its Step 1. You have to put Psi onto a grid, so the accuracy of your flux surfaces is limited by the resolution of the grid. Calls to Psi(R,Z) are somewhat slow in TEQUILA, since you need to do the nonlinear conversion of (R, Z) to (rho, theta), so going to high resolution in the grid was dominating the runtime in FUSE. Going to lower resolution sped things up, but limits the amount of convergence you can get. This takes care of all of that. Here are results running at moderate resolution for
Old
New
|
Fantastic! Could the accuracy be an input parameter. It looks like now you can converge to 1E-6 with much fewer iterations. That should speedup things! |
I sent email on Feb 27 with results for an NSTX case that you sent me |
Will this new approach be used in ExtendedMillerHarmonic.jl? |
@lstagner This is a different capability from what's in MillerExtendedHarmonic.jl, which has functions for reading in a bunch of (R, Z) points and giving an MXH fit to those points. This method is for getting MXH coefficients such that the curve satisfies |
This sounds like a good idea @bclyons12 ! |
And great point @lstagner !! |
I also think the fft method to determine the coefficients (instead of the current integral method) may be more faster/stable |
@lstagner agreed when contouring from a field, but it won't work if you just give (R,Z) coordinates, since you need equal spacing in theta to do an FFT |
My thought was to create a spline and then do equal spacing. I do wonder what the spacing would need to be to resolve higher modes. Does the moment method work better for calculating the coefficients? |
My guess is that the moment method will give the best fit to arbitrarily spaced points. I'm not sure there would be an advantage to splining, downsampling, then taking an FFT. Perhaps it would be faster but that's not obvious to me. Fitting a contour to a field, like here, is a different problem. |
This change bypasses the standard MXH fitting infrastructure
Old steps
New steps