Let me just quickly clear up one misunderstanding from early in the thread thats been bugging me:
Of course the reason why DF handles aquifers as being spawned from water producing stones might be because it hits an edge, practically an empty void, and would dry out without these stones.
You're *way* overthinking things. Like so many things in DF, the current aquifer setup is just a placeholder. The reason their behavior doesn't make sense is because Toady hasn't yet gotten around to giving them "real" behavior. He might not have even gotten around to *considering* what that real behavior should be (which makes it *our* job ). On the one hand that means that we're basically free to propose any redesign we want, on the other it means that anything we propose is going to take more CPU cycles than "fuck it, just spawn water" currently does.
Aren't we already pretty much doing that?
Also, aquifers don't always stretch all the way to the map edges. The fact that they *usually* stretch that far might indicate some shortcoming in the world geology. If possible, some geology-minded types should get DFHack, embark on some varied locations, run "reveal" on the map, and report back on whether the distribution of liquid-permeable rock and soil is realistic in DF.
Wait, hold on, I would have thought that groundwater would spread out to more or less wherever it could. Why shouldn't the aquifers spread to the map edges, barring impermeable rock or something in the way?
I want moving groundwater!
I like the idea of making things permeable to liquid, and then using the existing liquids code to make water move through soil, and letting aquifers be a natural result of that flow instead of artificial constructs. Just for fun, I'm going to throw out a possible implementation to discuss:
Pause: I suggested pretty much this a bit ago.
Implementation:
Give each map tile a permeability representing how quickly water flows through it. Permeability would be determined more or less by what material that tile is made of. Lets say we have 8 levels of permeability to start with.
When it comes time to run the water simulation, water in completely empty space gets calculated every n ticks, and as tiles become less permeable the CPU calculates their flow on progressively rarer occasions. Try the following on for size (According to the wiki: 1200 ticks per day in fortress mode, 33600 in a month, 403200 in a year.):
- 0: calculated every n*1 ticks. Water flows freely, as through empty space.
- 1: calculated every n*10 ticks. Flow is impeded but continuous, like water flowing through a fortification, or a pipe (if we ever get plumbing...)
- 2: calculated every n*100 ticks. Leaky roof. Loose sand. Will flood a tunnel almost immediately.
- 3: every n*1000 ticks. Soil. Water filters slowly through. Workable, but requires constant pumping if you don't want the place flooded.
- 4: n*10000. Loosely packed soil and rock.
- 5: n*60000. Thicker soil or rocks.
- 6: n*100000. Thickest soil. Very slow. I've heard that in real life it can sometimes take months for water to seep all the way down to an aquifer, but I can't find any useful sources of information on this. How long does it take water to get through different types of soil?
- 7: Never calculated. Waterproof. Ex: Obsidian, Resin or tar-sealed walls
Why not just every n(10^x-1) ticks, and have 0 be impermeable?
Advantages and cool stuff:
Lets combine this aquifer idea with one other simple change: Cause rain to leave behind the occasional 1/7 or 2/7 water puddle on the ground. Suddenly we get some very cool results.
Pause: I think that, rather than having every tile checked for a chance like I suggesed above, every 6X6 or 12X12 tile should be checked every so often and have a chance to put a puddle there.
- Aquifers could be drained for mining, but the difficulty is in proportion to how wet the area is. Armok forbid you try to drain an aquifer on the beach, or on an island.
- In very heavy rains the aquifer could become fully saturated, resulting in the flooding of low-lying areas. Over-saturated soil would start to exude water, causing stagnant pools to form naturally rather than on embark, and causing the soil to be wet and swampy. Once the microgeology simulation is a bit more detailed we might even be able to get natural springs.
- Aquifers could be emptied through overuse, allowing wells to run dry. In dry climates the player would have to protect their aquifer and maybe even look for ways to manually recharge it (Like pumping from a river in a neighboring biome).
- Picture this: A rainstorm occurs in a mountainous area of your site. Since water can't drain into the impermeable rock, it water builds up and starts flowing, forming a short-lived stream down the mountain (and possibly a mudslide in future versions, once mud becomes a fluid!).
Heh. All of those sound...amusing. You've really thought this through.
Questions:
- Should permeability be stored per map tile, or per material? In programming terms, if we're going through every map tile once per tick, is it ok to call better to access tile.mat.permeability a few billion times? Or is it faster to just access tile.permeability? and is that speedup worth adding an extra 200KB per embark-square to a site?
By material. It's probably easier to remember. Maybe giving each tile a specific value on embark would make it faster; I don't know. If so, try that, but I think that, for reasons of simplicity, each soil or stone type (as well as everything else that walls can be made out of) shoud have a specific permeability number.
- How many levels of permeability should there be? This is particularly important if we are storing the information in individual map tiles. Too many permeability levels could push a lot of embarks over the 2gb limit.
- Is my n*x progression reasonable? It will probably have to be adjusted depending on how long it takes water to flow through different real-life materials.
Hm. Well, I suppose it could be something like...well, one level for impenetrable, and a total of 2^n-1 others, so...sand, soil, clay, permeable stone, stone, wood, metal...seven layers of permeability plus impermeability should work fine.
- I just realized that I can't think of a way to ensure that flow in a certain tile is only calculated ever n ticks without putting a counter on each individual tile, which would be a nightmare. I'm going to post this anyway, and really hope that someone can think of a way to make it work.
Maybe...no, if it's calculated at varying speed that won't work. I have no idea.