Dear Conor, Myrta, Andrea and Daniele,
Can you comment on the optimization of the CPU time in a GW parallel run? For example, is there a way to tune the GW part of the run, for large systems, w.r.t the variables in the input? In particular, how to run efficiently the GW run in a parallel machine for a big system (containing say 100 atoms).
Sincerely,
Bhagawan Sahu, Researcher
Microelectronics Research Center
University of Texas, Austin TX 78758
Parallel GW run
Moderators: Davide Sangalli, andrea.ferretti, myrta gruning, andrea marini, Daniele Varsano, Conor Hogan, Nicola Spallanzani
- myrta gruning
- Posts: 242
- Joined: Tue Mar 17, 2009 11:38 am
- Contact:
Re: Parallel GW run
Dear Sahu
Just from my experience (on not so big systems though) Yambo works quite good in parallel. The parallelization is such that the work load is well distributed among all the nodes irrespective from the input variables. You can check this from the runtime log files (l_*), that are reporting the elapsed/expected time for a given operation for each node. With big systems you usually have to worry about the memory requests that can easily be quite large, so probably you need to play e.g. with FFTGvecs. Anyway I would suggest to try some smaller systems before the big guy to get the "feeling" [as I said looking at the runtime logs is a good way to see how the program run on the machine, to spot problems (e.g. unbalanced work load, too much memory requested), get an idea whether a system is feasible etc.].
Cheers,
m
Just from my experience (on not so big systems though) Yambo works quite good in parallel. The parallelization is such that the work load is well distributed among all the nodes irrespective from the input variables. You can check this from the runtime log files (l_*), that are reporting the elapsed/expected time for a given operation for each node. With big systems you usually have to worry about the memory requests that can easily be quite large, so probably you need to play e.g. with FFTGvecs. Anyway I would suggest to try some smaller systems before the big guy to get the "feeling" [as I said looking at the runtime logs is a good way to see how the program run on the machine, to spot problems (e.g. unbalanced work load, too much memory requested), get an idea whether a system is feasible etc.].
Cheers,
m
Dr Myrta Grüning
School of Mathematics and Physics
Queen's University Belfast - Northern Ireland
http://www.researcherid.com/rid/B-1515-2009
School of Mathematics and Physics
Queen's University Belfast - Northern Ireland
http://www.researcherid.com/rid/B-1515-2009