[QE-users] Huge memory requirements for a scf calculation of a system consisting with 300+ atoms.
Nicola Marzari
nicola.marzari at epfl.ch
Wed May 27 15:26:09 CEST 2020
Fully agree with this! If I can add, using the Baldereschi point (or, to
make it simple, 1/4 1/4/ 1/4 in crystal coordinates), and nosym=.true.
allows you to do a calculation with one k-point that is almost as
accurate as using a 2x2x2 shifted monkhorst pack mesh (i.e. 2 2 2 1 1
1), at a cost that is only twice as large as a Gamma only calculation.
If a metal, use 0.03 Ry of smearing (either m-p or m-v), and indeed you
are good to go for a fast but quite accurate relaxation.
nicola
On 27/05/2020 13:39, Giuseppe Mattioli wrote:
>
> 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>
>
> _______________________________________________
> 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
--
----------------------------------------------------------------------
Prof Nicola Marzari, Chair of Theory and Simulation of Materials, EPFL
Director, National Centre for Competence in Research NCCR MARVEL, EPFL
http://theossrv1.epfl.ch/Main/Contact http://nccr-marvel.ch/en/project
More information about the users
mailing list