OpenMP - Revision history

Neteler: remove hardcoded version specific urls, use latest version

2018-12-04T10:40:05Z

remove hardcoded version specific urls, use latest version

Annakrat: update openmp modules support

2017-10-27T14:58:31Z

update openmp modules support

← Older revision		Revision as of 14:58, 27 October 2017
Line 18:		Line 18:

	=== OpenMP support in GRASS 7 ===		=== OpenMP support in GRASS 7 ===
			Several modules have fully functioning OpenMP support: {{Cmd\|v.surf.rst\|version=73}}, {{Cmd\|r.sim.water\|version=73}}, {{Cmd\|r.sim.sediment\|version=73}}, it is available currently in trunk (7.3), will be available in GRASS GIS 7.4.
	In GRASS ~~version~~ 7 ~~the~~ gpde and the gmath libraries are providing functions which are partly parallelized with OpenMP. All blas level 2 and 3 functions as well as many linear equation solver in the gmath library, are parallelized using OpenMP pragmas. Several numerical modules, which are using those functions, can now benefit from multi core systems (i.e.: {{cmd\|r.proj\|version=70}}, {{Cmd\|r.gwflow\|version=70}}, {{Cmd\|r3.gwflow\|version=70}}, {{Cmd\|r.solute.transport\|version=70}}). Other modules like {{Cmd\|v.surf.bspline~~\|version=70}} and {{Cmd\|v.surf.rst~~\|version=70}} have initial support (via the LU solvers in the gmath library) but are still in the prototype stage and not very efficient yet.		{{AddonCmd\|r.sun.mp\|version=72}} will be moved to trunk and available in GRASS GIS 7.4.
			The gpde and the gmath libraries are providing functions which are partly parallelized with OpenMP. All blas level 2 and 3 functions as well as many linear equation solver in the gmath library, are parallelized using OpenMP pragmas. Several numerical modules, which are using those functions, can now benefit from multi core systems (i.e.: {{cmd\|r.proj\|version=70}}, {{Cmd\|r.gwflow\|version=70}}, {{Cmd\|r3.gwflow\|version=70}}, {{Cmd\|r.solute.transport\|version=70}}).
			Other modules like {{Cmd\|v.surf.bspline\|version=70}} have initial support (via the LU solvers in the gmath library) but are still in the prototype stage and not very efficient yet.

	OpenMP flags are compiler dependent, thus OpenMP support should be set using C- and linker-flags before calling configure.		OpenMP flags are compiler dependent, thus OpenMP support should be set using C- and linker-flags before calling configure.
Line 165:		Line 167:
	* v.lidar: parallelize tcholDec() in {{src\|lib/lidar/TcholBand.c}} (?moved)		* v.lidar: parallelize tcholDec() in {{src\|lib/lidar/TcholBand.c}} (?moved)
	: This would speed up the CPU-bound {{cmd\|v.surf.bspline\|version=70}} and {{cmd\|v.lidar.edgedetection\|version=70}} considerably. [Partially done in the gmath lib by Soeren?]		: This would speed up the CPU-bound {{cmd\|v.surf.bspline\|version=70}} and {{cmd\|v.lidar.edgedetection\|version=70}} considerably. [Partially done in the gmath lib by Soeren?]

	* (suggestion) RST library and {{cmd\|v.surf.rst\|version=70}} [Partially done in the gmath lib by Hamish?]
	~~: Please contact and coordinate with Helena Mitasova before starting work on this.~~

	* (suggestion) {{cmd\|r.watershed\|version=70}}		* (suggestion) {{cmd\|r.watershed\|version=70}}
Line 176:		Line 175:
	: Should fix bug described in {{trac\|390}} first and once that is done move module into the main repo.		: Should fix bug described in {{trac\|390}} first and once that is done move module into the main repo.

	* (~~in progress~~) {{cmd\|r.sun\|version=70}} [Note, OpenCL GPU support already added by Seth Price as part of his Summer of Code project; OpenCL supports multi CPU as well as GPU; ./configure GRASS 7 --with-opencl]		* (done) {{cmd\|r.sun\|version=70}} [Note, OpenCL GPU support already added by Seth Price as part of his Summer of Code project; OpenCL supports multi CPU as well as GPU; ./configure GRASS 7 --with-opencl]
	: Please contact and coordinate with Markus Neteler / Jaro Hofierka before starting work on this.		: Please contact and coordinate with Markus Neteler / Jaro Hofierka before starting work on this.

