Slow calculations with both ESPRESSO and VASP?

[nsolmt]

Does anyone have ideas why calculations would be slow? For 30 atoms, the rate is 1 structure per 6 hours, which means it takes weeks to get through 2 generations.

T0_Physics_VASP creates 4 structures per hour (which is slow for that time of calculation, correct?). 

I get "PROBLEM_read_CONTCAR" in the log every time it tries a new structure, as follows:

PROBLEM_read_CONTCAR 22

ans = 0

/global/home/nsolomat/USPEX-9.3.9-2013/Tests/T0_Physics_VASP/CalcFold1

Structure22 step1 at CalcFold1

Structure22 step2 at CalcFold1

Structure22 step3 at CalcFold1

Structure22 step4 at CalcFold1

fingerprint CalcTime = 3.1449 sec

I also get these errors in Calcfold1/log (not sure if they're related):

 WARNING: small aliasing (wrap around) errors must be expected

 FFT: planning ...

 WAVECAR not read

I use 4 nodes with 4 processors per node.

Anyone have suggestions?

[Qiang Zhu]

I think this issue is pretty much related to your set up for abinitio calculations. First of all, the computational cost increases very much with system size N (almost ~O(N^3) relations). T0_physics_vasp is an example of 4 Si atoms per cell, but here you have 30 atoms !!!!

Here I just list a few possible solutions.

1) to check if the vasp is correctly compiled in the most optimum efficiency. (compilation tags and Math Libraries)

2) If your system is insulator, you do not need to use very dense Kpoints mesh in your calculation (this is a crucial factor for plane wave code like VASP). An economical way is to decrease the Kpoint resolution.

%Resolution for KPOINTS - one number per step or just one number in total)
% KresolStart
0.16 0.12 0.10 0.09
%  Kresolend

And also try to decrease the ENCUT for INCAR_* under Specific, but make sure that the precision is good enough to describe the relative energetics.

Best regards.

Qiang

[nsolmt]

Hmm yes, but it's extremely slow - 30-atom structure would take months (if not a year) to complete. That seems unreasonable. 

1) This might be the problem, but I'm not sure how to test if vasp is correctly compiled. Just as a note, Espresso runs just as slow.

2) I've tried reducing k-point resolution, encut, space group search, tried a variety of reasonable minimum ion-distances (between 0.8 to 1.2), minvector, etc.

For uspex+espresso, I tried using lower mixing_beta's, larger smearing, and larger conv_thr just to see if that would speed it up, but the calculations did not speed up much (if at all). This seemed to imply that there's a problem beyond the input parameters.

Also switched from octave to matlab, which didn't help.

I appreciate your response very much! 

[Qiang Zhu]

In USPEX caculations, 99% of computing time are spent on ab-initio calculations. Firstly, you should have a clear idea to figure out which factor leads to inefficiency.

1> If you have problem in generating structures, that is the problem of USPEX. For this, you can try to modify INPUT parameters like (space group search, minimum ion-distances, switch from octave to matlab, etc).

2> If the structural relaxation just takes a long time, it the problem of ab-initio calculation. You need to take a single structure, any one from results1/non_optimized_structures. And try to follow the step of USPEX, relax it manually (with INCAR_1, INCAR_2, INCAR_3, etc). Then you can estimate the time for a single structural relaxation and see if you can improve the efficiency by recompiling vasp and modifying the VASP INPUTs (INCAR, POTCAR, KPOINTS.) USPEX only provides POSCAR.

3> Remember each USPEX calculation might go through thousands structural relaxations. Now you can estimate how much computing time you need. For 30 atoms structural search with VASP or QE, it is not really a good idea to use only 16 processors.  You do need to find a supercomputer which allows you to use hundreds of processors. In this case you submit multiple jobs simultaneously to speed up the calculation.

http://uspex.stonybrook.edu/Manual/module_4_8.htm?ms=ATA=&mw=MjQw&st=MA==&sct=MA==
http://uspex.stonybrook.edu/Manual/module_5_5.htm?ms=ATA=&mw=MjQw&st=MA==&sct=NTg=

*variable numParallelCalcs

Meaning: specifies how many structure relaxations you want to run in parallel (more precisely, up to how many jobs you want to be in the queue at each moment – of course, if the machine is fully loaded, you will have to wait, only if the machine is sufficiently free they will be executed at the same time).

 

Default: 1

 

Format:

10   :  numParallelCalcs

Best,
Qiang

--
You received this message because you are subscribed to the Google Groups "USPEX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uspex+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Qiang Zhu (Ph.D)
ESS 365
Department of Geosciences
Stony Brook University
NY 11794-2100

USPEX download Page: http://uspex.stonybrook.edu/

[nsolmt]

Thank you for the quick response!

1) Uspex is not the problem - it creates structures very quickly.

2) An ab initio calculation (without Uspex) of a tabulated 30-atom cell takes ~6-12 hours (20-atom cell takes 2-4 hours), which is a problem.

3) I parallelized to 20, but it had no effect on the speed. There must be something wrong with my supercomputer's library(ies). 

I'll definitely look into your suggestions. Thank you very much for your assistance! I'll update this post with the solution when I find it.