Dirt - Sparks - Code

Self indulgent rambling. Minimal redeeming attributes.

HomeHome

Simulating surface water flows

Stu Pocknee
Stu Pocknee
tags coding , precisionag , dirt

It has been over a decade since I laid down the first lines of code for T3RRA Cutta (or, as it was then, Terracutta).

From the beginning, I thoroughly enjoyed the algorithms and logic of terrain management applications.

There is a purity and simplicity to working with elevation that you do not find in other precision agriculture applications.

Biological and agronomic systems are often necessarily characterized by chaotic uncertainty.

Terrain related work tends to incorporate more quantitative precision.

The explicitness of this suits me.

The problems Terracutta needed to solve, and the solution paths required, were obvious. Challenges were involved, but the clarity of purpose made for enjoyable coding. Better yet, the product was well received right out-of-the-box, so ongoing development was assured.

Early on, I created a surface flow simulator. Not everyone can easily interpret the patterns of a 2D elevation map. Having an animated model of water flowing over the terrain helped people to instantly relate. It was (and remains) a brilliant validation tool. Many customers have expressed how accurately it reflects what they observe in their fields. In terms of instilling confidence in the toolset & data, it has proved very effective.

Where did the idea come from?

Most field leveling is performed with an eye to altering water relations. When creating software to design a new field surface it makes sense to provide tools that measure the effect of terrain on water movement.

My graduate school GIS training had exposed me to something called a Topographic Wetness Index (TWI). This map layer attempts to describe the spatial variation of soil moisture in a landscape. It does so by using area and slope to calculate water accumulation and concentration. Although simple, it was never compelling to me. TWI maps do not meet my intuitive expectations. The reasons for this exceed the scope of this post, but relate to the inability of TWI to account for the cumulative dynamic properties of water flow.

Accordingly, I was curious to see if I could come up with something better.

A Wetness Index layer. From [TOPOGRAPHIC ANALYSIS AND HYDROLOGIC MODELING FOR PRECISION FARMING](http://fatra.cnr.ncsu.edu/~hmitaso/gmslab/pfarm/farm1.html)

I wanted a way of visualizing surface flow that accounted not only for the effects of topography on individual water "particles", but also the changing nature of that effect as water pooled, ponded, and (in effect) started to create its own surface topography.

To achieve this, I had nothing but some basic intuition and a "have-a-go" attitude. The exact methodology I created is proprietary, however the basics are straight forward enough. My method uses a mix of 3 dimensional game physics, cellular automata, and Markov Chain Monte Carlo simulation. At the time I was blissfully unaware of the relevance of any of these, so simply started from scratch. Happily so, as the challenge of first having to study these techniques might have put me off completely.

In the gaming world there are things known as "falling sand" games. Although conceptually a bit simpler, these utilize a lot of similar ideas.

A basic falling sand game. From https://artsology.com/sand_painting.php.

This was one of those happy circumstances where instincts and elbow grease almost immediately paid dividends. Within a day of dabbling, I could tell that my creation was not only going to work, but that the results were probably better than anything I could have expected. As the individual water particles slipped off high points, and collided with other particles, realistic patterns appeared. Topographic details jumped off the 2D maps in unignorable fashion. From the chaotic motion of millions of individual particles, a complex story of inflows, accumulations, and outflows magically emerged.

'Before and after' on a field with a 'plane-of-best-fit' design applied. If it looks fuzzy, full-screen it and force it into 1080p mode.

To be clear, this is not a hardcore fluid dynamics model. It is not the type of tool you would want to model municipal flood levels with, or take to court to dispute downstream water damage. It is a simulation that prioritizes speed, simplicity, and visual-relationship-discovery over real-world accuracy. Complex emergent behavior is created, but insufficient inputs are utilized to expect a true digital twin of reality.

There are many, many factors it does not attempt to take into account. Just a few of these include:

The algorithm has no concept of time, just model progression. For this reason, drainage times need to be treated with caution. It is probably valid to ask "How much quicker (in percentage terms) will the proposed design drain water compared to the natural surface?". It will not answer questions like "how many days after an irrigation event will the field be dry enough to work?"

'Before and after' on a field with contour banks (terraces) added. If it looks fuzzy, full-screen it and force it into 1080p mode.

From the beginning it was clear there were ways of improving and extending this tool. The realities of small business often means that "good enough is good enough". Unfortunately, this has meant that my explorations with this concept have languished the past decade or so. Having more time on my hands of late I have circled back, and am a bit excited by the possibilities. We will see where it leads...

. .