[GRASS-user] Inquiry about GRASS GIS Windows Binary Stand-Alone Build Configuration

[Synper311]

Markus, Helmut,

Thank you both for the extra information! I’ll attempt to work a solution using your method and see if it helps speed up that part of our workflow.

Thanks!
Brett

From: Markus Neteler
Sent: Saturday, December 18, 2021 9:17 AM
To: Synper311
Cc: grass-user at lists.osgeo.org
Subject: Re: [GRASS-user] Inquiry about GRASS GIS Windows Binary Stand-Alone Build Configuration

Hi,

On Fri, Dec 17, 2021 at 9:27 PM Synper311 via grass-user
<grass-user at 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:

r.proj
r.series.accumulate
r.sim.sediment
r.sim.water
r.sun
v.surf.rst

and several more are in the pipeline:

https://github.com/OSGeo/grass/pulls?q=is%3Apr+is%3Aopen+openMP

> 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

Best,
Markus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20211230/adaf4427/attachment.html>