-
Notifications
You must be signed in to change notification settings - Fork 11
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
Problems to call spfft_multi_transform_* routines #58
Comments
I've looked into the issue and found at least one bug in the C and Fortran interface of the multi-transform functions. Some general notes for your use case: |
Thank you. I will try it later even if it may not lead to an acceleration. Regarding our use case, I was attempting to accelerate local FFTs first. Several 1D and all 2D FFTs will become obsolete in favor of distributed 3D FFTs and sparse FFTs. |
I have just tried it locally on CPU and the tests pass. |
Great, Thanks for reporting the issue! In case it helps, here are some details about the multi-transform implementation: I'll close this for now, but feel free to reopen it if there are still related problems. |
Dear developers,
I am currently attempting to use SpFFT (version 1.0.6) to offload FFTs to GPUs in a Fortran code (CP2K). In our code, there is the need to perform several FFTs at once, usually 1D and 2D FFTs which I map to 3D FFTs. I am able to employ the routines
spfft_transform_forward
andspfft_transform_backward
with something likeNow, I am migrating to the
spfft_multi_transform_*
routines. Currently, I am only trying the CPU version for testing. A boiled down version of my new code for the forward transform looks as followedLeakSanitizer:DEADLYSIGNAL
==358529==ERROR: LeakSanitizer: SEGV on unknown address 0x000000000060 (pc 0x0000037714d0 bp 0x7ffe17ffeba0 sp 0x7ffe17ffeb68 T0)
==358529==The signal is caused by a READ memory access.
==358529==Hint: address points to the zero page.
LeakSanitizer:DEADLYSIGNAL
==358530==ERROR: LeakSanitizer: SEGV on unknown address 0x000000000060 (pc 0x0000037714d0 bp 0x7ffcd8239f90 sp 0x7ffcd8239f58 T0)
==358530==The signal is caused by a READ memory access.
==358530==Hint: address points to the zero page.
#0 0x37714d0 in spfft::ExecutionHost::space_domain_data() /home/fstein/cp2k/cp2k/tools/toolchain/build/SpFFT-1.0.6/src/execution/execution_host.cpp:356
#1 0x376a6bc in spfft::TransformInternal::space_domain_data(SpfftProcessingUnitType) /home/fstein/cp2k/cp2k/tools/toolchain/build/SpFFT-1.0.6/src/spfft/transform_internal.cpp:355
#2 0x376b45b in spfft::MultiTransformInternalspfft::Transform::forward(int, spfft::Transform*, SpfftProcessingUnitType const*, double* const*, SpfftScalingType const*) /home/fstein/cp2k/cp2k/tools/toolchain/build/SpFFT-1.0.6/src/spfft/multi_transform_internal.hpp:56
#3 0x376b45b in spfft::multi_transform_forward(int, spfft::Transform*, SpfftProcessingUnitType const*, double* const*, SpfftScalingType const*) /home/fstein/cp2k/cp2k/tools/toolchain/build/SpFFT-1.0.6/src/spfft/multi_transform.cpp:40
#4 0x376b45b in spfft_multi_transform_forward /home/fstein/cp2k/cp2k/tools/toolchain/build/SpFFT-1.0.6/src/spfft/multi_transform.cpp:72
#5 0x30a8f89 in __spfft_lib_MOD_spfft_2d /home/fstein/cp2k/cp2k/src/pw/fft/spfft_lib.F:317
#6 0x30a22b2 in __fft_lib_MOD_fft_2d /home/fstein/cp2k/cp2k/src/pw/fft/fft_lib.F:355
#7 0x2f6bd0f in __fft_tools_MOD_fft3d_ps /home/fstein/cp2k/cp2k/src/pw/fft_tools.F:801
#8 0x2fdc7da in __pw_methods_MOD_fft_wrap_pw1pw2_r3d_c1d_rs_gs /home/fstein/cp2k/cp2k/src/pw/pw_methods.F:1395
#9 0xb03c39 in __qs_collocate_density_MOD_calculate_rho_core_c1d_gs /home/fstein/cp2k/cp2k/src/qs_collocate_density.F:916
#10 0x17dc6e7 in __qs_update_s_mstruct_MOD_qs_env_update_s_mstruct /home/fstein/cp2k/cp2k/src/qs_update_s_mstruct.F:104
#11 0xa68b99 in qs_energies_init_hamiltonians /home/fstein/cp2k/cp2k/src/qs_energy_init.F:316
#12 0xa694e0 in __qs_energy_init_MOD_qs_energies_init /home/fstein/cp2k/cp2k/src/qs_energy_init.F:111
#13 0xb9968d in __qs_energy_MOD_qs_energies /home/fstein/cp2k/cp2k/src/qs_energy.F:95
#14 0x1e35a86 in qs_forces /home/fstein/cp2k/cp2k/src/qs_force.F:200
#15 0x1e39bb1 in __qs_force_MOD_qs_calc_energy_force /home/fstein/cp2k/cp2k/src/qs_force.F:112
#16 0xfbe5df in __force_env_methods_MOD_force_env_calc_energy_force /home/fstein/cp2k/cp2k/src/force_env_methods.F:259
#17 0xb3b328 in __f77_interface_MOD_calc_energy_force /home/fstein/cp2k/cp2k/src/f77_interface.F:1355
#18 0x6ae3d0 in cp2k_calc_energy_force /home/fstein/cp2k/cp2k/src/start/libcp2k.F:377
#19 0x6ace7d in main /home/fstein/cp2k/cp2k/src/start/libcp2k_unittest.c:79
#20 0x7fab4927cd8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#21 0x7fab4927ce3f in __libc_start_main_impl ../csu/libc-start.c:392
#22 0x6ac954 in _start (/home/fstein/cp2k/cp2k/exe/local/libcp2k_unittest.pdbg+0x6ac954)```
I am running with two MPI ranks and a single thread per rank.
The actual code is found at here for the transformation creation and here for the actual transformation. The preceding commit where I used a loop over
spfft_transform_forward
worked in the CPU version.I have also tried variants of the calls to the transformation routine in which I indexed the first element directly (
C_LOC(pointer(0))
instead ofC_LOC(pointer)
) or where I dropped theC_LOC
function where possible. I haven even added my own interface to the C routine where I used arrays instead of plainTYPE(C_PTR)
.Do you have an idea what is going on or do you need more information?
The text was updated successfully, but these errors were encountered: