Skip to content
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

BEAMS3D/FIELDLINES: Bug (and solution) for failures of inverse lookup. #354

Open
kudav opened this issue Feb 20, 2025 · 10 comments · May be fixed by #356
Open

BEAMS3D/FIELDLINES: Bug (and solution) for failures of inverse lookup. #354

kudav opened this issue Feb 20, 2025 · 10 comments · May be fixed by #356
Assignees
Labels
bug Something isn't working

Comments

@kudav
Copy link
Collaborator

kudav commented Feb 20, 2025

Running BEAMS3D with AUG equilbria from VMEC (with ns=512, ftol_end=1e-19) produces wrong fields on some individual grid points. This extends to the BR, BZ and U values, but sometimes also to BPHI and S. Ive tried both with and without -plasma with essentially the same results. Changing the grid resolution changes where these grid points occur.
The black dots in the left panel show the R and Z locations of the VMEC grid, the right panel the differnce of the U_ARR variable in the R direction to clearly show the 0 values. Here, nr=301, nz=501.
Image
There were some changes to the functions in vmec_utils in the last year or so, which get perform the inverse lookups to construct the cylindrical grid. Is it possible that these introduced bugs?

@kudav kudav added the bug Something isn't working label Feb 20, 2025
@kudav kudav self-assigned this Feb 20, 2025
@lazersos
Copy link
Collaborator

This is an occasional issue with the inverse lookup. It looks to be an issue with the lookup in the region where theta transitions from 2*pi to zero. If you upload a fixed boundary input file it can be debugged.

@lazersos
Copy link
Collaborator

The GetBcyl routine in LIBSTELL/Sources/Modules/vmec_utils.fhandles two error cases. If the error flag returns -3 then the point is well outside the equilibrium domain. If the flag returns -1 then there was a failure to converge the inverse lookup to sqrt(ftol)=1E-16. If either of the error codes are thrown a value for S and U may be returned but no computation of B is performed. Now GetBcyl has a parameter fmin_acceptable = 1.E-12_dp which is used to pass points which fail the lookup tollerance but may still be considered 'good'. Using @kudav case I get the following:

Image

So clearly points inside the equilbrium are failing the lookup. These points do return a value for S but not a meaningful Br,Bphi, or Bz.

@lazersos
Copy link
Collaborator

If I set fmin_acceptable = 1.E-6_dp, then the problem seems to go away:

Image

I'm hesitant to make the change in the code official, but I think it's worth noting this issue. I would suggest that @kudav you modify your sources (line 56 of vmec_utils.f) and recompile.

@lazersos lazersos pinned this issue Feb 20, 2025
@lazersos lazersos changed the title BEAMS3D: axisymmetric VMEC produces B_R=B_Z=0 on single grid points BEAMS3D/FIELDLINES: Bug (and solution) for failures of inverse lookup. Feb 20, 2025
@kudav
Copy link
Collaborator Author

kudav commented Feb 24, 2025

This issue seems to also exist in W7-X cases using VMEC+VC (this is for an EIM configuration, with the nominal tolerance):
Image
Clearly, the lookup fails here just as in the AUG case. I'm re-running the same case with 1e-6 tolerance to see if the fix is the same.

@lazersos
Copy link
Collaborator

@kudav Let us know the outcome. The issue is related to the inverse lookup so both runs with VMEC+VC and the -plasma flag (so only VMEC) would have this issue. If changing the tolerance helps then we can make a new pull request.

@kudav
Copy link
Collaborator Author

kudav commented Feb 25, 2025

I could not find any wrong grid points with the decreased tolerance, and the fast ion distribution also seems much less affected by artifacts, so I'd say the fix works but perhaps a more in-depth search for the causes is warranted, since it does have a meaningful impact?

Image
(left: original, right: with decreased tolerance, I also changed the FIDASIM distribution grid, hence the increased resolution)

@lazersos
Copy link
Collaborator

I'm going to run a scan of the parameter to see what makes the most sense. This is a tollerance on the square of the error for the coordinate inversion. So 1E-6 may roughly translate to 1 mm which is a bit too lax for my tolerance. If 1E-8 or 1E-10 works as well then I'll set the parameter to that and push a new branch.

@lazersos
Copy link
Collaborator

OK here is the comparrision it seems the magic number is greater than 1.0E-10.

Image

Image

Image

Image

@lazersos lazersos linked a pull request Feb 25, 2025 that will close this issue
@kudav
Copy link
Collaborator Author

kudav commented Feb 26, 2025

So there are minor but noticeable differences in the fast ion distribution between the tolerance at 1e-6, 1e-8 and 1e-9. No grid points with B_R<2e-5 appear for any of these tolerance, while 30 are found for 1e-12.
Image

There stil exist discontinuities in the derivatives of B_R though (which affect the drifts), and these seem to be relatively independent of the tolerance used:

Image

@lazersos
Copy link
Collaborator

lazersos commented Feb 26, 2025

The discontinuity at the edge is real, at least from the theoretical standpoint. VMEC assumes a surface current at the boundary which guaruntees that it is a flux surface. Essentially this surface current is the representation of the external magnetic field which gives rise to the vacuum component of the field inside the equilbrium. Such an effect is a natural outcome of the VMEC model. One could argue that a free boundary VMEC equilibrium at zero beta which exactly matches a flux surface would have no such feature. The little point in the lower left of the equilbrium is a bit worrying.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants