[Pw_forum] Why does Ewald sum calculation need so much RAM

[Paolo Giannozzi]

I cannot see any evidence from your files that the Ewald term
is responsible for the large RAM and CPU requirements. A lot
of time is spent in the initialization phase ("phq_init"), mostly
in subroutines "drho" and "dvanqq". These calculates terms
required by the PAW and USPP formalism. The rest of the time
is spent in computing the linear response ("phqscf") by solving
a linear system ("solve_linter"), but again, most of the time is
spent in the calculation of PAW/US specific terms ("addusdbec",
"addusddens").

Some improvement could be achieved with a better chosen
parallelization: the number of "pools" should be a divisor of
the number of k-points (so 8 pools is not a good choice with
12 k-points). Note however that
- some calculations cannot be parallelized over k-points
- some other calculations (especially PAW/USPP specific
   stuff) are not parallelized at all
so there is a limit to what parallelization can achieve here
without some work on the code. The phonon code is not
yet ready to be run on very large systems (hundreds of
atoms), and for USPP and PAW, not even on not-so-large
systems. Promises of better scalability have yet to
materialize.

I also notice a disproportionately large cutoff (70Ry).
One of the advantages of PAW/USPP over Norm
Conserving PP is to allow the usage of a much smaller
cutoff. For a Si-Li system, 70Ry seems to me a lot
(unless you are using all-electron Li: with a 1-el Li,
  you could run with norm-conserving PP at a
smaller cutoff).

About the repeated initialization: this is something that
shouldn't be difficult to fix, as long as you run on the
same machine and can read previously written files.
It requires however some modifications of the code
and some understanding of what is going on. The
PAW/USPP formalism is very complex for phonon
calculations and requires the calculation of a
disproportionate number of terms.

P.

On Jul 18, 2012, at 16:12 , Thomas Gruber wrote:

>
>> Message-ID: <1342541146.16360.64.camel at fe12lx.fisica.uniud.it>
>> are we talking about RAM, or about CPU, or both, and in which  
>> subroutine exactly?
> To save CPU time it gets a RAM problem because this is the limiting  
> factor.
>> it was done in this way because the Ewald part has never been a  
>> serious problem for anybody until now.
> It looks like it is in my case.
>> sure there is, but you need to locate exactly where too much cpu  
>> time is spent and where too much RAM is required. Then, we can  
>> discuss about possible solutions. P.
> I attached a graphic of the RAM usage for an "-npool 8" calculation  
> and added the output file named after the time stamp from the  
> graphic. I can't tell you more than it takes almost three days to  
> print the line " PHONON       :     2d   18h22m CPU        2d    
> 21h55m WALL" and it uses 4 times more RAM than in the scf  
> iterations afterward. Unfortunately the scaling is not very good:
>>   With 16 cores it takes "3d
>> 6h" and on 32 cores it takes "2d 16h" and I have only 5 days on that
>> cluster for one job.
> What is the program doing during this time and can I do it only  
> once and give it as input for the other splited phonon calculations?
> I tried to use the "-npool" flag, but I can't use it because my RAM  
> is to "small" (64GB+, some nodes have more). To save time I like to  
> put more representations in one job, but because of this time  
> demanding step I get over the time limit of 5 days. So i have to  
> repeat this calculations 450 times instead of once.
>
> Thanks in advance.
>
> -- 
> Thomas Gruber
> Institut für Theoretische Physik
> TU Bergakademie Freiberg
> Leipziger Str. 23, 09599 Freiberg, Germany
> Tel: +49 (0)3731 392006
> Email:thomas.gruber at physik.tu-freiberg.de
>
> <1.out><10.out><4070.out><5360.out><Li12Si7.0.0.1.1.111.log.png>______ 
> _________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum

---
Paolo Giannozzi, Dept of Chemistry&Physics&Environment,
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222