Using Yambo in parallel - Revision history

Claudio: /* RPA response in parallel */

2020-12-15T10:58:08Z

RPA response in parallel

← Older revision		Revision as of 10:58, 15 December 2020
Line 127:		Line 127:

	Here, after the calculation of the independent particle linear response, a matrix inversion is performed to obtain the RPA response.		Here, after the calculation of the independent particle linear response, a matrix inversion is performed to obtain the RPA response.
	* After ~~initialisation~~ (see [[Initialization]] for info) generate the input file by issuing:		* After initialization (see [[Initialization]] for info) generate the input file by issuing:
	$ yambo -o c -V par -F yambo_RPA.in		$ yambo -o c -V par -F yambo_RPA.in
	edit some of the variables by setting		edit some of the variables by setting
Line 154:		Line 154:
	k parallelism over k-points		k parallelism over k-points

	Notice that ~~parellization~~ on c,v and k ~~reduce~~ the amount of memory in the calculation.		Notice that parellelization on c,v and k reduces the amount of memory in the calculation.

	==GW in parallel==		==GW in parallel==

Claudio: /* RPA response in parallel */

2020-12-15T10:56:48Z

RPA response in parallel

← Older revision		Revision as of 10:56, 15 December 2020
Line 146:		Line 146:
	X_all_q_nCPU_LinAlg_INV= 8 # [PARALLEL] CPUs for Linear Algebra		X_all_q_nCPU_LinAlg_INV= 8 # [PARALLEL] CPUs for Linear Algebra
	adding one extra MPI level of parallelism related to the distribution over q points.		adding one extra MPI level of parallelism related to the distribution over q points.

	Finally the different possible parallelism strategies for the dielectric constant are:		Finally the different possible parallelism strategies for the dielectric constant are:

Claudio: /* RPA response in parallel */

2020-12-15T10:56:03Z

RPA response in parallel

← Older revision		Revision as of 10:56, 15 December 2020
Line 146:		Line 146:
	X_all_q_nCPU_LinAlg_INV= 8 # [PARALLEL] CPUs for Linear Algebra		X_all_q_nCPU_LinAlg_INV= 8 # [PARALLEL] CPUs for Linear Algebra
	adding one extra MPI level of parallelism related to the distribution over q points.		adding one extra MPI level of parallelism related to the distribution over q points.
			Finally the different possible parallelism strategies for the dielectric constant are:

			g parallelism over G-vectors
			q parallelism over transferred momenta (q in Eq. above)
			c/v parallelism over conduction/valence bands
			k parallelism over k-points

			Notice that parellization on c,v and k reduce the amount of memory in the calculation.

	==GW in parallel==		==GW in parallel==

Claudio: /* RPA response in parallel */

2020-12-15T10:53:03Z

RPA response in parallel

← Older revision		Revision as of 10:53, 15 December 2020
Line 142:		Line 142:

	In case multiple or all q points need to be computed (as in GW calculations), the parallelism variables to be used, are:		In case multiple or all q points need to be computed (as in GW calculations), the parallelism variables to be used, are:
	X_all_q_ROLEs= "g q k c v" # [PARALLEL] CPUs roles (q,k,c,v)		X_all_q_ROLEs= "g q k c v" # [PARALLEL] CPUs roles (g,q,k,c,v)
	X_all_q_CPU= "1 2 1 4 1" # [PARALLEL] CPUs for each role		X_all_q_CPU= "1 2 1 4 1" # [PARALLEL] CPUs for each role
	X_all_q_nCPU_LinAlg_INV= 8 # [PARALLEL] CPUs for Linear Algebra		X_all_q_nCPU_LinAlg_INV= 8 # [PARALLEL] CPUs for Linear Algebra

Claudio: /* RPA response in parallel */

2020-12-15T10:52:37Z

RPA response in parallel

← Older revision		Revision as of 10:52, 15 December 2020
Line 142:		Line 142:

	In case multiple or all q points need to be computed (as in GW calculations), the parallelism variables to be used, are:		In case multiple or all q points need to be computed (as in GW calculations), the parallelism variables to be used, are:
	X_all_q_ROLEs= "q k c v" # [PARALLEL] CPUs roles (q,k,c,v)		X_all_q_ROLEs= "g q k c v" # [PARALLEL] CPUs roles (q,k,c,v)
	X_all_q_CPU= " 2 1 4 1" # [PARALLEL] CPUs for each role		X_all_q_CPU= "1 2 1 4 1" # [PARALLEL] CPUs for each role
	X_all_q_nCPU_LinAlg_INV= 8 # [PARALLEL] CPUs for Linear Algebra		X_all_q_nCPU_LinAlg_INV= 8 # [PARALLEL] CPUs for Linear Algebra
	adding one extra MPI level of parallelism related to the distribution over q points.		adding one extra MPI level of parallelism related to the distribution over q points.

