Take a look, here are some important parameters which can improve parallelised calculation!

Queries about input and output files, running specific calculations, etc.


Moderators: Global Moderator, Moderator

Post Reply
Message
Author
vasp16888
Newbie
Newbie
Posts: 44
Joined: Fri Apr 23, 2010 3:09 am

Take a look, here are some important parameters which can improve parallelised calculation!

#1 Post by vasp16888 » Mon May 03, 2010 10:51 pm

Dear all vasp users:
Some time ago, in order to improve the efficiency of parallelised calculation on large system, I posted a thread about "How to improve parallelised calculation ?" After several communications between Danny, Alex and me, they suggested me to do some test on parameter NPAR, NSIM, LPLANE.
The testing example is Tb0.25Dy0.75Fe2 which have 2 Tb atoms, 6 Dy atoms and 16 Fe atoms in unit cell, kpoints is auto, 7*7*7, etc. I used 2 nodes(24 cores, which means each node has 12 cores), the network card is Infiniband (20GB/S).
If I take the default value for NPAR, NSIM, LPLANE, I approximately use 3000 seconds.
I tested NPAR = 1, 2, 4, 6, 8, 12, 24, each of NPAR corresponds to NSIM = 1, 2, 4, 6, 8, 12, 24 which means 7*7 cases, here are my calculated result:
===========================================
NSIM\NPAR NPAR=1 NPAR=2 NPAR=4 NPAR=6 NPAR=8 NPAR=12 NPAR=24
NSIM=1 10712.798 1533.092 2302.704 2220.371 2470.454 2834.889 2941.860
NSIM=2 10889.813 1940.413 2429.192 2239.376 2515.769 2891.733 2948.944
NSIM=4 10622.640 1917.540 2221.515 2385.977 2502.756 2929.271 3033.390
NSIM=6 10836.125 2111.760 2393.558 2395.906 2623.324 2913.558 2990.683
NSIM=8 11168.838 2107.752 2378.309 2296.263 2668.595 2934.627 3109.094
NSIM=12 11148.837 2056.108 2279.254 2339.886 2624.820 2934.643 3207.204
NSIM=24 10512.837 1967.503 2253.869 2260.493 2626.288 3016.769 3725.165
===========================================
It seems like NPAR = 2, NSIM = 1 is fastest. The increase of NSIM will always increase the calculation time, increaing NPAR should be careful, because NPAR should be different according to your specific cases.
I also tested LPLANE = .TRUE. which save approximately 50% calculation time further.

My questions are as follows:
(1)In vasp userguide, it says increase NSIM should improve the performance, but here the data is not the case, so which one is correct ?
(2)Since NPAR = 2, NSIM = 1 is fastest, I think maybe calculating one band in one node is most optimized, so I am expecting a further improvement when I use 3 nodes which I set NPAR = 3, NSIM = 1, but even though, the calculation time is 1515 seconds, only 18 second faster. I don't know why ?

I hope my calculation result will be usefull for all vasp users, I am looking forward to everybody's reply to my questions.
Thanks:)
Hui





<span class='smallblacktext'>[ Edited ]</span>
Last edited by vasp16888 on Mon May 03, 2010 10:51 pm, edited 1 time in total.
[align=center]
AB INITIO STUDY OF MAGNETIC MATERIALS
[/align]

alex
Hero Member
Hero Member
Posts: 586
Joined: Tue Nov 16, 2004 2:21 pm
License Nr.: 5-67
Location: Germany

Take a look, here are some important parameters which can improve parallelised calculation!

#2 Post by alex » Tue May 04, 2010 6:47 am

1) benchmark results only apply to your very special case you just tested. Similar systems behave similar. So there is no right and wrong, just better or worse.
3) NPAR decreases communication and increases the numerics on one core. Probably you have somehow a double minimum.

alex
Last edited by alex on Tue May 04, 2010 6:47 am, edited 1 time in total.

Danny
Full Member
Full Member
Posts: 201
Joined: Thu Nov 02, 2006 4:35 pm
License Nr.: 5-532
Location: Ghent, Belgium
Contact:

Take a look, here are some important parameters which can improve parallelised calculation!

#3 Post by Danny » Tue May 04, 2010 9:17 am

In addition, bear in mind that your problem (36atoms) might become small for a large number of cores (3nodes=36 cores).
If you have a look at the scalling of VASP wrt the number of cores/nodes used you'll see it show a linear behavior(like we whish) but at some point it starts to top of, and you get no further improvement.

In your case test for 1 node, and normally your optimum should be at NPAR=1, NSIM=1
(again a grid, but you can make it smaller NPAR= 1,2,4,6,12; NSIM=1,2,4,6)
So the fact that you find only 18 seconds difference for 3 nodes might be because you reached your best performance for that system.

Keep in mind that this behavior differs from machine to machine, and probably setup to setup.

Danny
Last edited by Danny on Tue May 04, 2010 9:17 am, edited 1 time in total.

vasp16888
Newbie
Newbie
Posts: 44
Joined: Fri Apr 23, 2010 3:09 am

