What I worked on in week 6:
On #7440 I removed the old testsuite and added the pytest with the skip removed to see how CI handles it. I swapped my older benchmark for the script my mentor provided, with the thread pinning commented out. I also rechecked serial speed against the unparallelized version on the same 100 million cell map with window size 31 and cooldowns between runs, and there was no regression.
For the lu.c bug I worked out a plan for a permanent fix. I searched every place G_ludcmp is called across GRASS and the addons, and only four modules use it. R.param.scale, being one of the modules, already had my single threaded workaround, and two others call it from serial code where the race can’t fire. The last one, v.surf.rst, calls it from inside an already parallel region where OpenMP runs the inner loop single threaded anyway. Since no caller actually benefits from the parallel pivot search, and with both Claude’s suggestion and mentor agreeing with the idea, the simplest correct fix was to just remove the pragma call from the library.
I also started on r.proj this week with a row based parallelization. It was memory efficient with a good compute speedup, though the total speedup is limited because raster output writing in GRASS is serial by design. The bigger problem was that the row approach only worked for simple reprojections, so I was suggested trying a column-wise approach for the harder projections. I also addressed mentor feedback and questions within the draft PR comments.
PRs:
r.param.scale - r.param.scale: parallelize with OpenMP by krcoder123 · Pull Request #7440 · OSGeo/grass · GitHub
r.proj - r.proj: memory-bounded parallel banding by krcoder123 · Pull Request #7627 · OSGeo/grass · GitHub
Thanks,
Kaushik