Just writing to inquire if the GRASS GIS Windows Binary Stand-Alone Builds are using the –with-openmp Build Configuration flag to enable multithreading across all applicable modules.
Tangential to this question is whether or not it is expected that r.contour will use N-Number of threads when processing on a system with greater than 4 threads. This question arises as it was observed to only use 4 threads on a Ryzen machine with 24+ threads.
For a bit more context, this all relates to the usage of the Binary GRASS GIS files being used within the context of generating contours within WebODM (OpenDroneMap).
On Fri, Dec 17, 2021 at 9:27 PM Synper311 via grass-user
<grass-user@lists.osgeo.org> wrote:
Hi,
Just writing to inquire if the GRASS GIS Windows Binary Stand-Alone Builds are using the –with-openmp Build Configuration flag to enable multithreading across all applicable modules.
(see the email by Helmut)
Tangential to this question is whether or not it is expected that r.contour will use N-Number of threads when processing
on a system with greater than 4 threads. This question arises as it was observed to only use 4 threads on a Ryzen
machine with 24+ threads.
To my knowledge these commands have openMP support so far:
For a bit more context, this all relates to the usage of the Binary GRASS GIS files being used within the context of generating contours within WebODM (OpenDroneMap).
Would be nice to see r.contour to be the next candidate!
Alternative solution (say, an idea) for now:
- r.tile the data into chunks (perhaps with small overlap, not sure if
needed or useful)
- run r.contour on the tiles, in parallel (SLURM, gnu-parallel, something else)
- v.patch the resulting vector maps
- v.build.polylines to generate polylines from lines
Just writing to inquire if the GRASS GIS Windows Binary Stand-Alone Builds are using the –with-openmp Build Configuration flag to enable multithreading across all applicable modules.
(see the email by Helmut)
Tangential to this question is whether or not it is expected that r.contour will use N-Number of threads when processing
on a system with greater than 4 threads. This question arises as it was observed to only use 4 threads on a Ryzen
machine with 24+ threads.
To my knowledge these commands have openMP support so far:
For a bit more context, this all relates to the usage of the Binary GRASS GIS files being used within the context of generating contours within WebODM (OpenDroneMap).
Would be nice to see r.contour to be the next candidate!
Alternative solution (say, an idea) for now:
r.tile the data into chunks (perhaps with small overlap, not sure if
needed or useful)
run r.contour on the tiles, in parallel (SLURM, gnu-parallel, something else)
v.patch the resulting vector maps
v.build.polylines to generate polylines from lines