[QE-users] Huge memory requirements for a scf calculation of a system consisting with 300+ atoms.

[Giuseppe Mattioli]

Dear all
Just to add a bit of personal experience that might be useful to  
others. Let's admit that many k-points are necessary to provide a good  
description of the electronic properties of a given system, this is  
generally true in the case of metal systems. This fact might not  
extend to the potential, and very tiny differences might be found in  
final structures optimized by using a coarser sampling of the  
Brillouin zone. In the huge cell shared by Hongyi Zhao, I would start  
a geometry optimization from a gamma-only simulation and then I would  
check if forces on ions were low enough with a 2x2x1 mesh. If this was  
not the case, I would fully optimize the system with the new mesh and  
go a step ahead, and so on up to a decent convergence of the  
potential. Then I would perform nscf calculations with increasing  
numbers of k points followed by, e.g., dos.x post processing runs, to  
check the convergence of the density of states (be careful, because  
AFAIK nscf runs overwrite the results of the scf run). Of course, all  
of this depends on the specific purpose of the calculation, but in my  
past experience with molecules on metal surfaces this strategy saves a  
lot of time and resources.
HTH
Giuseppe

Quoting Sebastian Hütter <sebastian.huetter at ovgu.de>:

> Hi,
>
> This may be a stupid question, but...
>
>>      Estimated static dynamical RAM per process >       3.32 GB
>>      Estimated max dynamical RAM per process >      10.52 GB
>>      Estimated total dynamical RAM >     462.96 GB
>
> ... is this not expected behavior? I'm not super experienced, so I  
> just assumed it was.
>
> Your numbers pretty much match what I see in terms of "RAM per Cell  
> volume" in metals with non-symmetric unit cells using PAW pseudos,  
> if not less. Random example: 126 atoms, 63 k-points, ~1000 bands,  
> 250³ dense grid FFT gives ~10GB per rank, for a total of 680GB with  
> 64 ranks. I actually plan node requests for our cluster based  
> entirely on memory required, probably wasting CPU time along the way  
> (4N*16C in the example above).
>
> Reasonable ke and charge cutoffs seem to blow up the memory  
> requirements a lot. Of course multiplied by the number of bands...
>
>
> Best,
>
> Sebastian
>
>
> --
> M.Sc. Sebastian Hütter
> Otto-von-Guericke University Magdeburg
> Institute of Materials and Joining Technology
> _______________________________________________
> Quantum ESPRESSO is supported by MaX (www.max-centre.eu/quantum-espresso)
> users mailing list users at lists.quantum-espresso.org
> https://lists.quantum-espresso.org/mailman/listinfo/users



GIUSEPPE MATTIOLI
CNR - ISTITUTO DI STRUTTURA DELLA MATERIA
Via Salaria Km 29,300 - C.P. 10
I-00015 - Monterotondo Scalo (RM)
Mob (*preferred*) +39 373 7305625
Tel + 39 06 90672342 - Fax +39 06 90672316
E-mail: <giuseppe.mattioli at ism.cnr.it>