Add patch-based generation for improved statistical convergence in Random Midpoint Displacement (RMD)

[sbrandstaeter]

Description

When using the Random Midpoint Displacement (RMD) algorithm to generate rough surfaces, generating the surface in multiple patches — rather than as a single continuous surface — significantly improves the statistical convergence of the height distribution toward the expected Gaussian profile.

Dividing the surface into patches (each generated independently but with the same Hurst exponent and resolution) yields better ensemble statistics. This approach appears to mitigate some of the known limitations of standard RMD implementations that generate the surface in a single pass, where the resulting height distribution often deviates from Gaussian behavior.

Question:

Does the current implementation in MIRCO support patch-based generation for RMD surfaces?
If not, I’d like to suggest adding this as a configurable feature — allowing users to specify the number of patches (or patch size) at a fixed global resolution. The patches would then be combined to form the final surface.

Proposed enhancement:

• Introduce a num_patches or patch_size parameter in the RMD generator.
• Ensure each patch uses the same Hurst exponent.
• Seamlessly combine patches into a single continuous surface at the end of generation.

This feature would improve statistical robustness and make RMD-generated surfaces more consistent with theoretical expectations.

Example implementation:

An example of a Python implementation of the RMD algorithm with patches (done by @jacopenji ) can be found here:
https://github.com/sbrandstaeter/deep_sim/blob/paper-rebuttal/pydeep_sim/rough_surface/patches_generation.py

Related Issues and Merge Requests

• Blocks
• Is blocked by
• Follows
• Precedes
• Related to
• Part of
• Composed of

Additional Information

Interested Parties

@jacopenji

[jacopenji]

Another possibility, leading to same results and perhaps easier to implement consists in generating a set of surfaces of the same desired size, and then average them. This should get the homogenized surface rid of the long wavelength effect related to the first iterations of the RMD algorithm, which in turn determines the deviation from the desired statistical behavior.

[mayrmt]

Independent of the actual algorithms, I find it crucial to consolidate our software implementations: there must only be one, well maintained surface generator, so that we all use the same algorithms and do not have to chase bugs and bring improvements to multiple software frameworks.

Therefore, I propose the following: let us implement a surface generator in MIRCO. We should have a single implementation of a function, that generates the surface. This function can either be called from the MIRCO executable to generate a surface at runtime or it can be called from a separate executable (defined in the MIRCO repository), that generates the surface and writes it to a file on disk. This file can then later be read by MIRCO, for example to make sure that every call to MIRCO uses exactly the same surface.

[jacopenji]

Having a centralized surface generator is definitely good. We can shortly discuss which kind of process we wish to follow to synthesize the surface and then proceed. Possible steps to follow:

• @ALL: think about what we want exactly;
• @jacopenji: provide codes (most likely Python) for surface generation;
• @mayrmt and @PhilipOesterlePekrun: think about the architecture of this extension;
• @PhilipOesterlePekrun: actual implementation.

Let me know if you find it reasonable and if you have any comment, remarks, etc.

[PhilipOesterlePekrun]

@jacopenji If you are thinking of making a surface generator in python, it is already possible to take such a surface as input for the program, by using a .dat topology file which is basically the heightfield. See e.g. Input/input_sup5.yaml and Input/sup5.dat. If we want to implement different surface generators in C++, we could make the choice of generator an option in the .yaml input file, and also parse for the relevant inputs for that particular surface generator. It can also be provided externally in the form of a ViewMatrix_d. If we just want to change the MIRCO::CreateRmgSurface() algorithm, that is easy to do.

I'm quite sure there will be some restructuring of the input so that MIRCO fits cleanly into 4C as a library, which is what I am currently working on.

[mayrmt]

@jacopenji thanks for outlining a plan to realize this feature!

@PhilipOesterlePekrun the idea is to have one surface generator here in C++ in MIRCO, so that it can be called either from MIRCO at runtime or as a stand-alone tool to create a surface and write it to file, such that MIRCO can read it from file later.

While @jacopenji is currently using the workflow "write-file/read-file", the Python implementation works just fine. However, for MIRCO to generate surfaces at runtime, the surface generator needs to be implemented in C++, so that MIRCO can call it (without having to call Python from C++ -- yes, that's possible in theory, but adds additional software complexity).

For generating the surface at runtime, it might make sense to generate it on device, so that we reduce the number of host/device synchronizations. However, that's a detail that @PhilipOesterlePekrun and I can discuss offline.

[PhilipOesterlePekrun]

@mayrmt Ah, I see. That should be easily doable--essentially a main() which calls CreateRmgSurface() and a function which writes the topology to a file. And yes, I think I can convert the generator to run on device. If we are rewriting the algorithm to match the python script of @jacopenji, then we can do that then.