[GRASS-git] [OSGeo/grass] 4d2da1: r.sim: Lock the infiltration capacity of a cell (#...

[Vaclav Petras]

  Branch: refs/heads/main
  Home:   https://github.com/OSGeo/grass
  Commit: 4d2da1c18552037c2fbba1ad4847fd9ebf2bbe8e
      https://github.com/OSGeo/grass/commit/4d2da1c18552037c2fbba1ad4847fd9ebf2bbe8e
  Author: Vaclav Petras <wenzeslaus at gmail.com>
  Date:   2026-10-02 (Fri, 02 Oct 2026)

  Changed paths:
    M raster/r.sim/r.sim.water/tests/r_sim_water_nprocs_test.py
    M raster/r.sim/simlib/hydro.c

  Log Message:
  -----------
  r.sim: Lock the infiltration capacity of a cell (#8001)

With nprocs > 1, walkers on different threads checked and reduced the
remaining infiltration capacity of a cell without synchronization. This
is a data race and undefined behavior in C: two walkers could both be
absorbed by the capacity left for one, or a reduction could be lost.

Run the unchanged infiltration code in a critical section, entered only
when an atomic read shows capacity left in the cell. Within the lock,
the code checks the capacity again, as another thread may have used it
up. The capacity is written atomically, since it is also read outside
of the lock. After the first step, few walkers are in a cell with
capacity left, so the lock is rarely taken.

The arithmetic and the conditions are unchanged. With one thread, the
depth maps computed from the elev_lid792_1m elevation, with and without
infiltration, are byte-identical to those before this change, and the
run time is the same within noise with 1 and 4 threads. With more
threads, the order in which walkers reach a cell still depends on
thread scheduling, as before. A new test checks that infiltration
removes exactly the capacity of the cells at 1 and 4 threads.

Written with the help of Claude Code.



To unsubscribe from these emails, change your notification settings at https://github.com/OSGeo/grass/settings/notifications