Neteler: + FOSDEM 2014: Using OpenMP to Simply Parallelize CPU-Intensive C Code

2014-11-28T20:07:10Z

+ FOSDEM 2014: Using OpenMP to Simply Parallelize CPU-Intensive C Code

← Older revision		Revision as of 20:07, 28 November 2014
Line 220:		Line 220:

	* [https://docs.loni.org/wiki/Introduction_to_OpenMP Introduction to OpenMP]		* [https://docs.loni.org/wiki/Introduction_to_OpenMP Introduction to OpenMP]
			* [https://archive.fosdem.org/2014/schedule/event/hpc_devroom_openmp_tutorial Using OpenMP to Simply Parallelize CPU-Intensive C Code] - Klaas van Gend, 2014, FOSDEM Brussels
	* [https://computing.llnl.gov/tutorials/openMP OpenMP tutorial]		* [https://computing.llnl.gov/tutorials/openMP OpenMP tutorial]
	* [http://developer.amd.com/Membership/Print.aspx?ArticleID=157&web=http%3a%2f%2fdeveloper.amd.com%2fdocumentation%2farticles Easy OpenMP tutorial showing multithreading a program by sections], as opposed to the usual loop examples.		* [http://developer.amd.com/Membership/Print.aspx?ArticleID=157&web=http%3a%2f%2fdeveloper.amd.com%2fdocumentation%2farticles Easy OpenMP tutorial showing multithreading a program by sections], as opposed to the usual loop examples.

⚠️Mmetz: /* Candidates */

2013-09-27T09:15:44Z

Candidates

← Older revision		Revision as of 09:15, 27 September 2013
Line 182:		Line 182:

	* (suggestion) {{cmd\|r.neighbors\|version=70}} particularly for large neighborhood sizes.		* (suggestion) {{cmd\|r.neighbors\|version=70}} particularly for large neighborhood sizes.

			* (suggestion) {{cmd\|r.mfilter\|version=70}} particularly for large neighborhood sizes.

	* (suggestion) {{cmd\|r.texture\|version=70}} particularly for multiple methods and/or large regions.		* (suggestion) {{cmd\|r.texture\|version=70}} particularly for multiple methods and/or large regions.

⚠️Mmetz: add candidates

2013-09-27T08:51:52Z

add candidates

← Older revision		Revision as of 08:51, 27 September 2013
Line 180:		Line 180:

	* (suggestion) {{cmd\|r.univar\|version=70}} when run with multiple input maps. Send each input map to its own thread.		* (suggestion) {{cmd\|r.univar\|version=70}} when run with multiple input maps. Send each input map to its own thread.

			* (suggestion) {{cmd\|r.neighbors\|version=70}} particularly for large neighborhood sizes.

			* (suggestion) {{cmd\|r.texture\|version=70}} particularly for multiple methods and/or large regions.

	== Complete ==		== Complete ==

⚠️HamishBowman: /* Benchmarks */ link to results page

2013-08-30T23:52:33Z

Benchmarks: link to results page

← Older revision		Revision as of 23:52, 30 August 2013
Line 208:		Line 208:

	Neighborhood analysis performance using OpenMP and different compilers:		Neighborhood analysis performance using OpenMP and different compilers:
			* [[OpenMP/Benchmarks]]
	: http://trac.osgeo.org/grass/browser/sandbox/soeren/benchmarks/neighborhood_openmp/		: http://trac.osgeo.org/grass/browser/sandbox/soeren/benchmarks/neighborhood_openmp/

⚠️HamishBowman at 23:50, 30 August 2013

2013-08-30T23:50:41Z

← Older revision		Revision as of 23:50, 30 August 2013
Line 208:		Line 208:

	Neighborhood analysis performance using OpenMP and different compilers:		Neighborhood analysis performance using OpenMP and different compilers:
	~~source\|svn~~/sandbox/soeren/benchmarks/neighborhood_openmp/		: http://trac.osgeo.org/grass/browser/sandbox/soeren/benchmarks/neighborhood_openmp/

	== See also ==		== See also ==

⚠️HamishBowman: benchmarks

2013-07-24T00:41:44Z

benchmarks

← Older revision		Revision as of 00:41, 24 July 2013
Line 204:		Line 204:

	; WARNING: not all GRASS modules and scripts are safe to have other things happening in the same mapset while they are running. Try at your own risk after performing a suitable safety audit. e.g. Make sure {{cmd\|g.region\|version=70}} is not run, externally (temporarily) changing the region settings.		; WARNING: not all GRASS modules and scripts are safe to have other things happening in the same mapset while they are running. Try at your own risk after performing a suitable safety audit. e.g. Make sure {{cmd\|g.region\|version=70}} is not run, externally (temporarily) changing the region settings.

			== Benchmarks ==

			Neighborhood analysis performance using OpenMP and different compilers:
			source\|svn/sandbox/soeren/benchmarks/neighborhood_openmp/

	== See also ==		== See also ==

⚠️HamishBowman: /* Candidates */

2013-04-30T08:04:19Z

Candidates

← Older revision		Revision as of 08:04, 30 April 2013
Line 176:		Line 176:
	: Should fix bug described in {{trac\|390}} first and once that is done move module into the main repo.		: Should fix bug described in {{trac\|390}} first and once that is done move module into the main repo.

	* (~~suggestion~~) {{cmd\|r.sun\|version=70}} [Note, OpenCL GPU support already added by Seth Price as part of his Summer of Code project; OpenCL supports multi CPU as well as GPU]		* (in progress) {{cmd\|r.sun\|version=70}} [Note, OpenCL GPU support already added by Seth Price as part of his Summer of Code project; OpenCL supports multi CPU as well as GPU; ./configure GRASS 7 --with-opencl]
	: Please contact and coordinate with Markus Neteler / Jaro Hofierka before starting work on this.		: Please contact and coordinate with Markus Neteler / Jaro Hofierka before starting work on this.

Neteler: point to G7 versions

2013-01-30T20:33:32Z

point to G7 versions

← Older revision		Revision as of 14:58, 27 October 2017
Line 18:		Line 18:

	=== OpenMP support in GRASS 7 ===		=== OpenMP support in GRASS 7 ===
			Several modules have fully functioning OpenMP support: {{Cmd\|v.surf.rst\|version=73}}, {{Cmd\|r.sim.water\|version=73}}, {{Cmd\|r.sim.sediment\|version=73}}, it is available currently in trunk (7.3), will be available in GRASS GIS 7.4.
	In GRASS ~~version~~ 7 ~~the~~ gpde and the gmath libraries are providing functions which are partly parallelized with OpenMP. All blas level 2 and 3 functions as well as many linear equation solver in the gmath library, are parallelized using OpenMP pragmas. Several numerical modules, which are using those functions, can now benefit from multi core systems (i.e.: {{cmd\|r.proj\|version=70}}, {{Cmd\|r.gwflow\|version=70}}, {{Cmd\|r3.gwflow\|version=70}}, {{Cmd\|r.solute.transport\|version=70}}). Other modules like {{Cmd\|v.surf.bspline~~\|version=70}} and {{Cmd\|v.surf.rst~~\|version=70}} have initial support (via the LU solvers in the gmath library) but are still in the prototype stage and not very efficient yet.		{{AddonCmd\|r.sun.mp\|version=72}} will be moved to trunk and available in GRASS GIS 7.4.
			The gpde and the gmath libraries are providing functions which are partly parallelized with OpenMP. All blas level 2 and 3 functions as well as many linear equation solver in the gmath library, are parallelized using OpenMP pragmas. Several numerical modules, which are using those functions, can now benefit from multi core systems (i.e.: {{cmd\|r.proj\|version=70}}, {{Cmd\|r.gwflow\|version=70}}, {{Cmd\|r3.gwflow\|version=70}}, {{Cmd\|r.solute.transport\|version=70}}).
			Other modules like {{Cmd\|v.surf.bspline\|version=70}} have initial support (via the LU solvers in the gmath library) but are still in the prototype stage and not very efficient yet.

	OpenMP flags are compiler dependent, thus OpenMP support should be set using C- and linker-flags before calling configure.		OpenMP flags are compiler dependent, thus OpenMP support should be set using C- and linker-flags before calling configure.
Line 165:		Line 167:
	* v.lidar: parallelize tcholDec() in {{src\|lib/lidar/TcholBand.c}} (?moved)		* v.lidar: parallelize tcholDec() in {{src\|lib/lidar/TcholBand.c}} (?moved)
	: This would speed up the CPU-bound {{cmd\|v.surf.bspline\|version=70}} and {{cmd\|v.lidar.edgedetection\|version=70}} considerably. [Partially done in the gmath lib by Soeren?]		: This would speed up the CPU-bound {{cmd\|v.surf.bspline\|version=70}} and {{cmd\|v.lidar.edgedetection\|version=70}} considerably. [Partially done in the gmath lib by Soeren?]

	* (suggestion) RST library and {{cmd\|v.surf.rst\|version=70}} [Partially done in the gmath lib by Hamish?]
	~~: Please contact and coordinate with Helena Mitasova before starting work on this.~~

	* (suggestion) {{cmd\|r.watershed\|version=70}}		* (suggestion) {{cmd\|r.watershed\|version=70}}
Line 176:		Line 175:
	: Should fix bug described in {{trac\|390}} first and once that is done move module into the main repo.		: Should fix bug described in {{trac\|390}} first and once that is done move module into the main repo.

	* (~~in progress~~) {{cmd\|r.sun\|version=70}} [Note, OpenCL GPU support already added by Seth Price as part of his Summer of Code project; OpenCL supports multi CPU as well as GPU; ./configure GRASS 7 --with-opencl]		* (done) {{cmd\|r.sun\|version=70}} [Note, OpenCL GPU support already added by Seth Price as part of his Summer of Code project; OpenCL supports multi CPU as well as GPU; ./configure GRASS 7 --with-opencl]
	: Please contact and coordinate with Markus Neteler / Jaro Hofierka before starting work on this.		: Please contact and coordinate with Markus Neteler / Jaro Hofierka before starting work on this.

← Older revision		Revision as of 09:15, 27 September 2013
Line 182:		Line 182:

	* (suggestion) {{cmd\|r.neighbors\|version=70}} particularly for large neighborhood sizes.		* (suggestion) {{cmd\|r.neighbors\|version=70}} particularly for large neighborhood sizes.

			* (suggestion) {{cmd\|r.mfilter\|version=70}} particularly for large neighborhood sizes.

	* (suggestion) {{cmd\|r.texture\|version=70}} particularly for multiple methods and/or large regions.		* (suggestion) {{cmd\|r.texture\|version=70}} particularly for multiple methods and/or large regions.

← Older revision		Revision as of 10:40, 4 December 2018
Line 18:		Line 18:

	=== OpenMP support in GRASS 7 ===		=== OpenMP support in GRASS 7 ===
	Several modules have fully functioning OpenMP support: {{Cmd\|v.surf.rst~~\|version=73~~}}, {{Cmd\|r.sim.water~~\|version=73~~}}, {{Cmd\|r.sim.sediment~~\|version=73~~}}, it is ~~available currently in trunk (7.3), will be~~ available in GRASS GIS 7.4.		Several modules have fully functioning OpenMP support:
	{{AddonCmd\|r.sun.mp\|version=72}} ~~will~~ be ~~moved to trunk~~ and available in GRASS GIS 7.4.		* {{Cmd\|v.surf.rst}}, {{Cmd\|r.sim.water}}, {{Cmd\|r.sim.sediment}}, it is available in GRASS GIS 7.4+.
	The gpde and the gmath libraries are providing functions which are partly parallelized with OpenMP. All blas level 2 and 3 functions as well as many linear equation solver in the gmath library, are parallelized using OpenMP pragmas. Several numerical modules, which are using those functions, can now benefit from multi core systems (i.e.: {{cmd\|r.proj~~\|version=70~~}}, {{Cmd\|r.gwflow~~\|version=70~~}}, {{Cmd\|r3.gwflow~~\|version=70~~}}, {{Cmd\|r.solute.transport~~\|version=70~~}}).		* {{AddonCmd\|r.sun.mp\|version=7}} has be merged and is available in GRASS GIS 7.4+.
	Other modules like {{Cmd\|v.surf.bspline~~\|version=70~~}} have initial support (via the LU solvers in the gmath library) but are still in the prototype stage and not very efficient yet.		* The gpde and the gmath libraries are providing functions which are partly parallelized with OpenMP. All blas level 2 and 3 functions as well as many linear equation solver in the gmath library, are parallelized using OpenMP pragmas. Several numerical modules, which are using those functions, can now benefit from multi core systems (i.e.: {{cmd\|r.proj}}, {{Cmd\|r.gwflow}}, {{Cmd\|r3.gwflow}}, {{Cmd\|r.solute.transport}}).
			Other modules like {{Cmd\|v.surf.bspline}} have initial support (via the LU solvers in the gmath library) but are still in the prototype stage and not very efficient yet.

	OpenMP flags are compiler dependent, thus OpenMP support should be set using C- and linker-flags before calling configure.		OpenMP flags are compiler dependent, thus OpenMP support should be set using C- and linker-flags before calling configure.
Line 166:		Line 167:

	* v.lidar: parallelize tcholDec() in {{src\|lib/lidar/TcholBand.c}} (?moved)		* v.lidar: parallelize tcholDec() in {{src\|lib/lidar/TcholBand.c}} (?moved)
	: This would speed up the CPU-bound {{cmd\|v.surf.bspline~~\|version=70~~}} and {{cmd\|v.lidar.edgedetection~~\|version=70~~}} considerably. [Partially done in the gmath lib by Soeren?]		: This would speed up the CPU-bound {{cmd\|v.surf.bspline}} and {{cmd\|v.lidar.edgedetection}} considerably. [Partially done in the gmath lib by Soeren?]

	* (suggestion) {{cmd\|r.watershed~~\|version=70~~}}		* (suggestion) {{cmd\|r.watershed}}
	: Please contact and coordinate with Markus Metz before starting work on this.		: Please contact and coordinate with Markus Metz before starting work on this.

	* (suggestion) {{Cmd\|r.viewshed~~\|version=70~~}} (C++)		* (suggestion) {{Cmd\|r.viewshed}} (C++)
	: Please contact and coordinate with Laura Toma before starting work on this.		: Please contact and coordinate with Laura Toma before starting work on this.
	: Should fix bug described in {{trac\|390}} first and once that is done move module into the main repo.		: Should fix bug described in {{trac\|390}} first and once that is done move module into the main repo.

	* (done) {{cmd\|r.sun~~\|version=70~~}} [Note, OpenCL GPU support already added by Seth Price as part of his Summer of Code project; OpenCL supports multi CPU as well as GPU; ./configure GRASS 7 --with-opencl]		* (done) {{cmd\|r.sun}} [Note, OpenCL GPU support already added by Seth Price as part of his Summer of Code project; OpenCL supports multi CPU as well as GPU; ./configure GRASS 7 --with-opencl]
	: Please contact and coordinate with Markus Neteler / Jaro Hofierka before starting work on this.		: Please contact and coordinate with Markus Neteler / Jaro Hofierka before starting work on this.

	* (suggestion) {{cmd\|r.univar~~\|version=70~~}} when run with multiple input maps. Send each input map to its own thread.		* (suggestion) {{cmd\|r.univar}} when run with multiple input maps. Send each input map to its own thread.

	* (suggestion) {{cmd\|r.neighbors~~\|version=70~~}} particularly for large neighborhood sizes.		* (suggestion) {{cmd\|r.neighbors}} particularly for large neighborhood sizes.

	* (suggestion) {{cmd\|r.mfilter~~\|version=70~~}} particularly for large neighborhood sizes.		* (suggestion) {{cmd\|r.mfilter}} particularly for large neighborhood sizes.

	* (suggestion) {{cmd\|r.texture~~\|version=70~~}} particularly for multiple methods and/or large regions.		* (suggestion) {{cmd\|r.texture}} particularly for multiple methods and/or large regions.

	== Complete ==		== Complete ==
Line 193:		Line 194:
	* The GPDE library ({{src\|lib/gpde/}}) has OpenMP support		* The GPDE library ({{src\|lib/gpde/}}) has OpenMP support

	* The gmath library ({{src\|lib/gmath/}}) has OpenMP support for grass blas level 1, 2 and 3 algorithms as well as several iterative and direct linear equation solver. This is a work in progress, and may not be very efficient currently. When finished, a parallelized LU solver will help with tasks like {{cmd\|v.surf.rst~~\|version=70~~}} and {{cmd\|v.surf.bspline~~\|version=70~~}}.		* The gmath library ({{src\|lib/gmath/}}) has OpenMP support for grass blas level 1, 2 and 3 algorithms as well as several iterative and direct linear equation solver. This is a work in progress, and may not be very efficient currently. When finished, a parallelized LU solver will help with tasks like {{cmd\|v.surf.rst}} and {{cmd\|v.surf.bspline}}.

	* Experimental {{wikipedia\|Pthread}} support for [http://thread.gmane.org/gmane.comp.gis.grass.devel/30313 r.mapcalc is now in GRASS 7svn]		* Experimental {{wikipedia\|Pthread}} support for [http://thread.gmane.org/gmane.comp.gis.grass.devel/30313 r.mapcalc is now in GRASS 7svn]

	* Yann has added OpenMP support to {{cmd\|i.atcorr~~\|version=70~~}}. (not in SVN, since not working properly)		* Yann has added OpenMP support to {{cmd\|i.atcorr}}. (not in SVN, since not working properly)

	* MarkusM has added OpenMP support to {{cmd\|r.proj~~\|version=70~~}} in GRASS 7 (and removed, since not working properly)		* MarkusM has added OpenMP support to {{cmd\|r.proj}} in GRASS 7 (and removed, since not working properly)

	== Alternatives ==		== Alternatives ==
Line 208:		Line 209:
	* For some tasks it may be possible to easily parallelize at the module level. See [[Parallelizing Scripts]]		* For some tasks it may be possible to easily parallelize at the module level. See [[Parallelizing Scripts]]

	; WARNING: not all GRASS modules and scripts are safe to have other things happening in the same mapset while they are running. Try at your own risk after performing a suitable safety audit. e.g. Make sure {{cmd\|g.region~~\|version=70~~}} is not run, externally (temporarily) changing the region settings.		; WARNING: not all GRASS modules and scripts are safe to have other things happening in the same mapset while they are running. Try at your own risk after performing a suitable safety audit. e.g. Make sure {{cmd\|g.region}} is not run, externally (temporarily) changing the region settings.

	== Benchmarks ==		== Benchmarks ==

← Older revision		Revision as of 20:33, 30 January 2013
Line 19:		Line 19:
	=== OpenMP support in GRASS 7 ===		=== OpenMP support in GRASS 7 ===

	In GRASS version 7 the gpde and the gmath libraries are providing functions which are partly parallelized with OpenMP. All blas level 2 and 3 functions as well as many linear equation solver in the gmath library, are parallelized using OpenMP pragmas. Several numerical modules, which are using those functions, can now benefit from multi core systems (i.e.: {{~~Cmd~~\|r.proj}}, {{Cmd\|r.gwflow}}, {{Cmd\|r3.gwflow}}, {{Cmd\|r.solute.transport\|version=70}}). Other modules like {{Cmd\|v.surf.bspline}} and {{Cmd\|v.surf.rst}} have initial support (via the LU solvers in the gmath library) but are still in the prototype stage and not very efficient yet.		In GRASS version 7 the gpde and the gmath libraries are providing functions which are partly parallelized with OpenMP. All blas level 2 and 3 functions as well as many linear equation solver in the gmath library, are parallelized using OpenMP pragmas. Several numerical modules, which are using those functions, can now benefit from multi core systems (i.e.: {{cmd\|r.proj\|version=70}}, {{Cmd\|r.gwflow\|version=70}}, {{Cmd\|r3.gwflow\|version=70}}, {{Cmd\|r.solute.transport\|version=70}}). Other modules like {{Cmd\|v.surf.bspline\|version=70}} and {{Cmd\|v.surf.rst\|version=70}} have initial support (via the LU solvers in the gmath library) but are still in the prototype stage and not very efficient yet.

	OpenMP flags are compiler dependent, thus OpenMP support should be set using C- and linker-flags before calling configure.		OpenMP flags are compiler dependent, thus OpenMP support should be set using C- and linker-flags before calling configure.
Line 164:		Line 164:

	* v.lidar: parallelize tcholDec() in {{src\|lib/lidar/TcholBand.c}} (?moved)		* v.lidar: parallelize tcholDec() in {{src\|lib/lidar/TcholBand.c}} (?moved)
	: This would speed up the CPU-bound {{cmd\|v.surf.bspline}} and {{cmd\|v.lidar.edgedetection}} considerably. [Partially done in the gmath lib by Soeren?]		: This would speed up the CPU-bound {{cmd\|v.surf.bspline\|version=70}} and {{cmd\|v.lidar.edgedetection\|version=70}} considerably. [Partially done in the gmath lib by Soeren?]

	* (suggestion) RST library and {{cmd\|v.surf.rst}} [Partially done in the gmath lib by Hamish?]		* (suggestion) RST library and {{cmd\|v.surf.rst\|version=70}} [Partially done in the gmath lib by Hamish?]
	: Please contact and coordinate with Helena Mitasova before starting work on this.		: Please contact and coordinate with Helena Mitasova before starting work on this.

	* (suggestion) {{cmd\|r.watershed}}		* (suggestion) {{cmd\|r.watershed\|version=70}}
	: Please contact and coordinate with Markus Metz before starting work on this.		: Please contact and coordinate with Markus Metz before starting work on this.

	* (suggestion) {{~~AddonCmd~~\|r.viewshed}} (C++)		* (suggestion) {{Cmd\|r.viewshed\|version=70}} (C++)
	: Please contact and coordinate with Laura Toma before starting work on this.		: Please contact and coordinate with Laura Toma before starting work on this.
	: Should fix bug described in {{trac\|390}} first and once that is done move module into the main repo.		: Should fix bug described in {{trac\|390}} first and once that is done move module into the main repo.

	* (suggestion) {{cmd\|r.sun}} [Note, OpenCL GPU support already added by Seth Price as part of his Summer of Code project; OpenCL supports multi CPU as well as GPU]		* (suggestion) {{cmd\|r.sun\|version=70}} [Note, OpenCL GPU support already added by Seth Price as part of his Summer of Code project; OpenCL supports multi CPU as well as GPU]
	: Please contact and coordinate with Markus Neteler / Jaro Hofierka before starting work on this.		: Please contact and coordinate with Markus Neteler / Jaro Hofierka before starting work on this.

	* (suggestion) {{cmd\|r.univar}} when run with multiple input maps. Send each input map to its own thread.		* (suggestion) {{cmd\|r.univar\|version=70}} when run with multiple input maps. Send each input map to its own thread.

	== Complete ==		== Complete ==
Line 188:		Line 188:
	* The GPDE library ({{src\|lib/gpde/}}) has OpenMP support		* The GPDE library ({{src\|lib/gpde/}}) has OpenMP support

	* The gmath library ({{src\|lib/gmath/}}) has OpenMP support for grass blas level 1, 2 and 3 algorithms as well as several iterative and direct linear equation solver. This is a work in progress, and may not be very efficient currently. When finished, a parallelized LU solver will help with tasks like {{cmd\|v.surf.rst}} and {{cmd\|v.surf.bspline}}.		* The gmath library ({{src\|lib/gmath/}}) has OpenMP support for grass blas level 1, 2 and 3 algorithms as well as several iterative and direct linear equation solver. This is a work in progress, and may not be very efficient currently. When finished, a parallelized LU solver will help with tasks like {{cmd\|v.surf.rst\|version=70}} and {{cmd\|v.surf.bspline\|version=70}}.

	* Experimental {{wikipedia\|Pthread}} support for [http://thread.gmane.org/gmane.comp.gis.grass.devel/30313 r.mapcalc is now in GRASS 7svn]		* Experimental {{wikipedia\|Pthread}} support for [http://thread.gmane.org/gmane.comp.gis.grass.devel/30313 r.mapcalc is now in GRASS 7svn]

	* Yann has added OpenMP support to {{cmd\|i.atcorr}}. (not in SVN)		* Yann has added OpenMP support to {{cmd\|i.atcorr\|version=70}}. (not in SVN, since not working properly)

	* MarkusM has added OpenMP support to {{cmd\|r.proj\|version=70}} in GRASS 7.		* MarkusM has added OpenMP support to {{cmd\|r.proj\|version=70}} in GRASS 7 (and removed, since not working properly)

	== Alternatives ==		== Alternatives ==
Line 203:		Line 203:
	* For some tasks it may be possible to easily parallelize at the module level. See [[Parallelizing Scripts]]		* For some tasks it may be possible to easily parallelize at the module level. See [[Parallelizing Scripts]]

	; WARNING: not all GRASS modules and scripts are safe to have other things happening in the same mapset while they are running. Try at your own risk after performing a suitable safety audit. e.g. Make sure {{cmd\|g.region}} is not run, externally (temporarily) changing the region settings.		; WARNING: not all GRASS modules and scripts are safe to have other things happening in the same mapset while they are running. Try at your own risk after performing a suitable safety audit. e.g. Make sure {{cmd\|g.region\|version=70}} is not run, externally (temporarily) changing the region settings.

	== See also ==		== See also ==