Dear Abinit community,
I wonder how big a system ABINIT can handle for both ground state and perturbations. Can you give me some tips plus parallelization strategies for big systems (> 50 atoms)?
Thanks,
Viet-Anh
Dear Abinit community,
I wonder how big a system ABINIT can handle for both ground state and perturbations. Can you give me some tips plus parallelization strategies for big systems (> 50 atoms)?
Thanks,
Viet-Anh
Hi Viet-Anh,
I recommend the documentation related to parallelism: Parallelism - abinit . Regarding the scalability of Abinit, one of the possible reads might be this Parallel eigensolvers in plane-wave Density Functional Theory - ScienceDirect.
For any specific questions don’t hesitate to ask.
Bogdan
Hi Bogdan,
Thank you so much for your help. Honestly, my system has 59 atoms and ~ 280 occupied bands. I’d like to do response function for this system. All what I knew for parallelization is
For ground-state, ABINIT provides many levels parallelization including k-points, bands, G-vectors,… However when I tried to manually setup parallelization, I didn’t see the self-consistent calculations go fast. I wonder if you have experienced with similar big system?
For response functions calculations, the G-parallelization is not available. Can you suggest some tips and setups for these calculations.
Thanks,
Viet-Anh
Hi Viet-Anh,
The parallelization layers (from paral_kgb) indicate the precedence of the internal iterative loops, so in principle parallelization over k-points should go perfectly well, and this was my experience as well overall. Now there might be several reasons why you didn’t experience a speed-up:
a) there is simply an imbalance of k-point/core, fft/core or even nband/core. I would recommend maximize first the parallelization over k-points, as in your number of cores to be on par with the number of k-points and follow the achieved speed-up. the progressively parallelize over fft and bands. Please keep in mind the recommendation under paral_kgb documentation related to the number of cores that you use.
b) based on your relatively small system, you already achieved the maximum speed-up (as in you already entered a saturation zone where it starts to take more for cores to communicate with each other than to actually do computations, or there are some internal calculations bottle necks etc.). I am not personally an expert in this but this is my best guess here.
c) simply your Abinit compilation is faulty and needs testing in the local environment to understand if it behaves as expected, before proceeding further. A quick check is to run one of the parallelization internal tests of Abinit.
When it comes to response calculations, the simplest case is the atomic perturbations calculations which in themselves have yet another keyword called paral_rf. Otherwise you can simply split manually calculations into independent perturbations according to direction/atom/type of perturbation based on rfdir, rfatpol, rfphon**/**rfelfd/rfstrs. Admitelly a little more tedious manually but easily overcomed by a little scripting effort. Abipy can in fact help with this part greatly in setting up.
Let me know if this covered your questions!
Bogdan
Hi Bogdan,
Thank you so much for your enthusiasm. Yes, I think these might be the best tips I can have. I’ll try to follow these and see if I’m able to get over the bottleneck.
Thanks,
Viet-Anh