Aferretti: /* Yambo Parallelism in a nutshell */

2020-01-23T10:20:46Z

Yambo Parallelism in a nutshell

← Older revision		Revision as of 10:20, 23 January 2020
Line 13:		Line 13:
	* '''MPI''' is particularly suited to distribute both memory and computation, and has a very efficient implementation in Yambo, which needs very few communications though may be prone to load unbalance (see [[GW_parallel_strategies\| GW parallel strategies]]).		* '''MPI''' is particularly suited to distribute both memory and computation, and has a very efficient implementation in Yambo, which needs very few communications though may be prone to load unbalance (see [[GW_parallel_strategies\| GW parallel strategies]]).
	* '''OpenMP''' instead works within a shared memory paradigm, meaning that multiple threads perform computation in parallel on the same data in memory (no memory replica, at least in principle).		* '''OpenMP''' instead works within a shared memory paradigm, meaning that multiple threads perform computation in parallel on the same data in memory (no memory replica, at least in principle).
			* Concerning '''Yambo''', tend to use MPI parallelism as much as possible (i.e. as much as memory allows), then resort to OpenMP parallelism in order not to increase memory usage any further while exploiting more cores and computing power.
	* '''GPU''' support is extremely efficient in Yambo, meaning that when you are running on GPU accelerated machines it is always a good idea to exploit the GPUs. In general, one needs to set 1 MPI task for each available GPU card, also including OpenMP threads to fully exploit the capabilities of the host. While a very relevant speed up can be achieved, device memory (eg 12, 16, 32 GB on currently available devices) may become a problem and needs to be controlled (eg increasing the number of required nodes and further distributing data across them).		* '''GPU''' support is extremely efficient in Yambo, meaning that when you are running on GPU accelerated machines it is always a good idea to exploit the GPUs. In general, one needs to set 1 MPI task for each available GPU card, also including OpenMP threads to fully exploit the capabilities of the host. While a very relevant speed up can be achieved, device memory (eg 12, 16, 32 GB on currently available devices) may become a problem and needs to be controlled (eg increasing the number of required nodes and further distributing data across them).
	* Concerning '''Yambo''', tend to use MPI parallelism as much as possible (i.e. as much as memory allows), then resort to OpenMP parallelism in order not to increase memory usage any further while exploiting more cores and computing power.
	* The number of '''MPI tasks''' and '''OpenMP threads''' per task can be controlled in a standard way, e.g. as		* The number of '''MPI tasks''' and '''OpenMP threads''' per task can be controlled in a standard way, e.g. as
	$ export OMP_NUM_THREADS=4		$ export OMP_NUM_THREADS=4

Aferretti: /* Yambo Parallelism in a nutshell */

2020-01-23T10:18:35Z

Yambo Parallelism in a nutshell

← Older revision		Revision as of 10:18, 23 January 2020
Line 12:		Line 12:
	on large partitions of HPC machines. For instance, runs over several tens of thousands of cores on the Marconi KNL partition (CINECA, IT) have been achieved, with a computational power ~ 3 PFl/s, as well as large scale runs on accelerated machines such as Piz-Daint at CSCS (CH), featuring NVIDIA GPUs.		on large partitions of HPC machines. For instance, runs over several tens of thousands of cores on the Marconi KNL partition (CINECA, IT) have been achieved, with a computational power ~ 3 PFl/s, as well as large scale runs on accelerated machines such as Piz-Daint at CSCS (CH), featuring NVIDIA GPUs.
	* '''MPI''' is particularly suited to distribute both memory and computation, and has a very efficient implementation in Yambo, which needs very few communications though may be prone to load unbalance (see [[GW_parallel_strategies\| GW parallel strategies]]).		* '''MPI''' is particularly suited to distribute both memory and computation, and has a very efficient implementation in Yambo, which needs very few communications though may be prone to load unbalance (see [[GW_parallel_strategies\| GW parallel strategies]]).
	* '''OpenMP''' instead works within a shared memory paradigm, meaning that multiple threads perform computation in parallel on the same data in memory (no memory replica, at least in principle)		* '''OpenMP''' instead works within a shared memory paradigm, meaning that multiple threads perform computation in parallel on the same data in memory (no memory replica, at least in principle).
			* '''GPU''' support is extremely efficient in Yambo, meaning that when you are running on GPU accelerated machines it is always a good idea to exploit the GPUs. In general, one needs to set 1 MPI task for each available GPU card, also including OpenMP threads to fully exploit the capabilities of the host. While a very relevant speed up can be achieved, device memory (eg 12, 16, 32 GB on currently available devices) may become a problem and needs to be controlled (eg increasing the number of required nodes and further distributing data across them).
	* Concerning '''Yambo''', tend to use MPI parallelism as much as possible (i.e. as much as memory allows), then resort to OpenMP parallelism in order not to increase memory usage any further while exploiting more cores and computing power.		* Concerning '''Yambo''', tend to use MPI parallelism as much as possible (i.e. as much as memory allows), then resort to OpenMP parallelism in order not to increase memory usage any further while exploiting more cores and computing power.
	* The number of '''MPI tasks''' and '''OpenMP threads''' per task can be controlled in a standard way, e.g. as		* The number of '''MPI tasks''' and '''OpenMP threads''' per task can be controlled in a standard way, e.g. as

