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

[FIX] Gauss-Legendre poles and weights in profile_functions.f #41

Merged
merged 8 commits into from
Feb 13, 2024

Conversation

jonathanschilling
Copy link
Collaborator

... are only parsed with single-precision
if specified without explicit double-precision suffix in the source code.

I found out (the hard way) that the constants used for Gauss-Legendre quadrature in profile_functions.f are only parsed with single-precision accuracy from the source file. This PR adds the _rprec suffixes to the constants in order to make Fortran aware of the available double-precision accuracy. This helps in comparisons with implementations in other languages.
Also, trailing whitespace is removed in this source code file in order to clean up future diffs. Sorry for the noise. The relevant changes are on lines 69 - 90.

@cianciosa
Copy link
Collaborator

It looks like the test failures here are being caused by the tolerance being set to low. Some about of deviation is expected due to parallel reductions. Setting the tolarance values in https://github.com/ORNL-Fusion/PARVMEC/blob/master/Testing/tests/free_boundary_test/CMakeLists.txt should fix that.

You can ignore the test failure in siesta_final_phipf_test since that happens randomly due to randomly sampling the value. Rerunning that test using makes it pass. I should make that test more robust but I just haven't gotten around to it.

@jonathanschilling
Copy link
Collaborator Author

jonathanschilling commented Oct 6, 2023

Actually the output quantities in VMEC are expected to change on the order of ca. 1e-8 in case the two_power profile is used for pcurr_type (as in the test.vmec case). Not sure if relaxing the tolerances is the right way or if we should rather re-generate the reference data.

[Edit] I just saw that those test merely compare the parallel vs. the serial implementation (?). In that case, I agree that relaxing the tolerances is probably ok and I can go ahead and figure out the values that make the tests pass again.

@cianciosa
Copy link
Collaborator

In this case the reference data is a comparison between serial and parallel runs. We should consider using known reference cases going forward in the future.

@cianciosa cianciosa force-pushed the fix_profile_functions_gl_constants branch from b9dfcea to 15bb761 Compare November 16, 2023 17:41
@cianciosa cianciosa force-pushed the fix_profile_functions_gl_constants branch from a0acb03 to 9765d49 Compare February 13, 2024 19:45
@cianciosa cianciosa merged commit e4928d4 into master_dev Feb 13, 2024
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants