Water Flow on Surface

unhandled

(David S. Mavrov) #1

Is there any way to calculate the rain runoff for any given surface (imagine a simple dual pitch roof for example)? I have tested several plug-ins like Mosquito and alike. The drain directions (flow paths) are good on most of them, but I haven’t found a solution which will calculate the amount of water at the drainage points.

I am not posting any geometry, because my question is more or less general.

Thank you in advance guys!


(IVELIN PEYCHEV) #2

Calculating the amount of water.

http://www.1728.org/flowrate.htm

If you know the diameter and the speed you can get the flow rate


(David S. Mavrov) #3

This is easy, I am not looking for that. A step before.

This is what I have:

And this is what I am aiming at:

All in all, I need to know how much water I will have to take care of and where.

As I have said the next step is easy, but thank you!


(David Rutten) #4

So the samples along the edges basically measure the area of the shape that drains into it? And probably only 2D area at that? Is water momentum taken into account during the flow, or is it just assumed to drain in the most downwards possible direction?


(David S. Mavrov) #5

This is mostly for doubly curved surfaces. I believe it is assumed to drain in the most downwards direction. Still good enough for me at this stage.


(IVELIN PEYCHEV) #6

Without knowing the amount of rain fall, speed, direction all this is very vague.


(David Rutten) #7

It’s certainly an interesting problem, and not all that trivial.

My first approach would be to generate a bitmap of the top-view of the shape, sampling each pixel and seeing in which direction it flows until it hits the boundary. You draw the entire path it takes using a colour that identifies it as belonging to its end-point. Then repeat for every pixel in the bitmap, and an optimisation there is that as soon as you hit an already computed pixel you can just copy it.

This is inherently an inaccurate sampled approach, but given that the model isn’t a perfect representation of reality anyway that doesn’t really matter.

Afterwards you just count pixels of a specific colour to figure out the area of the basin associated with a specific end-point. This gives you an approximation of the 2D area, but then that sounds correct as you don’t get more rainfall on slanted surfaces, except if you take non-vertical rain into account.


(David S. Mavrov) #8

Guys, good points. Actually this really sounds more interesting than I have initially thought. I have to research which factors must be taken under account so a realistic result could be achieved and by what method. Hope someone will enlighten me on this here though.


(David Rutten) #9

It’s a bit late in the day, but I’ll see how far I get in the next hour or so. I need a fun coding challenge after today’s github woes…


(IVELIN PEYCHEV) #10

Try this one:

among the examples there’s one particle gun, you can use it direct it top-down on your roof and you will see how much particles are falling from your roof and from which side.


(David S. Mavrov) #11

I have already done this part and yeah even with flexhopper. The point is to represent the liters of water (given the amount of rain fall for a given location) at the point where the flow curves exit the surface. And I want to represent them with vectors. So if we have 10 liters of water, the vector at that point will be 10 meters long. That’s more or less what I miss.


(David S. Mavrov) #12

Thank you! You are awesome to me as always. To be clear, I don’t want you to do my work for me. Just point me at a right direction.


(IVELIN PEYCHEV) #13

you can bake the particles in FlexHopper in real time. simply place as many collectors as you want (to designate the arrows). Then count the points in each collector, divide by the number of collectors and you’ll have a ratio to define the length of the arrows.


(David S. Mavrov) #14

That could work…


#15

Not sure if this is helpful, but might inspire some ideas:

I recently re-wrote a simple “particle descending down a surface/mesh drainage”-type script (that looks like a similar approach to your first example) for use on a project, and extended it with what is essentially a heat map visualisation of the drain polylines density (second image in the Instagram post):

I basically snap the drainage polyline vertices to the nearest face center in the heat map mesh, and then count how many points are at each face (i.e. how many drain paths flowed through it). Obviously this doesn’t take volume, physics etc into account, but might still be used to differentiate between places of high and low runoff (though in my case, the particles doesn’t actually flow off the terrain, need to add that come to think of it).

My colleague is currently working on implementing the Catchment Modelling Framework within Grasshopper/GHPython. So hopefully there’ll soon be some physically accurate hydrological models as well (I believe this will be made open to the public).


(IVELIN PEYCHEV) #16

If the mesh vertices are not homogenously distributed will this impact the final result?

(btw this picture is creepy :slight_smile: )


(David Rutten) #17

First sort of working test. Still plenty of bugs left, but it’s getting time for me to go home.

The colour in the image is just a straight map from mesh face index into RGB, and since the mesh is fairly small it only shows blue colours.


#18

The mesh (or surface) used for the flow/drainage stage is independent of the heat map analysis/visualisation stage, but of course the two will have to be fairly geometrically close (locally/spatially) in order to be meaningful.


(David S. Mavrov) #19

@AndersDeleuran why I am not surprised that any trouble I face, you already have dealth with and discovered a range of solutions :smiley: I imagine working with you is quite the trip. Always a pleasure hear what you have to say and show :slight_smile: Thank you!


(David S. Mavrov) #20

I had no idea you can achieve it using a method like that. Trying it ASAP! Thank you David!