Aferretti: /* Yambo Parallelism in a nutshell */

2020-01-23T09:54:00Z

Yambo Parallelism in a nutshell

← Older revision		Revision as of 09:54, 23 January 2020
Line 10:		Line 10:
	==Yambo Parallelism in a nutshell==		==Yambo Parallelism in a nutshell==
	Yambo implements a hybrid [https://en.wikipedia.org/wiki/Message_Passing_Interface MPI]+[https://en.wikipedia.org/wiki/OpenMP OpenMP] parallel scheme, suited to run		Yambo implements a hybrid [https://en.wikipedia.org/wiki/Message_Passing_Interface MPI]+[https://en.wikipedia.org/wiki/OpenMP OpenMP] parallel scheme, suited to run
	on large partitions of HPC machines ~~(for~~ instance, runs over several tens of thousands of cores on the Marconi KNL partition have been achieved, with a computational power ~ 3 PFl/s, as well as ~~runs~~ large scale runs on accelerated machines, such as Piz-Daint, featuring NVIDIA GPUs).		on large partitions of HPC machines. For instance, runs over several tens of thousands of cores on the Marconi KNL partition (CINECA, IT) have been achieved, with a computational power ~ 3 PFl/s, as well as large scale runs on accelerated machines such as Piz-Daint at CSCS (CH), featuring NVIDIA GPUs.
	* '''MPI''' is particularly suited to distribute both memory and computation, and has a very efficient implementation in Yambo, which needs very few communications though may be prone to load unbalance (see [[GW_parallel_strategies\| GW parallel strategies]]).		* '''MPI''' is particularly suited to distribute both memory and computation, and has a very efficient implementation in Yambo, which needs very few communications though may be prone to load unbalance (see [[GW_parallel_strategies\| GW parallel strategies]]).
	* '''OpenMP''' instead works within a shared memory paradigm, meaning that multiple threads perform computation in parallel on the same data in memory (no memory replica, at least in principle)		* '''OpenMP''' instead works within a shared memory paradigm, meaning that multiple threads perform computation in parallel on the same data in memory (no memory replica, at least in principle)

Aferretti: /* Yambo Parallelism in a nutshell */

2020-01-23T09:52:25Z

Yambo Parallelism in a nutshell

← Older revision		Revision as of 09:52, 23 January 2020
Line 10:		Line 10:
	==Yambo Parallelism in a nutshell==		==Yambo Parallelism in a nutshell==
	Yambo implements a hybrid [https://en.wikipedia.org/wiki/Message_Passing_Interface MPI]+[https://en.wikipedia.org/wiki/OpenMP OpenMP] parallel scheme, suited to run		Yambo implements a hybrid [https://en.wikipedia.org/wiki/Message_Passing_Interface MPI]+[https://en.wikipedia.org/wiki/OpenMP OpenMP] parallel scheme, suited to run
	on large partitions of HPC machines (~~as of Apr 2017~~, runs over several tens of thousands of cores, with a computational power ~~> 1~~ PFl/s, ~~have been achieved~~).		on large partitions of HPC machines (for instance, runs over several tens of thousands of cores on the Marconi KNL partition have been achieved, with a computational power ~ 3 PFl/s, as well as runs large scale runs on accelerated machines, such as Piz-Daint, featuring NVIDIA GPUs).
	* '''MPI''' is particularly suited to distribute both memory and computation, and has a very efficient implementation in Yambo, which needs very few communications though may be prone to load unbalance (see [[GW_parallel_strategies\| GW parallel strategies]]).		* '''MPI''' is particularly suited to distribute both memory and computation, and has a very efficient implementation in Yambo, which needs very few communications though may be prone to load unbalance (see [[GW_parallel_strategies\| GW parallel strategies]]).
	* '''OpenMP''' instead works within a shared memory paradigm, meaning that multiple threads perform computation in parallel on the same data in memory (no memory replica, at least in principle)		* '''OpenMP''' instead works within a shared memory paradigm, meaning that multiple threads perform computation in parallel on the same data in memory (no memory replica, at least in principle)

Conor at 09:24, 12 September 2017

2017-09-12T09:24:14Z

← Older revision		Revision as of 09:24, 12 September 2017
Line 207:		Line 207:
	== Links ==		== Links ==
	* [[Tutorials\|Back to tutorials menu]]		* [[Tutorials\|Back to tutorials menu]]

			[[Category:Modules]]