Take a look, here are some important parameters which can improve parallelised calculation!

#4 Post by vasp16888 » Tue May 04, 2010 6:11 pm

[quote="alex"]1) benchmark results only apply to your very special case you just tested. Similar systems behave similar. So there is no right and wrong, just better or worse.
3) NPAR decreases communication and increases the numerics on one core. Probably you have somehow a double minimum.

alex[/quote]


Hi Alex, thanks for your reply.
You said:NPAR decreases communication and increases the numerics on one core. Probably you have somehow a double minimum.

Are you saying we should find a balance between decreasing communication and increasing the numerics on one core ? Or some other thing ?
About NSIM, what do you think the role it playing in the calculation ? ( mannual says NSIM bands are optimized at the same time, it means if NSIM is bigger, it should be faster, but my result is not the case. Is this only about the special case?)
please make it clearer, thanks:)
Last edited by vasp16888 on Tue May 04, 2010 6:11 pm, edited 1 time in total.
[align=center]
AB INITIO STUDY OF MAGNETIC MATERIALS
[/align]

vasp16888
Newbie
Newbie
Posts: 44
Joined: Fri Apr 23, 2010 3:09 am

Take a look, here are some important parameters which can improve parallelised calculation!

#5 Post by vasp16888 » Tue May 04, 2010 6:26 pm

[quote author=36 cores).
If you have a look at the scalling of VASP wrt the number of cores/nodes used you'll see it show a linear behavior(like we whish) but at some point it starts to top of, and you get no further improvement.

In your case test for 1 node, and normally your optimum should be at NPAR=1, NSIM=1
(again a grid, but you can make it smaller NPAR= 1,2,4,6,12; NSIM=1,2,4,6)
So the fact that you find only 18 seconds difference for 3 nodes might be because you reached your best performance for that system.

Keep in mind that this behavior differs from machine to machine, and probably setup to setup.

Danny[/quote]My question are still ambiguous:[/color](1)What is the role of NSIM playing in the calculation ? (mannual says NSIM bands are optimized at the same time, it should be faster when NSIM is bigger, but my result is not the case)

(2)like Alex said, NPAR decreases the communication and increases the numerics in each cores. But how can we find the best NPAR without testing all the NPAR or a given system ?
(because we don't need to test all NPAR for every large system.)
My understanding, I used wien2k for sometime, and I can get the approximate number of plane waves during the init_lapw, so I can make a approximate guess about how many cores I need, and kpoints parallel or mpi parallel etc.

So, please tell me your thoughts about the above 2 questions. Thanks in advance:)
Last edited by vasp16888 on Tue May 04, 2010 6:26 pm, edited 1 time in total.
[align=center]
AB INITIO STUDY OF MAGNETIC MATERIALS
[/align]

Danny
Full Member
Full Member
Posts: 201
Joined: Thu Nov 02, 2006 4:35 pm
License Nr.: 5-532
Location: Ghent, Belgium
Contact:

Take a look, here are some important parameters which can improve parallelised calculation!

#6 Post by Danny » Wed May 05, 2010 8:35 am

wrt NPAR: the communication in VASP is pretty constant for different calculations, so if you benchmark for one decent system (the testjob you just used) you know how it behaves for all calculations (with some exceptions: eg very small jobs). Your current setting fixes the communication probably in such a way that mayor communication only is within a node, and reduces the communication between nodes. In general the latter is slower, so your choice of NPAR=#nodes reduces this last one=> increase in performance.

The NSIM is as far as I understand more connected to matrix operations, which are done outside VASP (mkl, etc takes care of these) I would guess it also depends on the CACHE of your system (and the blocksize you set in your makefile.) So there might be systems where you don't gain anything through setting NSIM higher. At least VASP seems to behave quite consistent on your system, so you have a good startingpoint to run jobs.

Danny
Last edited by Danny on Wed May 05, 2010 8:35 am, edited 1 time in total.

vasp16888
Newbie
Newbie
Posts: 44
Joined: Fri Apr 23, 2010 3:09 am

Take a look, here are some important parameters which can improve parallelised calculation!

#7 Post by vasp16888 » Thu May 06, 2010 10:28 pm

[quote author=#nodes reduces this last one=> increase in performance.

The NSIM is as far as I understand more connected to matrix operations, which are done outside VASP (mkl, etc takes care of these) I would guess it also depends on the CACHE of your system (and the blocksize you set in your makefile.) So there might be systems where you don't gain anything through setting NSIM higher. At least VASP seems to behave quite consistent on your system, so you have a good startingpoint to run jobs.

Danny[/quote]


Hi Danny, my CACHE is 512 KB, memory is 16 GB/node, is this big enough ?
I mean, if I wanna deal with 100 atoms by vasp, how big is the cache will be reasonable?
Thanks:)
Last edited by vasp16888 on Thu May 06, 2010 10:28 pm, edited 1 time in total.
[align=center]
AB INITIO STUDY OF MAGNETIC MATERIALS
[/align]

Post Reply