What I worked on in week 3:
While stress testing the parallel r.param.scale I found a small nondeterminism in the output, around one unit in the last place, that only showed up with more than one thread. I traced it to the pivot search in the library function lu.c. It runs a parallel loop that writes the shared variables big and imax without any synchronization or lock, so the pivot it picks can change from run to run once multiple threads are used. I reported it to the mentors and it is now tracked in issue #7539. As a workaround, #7440 runs just the LU decomposition single threaded, so the module’s output matches serial exactly at every thread count without touching the library.
At mentor’s request I also created PR #7534, a pytest that generates a small raster and checks r.param.scale results against reference values from the current serial code. I also pushed a gunittest version to #7440 that compares nprocs=1 against nprocs=4 directly.
I used Claude to help find the root cause of the lu.c issue
PR: r.param.scale: parallelize with OpenMP by krcoder123 · Pull Request #7440 · OSGeo/grass · GitHub
Thanks,
Kaushik