Deterministic / bit-for-bit identical output across runs (seed or deterministic mode?)

[LeandreSassi]

I’m trying to get bit-for-bit identical geometry from two runs with exactly the same inputs and config, but I still see differences between runs. I’m looking for guidance on whether fully deterministic output is possible today, and how to achieve it (e.g., via a seed or a deterministic mode).

What I’m doing

Host: Windows (Docker Desktop)

Image: 3dgi/roofer:develop

Command (single-threaded + pinned math libs):

docker run --rm ^
  -v C:\Users\XXX\Github\LOD2\data\docker_test:/data ^
  -e RANDOM_SEED=42 ^
  -e PYTHONHASHSEED=42 ^
  -e OMP_NUM_THREADS=1 ^
  -e OPENBLAS_NUM_THREADS=1 ^
  -e MKL_NUM_THREADS=1 ^
  -e NUMEXPR_NUM_THREADS=1 ^
  3dgi/roofer:develop roofer \
    -c /data/config.toml \
    --jobs 1 \
    --loglevel info

What I’ve tried:

Single-threaded Roofer: --jobs 1

Env vars to avoid hidden parallelism: OMP_NUM_THREADS=1, OPENBLAS_NUM_THREADS=1, MKL_NUM_THREADS=1, etc.

Fixed locale: LC_ALL=C

Fixed “seed” envs (RANDOM_SEED, PYTHONHASHSEED) — I understand Roofer doesn’t expose a --seed, so these may not affect core steps.

Ensured byte-identical inputs and stable layer selection in config.toml.

Is it even possible to get to that point or are the random seeds generated too deep in the code?

Thanks :)

Léandre

[Ylannl]

FYI those environment variables will have zero effect on roofer.

Deterministic / bit-for-bit identical output has not been a hard design goal, so this is not guaranteed at the moment. May I ask why do you need this?

[LeandreSassi]

Thanks! This would help with end-to-end tests, we could run Roofer a few times with the same params/inputs and just deep-compare the outputs to make sure it’s consistent.

[FLeroux23]

Concerning this thread, I’d like to add our organization’s view on this. We are currently looking into roofer’s potential by testing what minimum lidar specs we actually need to generate 3D building models of sufficient quality. We are comparing different lidar projects, playing around with simulated degradations (like point density, noise, missing data) and looking at different sensors and acquisition setups. We might even possibly produce an article out of this.

For this kind of work, having deterministic behavior would be huge. If the exact same inputs and settings keep producing different results, it becomes very difficult to distinguish the effects of the lidar data itself from the random noise introduced by the reconstruction pipeline. A deterministic mode would be invaluable for comparative testing, let alone for keeping things scientifically reproducible.

[Ylannl]

Thank you for adding your view. I want to put this on the roadmap for roofer, it will be useful for development and debugging as well. Can't promise when it'll be done though, depends on available resources.