BEAMS3D not producing correct results with PPPL GCC #109
Comments
|
Looks like the GCC one is not calling "Trajectory Calculation". Here is the screen output for the GCC executable. And from the Intel executable. |
|
@zhucaoxiang This is an odd behavior. For reference I usually debug on my Mac with GCC and OpenMPI. For production runs I'm usually on the MPCDF machines (or Cineca) which compile with Intel. What branch was @pomphrey working on? |
|
@lazersos The |
|
@lazersos : |
|
Run the BENCHMARKS with make test_beams3d in the |
|
I can confirm this behavior for GCC on Mac when using the debugging options in the I can confirm that the issue seems to stem from the compiler option |
|
@lazersos Good find! So there might be a "division by zero" issue. The GCC compiler with extra debug flags catches it while the release flags just return unphysical results without errors. For Intel, there are some hidden default flags that make it work normally. |
|
The issue came from a grid helper variable that was declared to be n sized but should really have only been n-1 sized. As a result the nth position was never initialized. A second helper variable was also created with the same problem, only it's value was set to the inverse of the other variable. As a result in the nth position we got a divide by Nan. Now this never cause a direct issue in the code since we never referenced the array beyond the n-1 position. However the compiler flags for debug threw an error at that step. For most situations this never caused an issue because the array element which was Nan was never reference by the code. Except in the |
|
@lazersos The new commits fix the error, but still on the PPPL cluster, neither using GCC nor Intel will give correct numbers when running the |
|
@zhucaoxiang I can't replicate the error on Macports, MPCDF, or Cincea, so I can't fix that. The Intel results you posted look pretty close to correct. The GCC results look totally wrong, but a cursory glance at the |
|
@lazersos This doesn't make sense. I can reproduce your results on Eddy with the Intel compiler (all True). On PPPL, the Intel version only gives about half Trues. The GCC version just returns ridiculous numbers. I will test on my laptop and also over the GitHub server. |
|
@lazersos @pomphrey |
|
@zhucaoxiang OK so this looks like the issue may just be a roundoff error. The code is showing that the particle positions agree well after 1 time step but for some particles (probably deeply trapped) after 100 timesteps the position isn't correct. There are a few things which could be the issue. Can you upload the beams3d HDF5 file this run produced so I can take a look at it? This could be related to #110. |
|
@zhucaoxiang I suspect the issue is the |
|
@lazersos But both on my laptop and the PPPL cluster, I was using the "release" mode. BTW, I am surprised that two 50-Mb-files can be compressed to 6 Mb. |
|
@zhucaoxiang Yeah it's what I suspected. The magnetic field grid isn't being initialized correctly: The code also runs fine on Draco, Cobra, Raven, and Marconi. The file size is probably small because the grids have quite a bit of redundancy for this axisymmetric case. |
|
@lazersos On the PPPL cluster, I was using |
|
@lazersos Source of the discrepancy on my laptop is found. I changed the compiler flag from I am really surprised that |
|
@lazersos There might be something wrong with the sources. If you add one line before line 784 in |
This is for tracking a known issue reported by @pomphrey. Using the GCC version (gcc/9.3) on PPPL, the BEAMS3D executable is not able to produce correct results.
Here is a simple example. Running the
input.ORBITScase inBENCHMARKS/BEAMS3Dwith-N 1 -n 16. The GCC version somehow gives non-sense results. The Intel version gives close results (though not exactly the same).@lazersos Do you have any idea what causes this issue? You can find the makefile at https://github.com/PrincetonUniversity/STELLOPT/blob/develop/SHARE/make_pppl_gcc.inc
The text was updated successfully, but these errors were encountered: