- v50 information can now be added to pages in the main namespace. v0.47 information can still be found in the DF2014 namespace. See here for more details on the new versioning policy.
- Use this page to report any issues related to the migration.
User:Jfredett/Plumbing
WRT plumbing, the setup I like to use works something like this.
Overview
Depending on the location of your watersource (mine tends to be a UG River or an overground river, but in any case), you will likely need to pump water up/down to truly effectively make use of it. In my forts, I tend to have an active overground presence, I keep my farms, barracks, dining hall, crafts, and butchery/leather chain almost always above ground (though not necessarily outside. I find that this setup (with workshops directly beneath it, and furnaces/metalcrafting going on directly below that (usually in range of a magma pipe, sometimes some pumping needs to be done)) leads to a nice "clustering" of resources that minimizes need for multiple stockpiles, increases efficiency, etc (For those interested, I keep the bedrooms on the third floor up from the bottom).
To this end, I really want to put my well/water source on the top floor, near to the dining area, barracks/hospital, etc. This is means I need to pump/redirect water from whereever it is to this area. With an overground river, one can generally just redirect water through some fortifications outside of their main wall into a pool, something like (side view) :
| W | |---------------####----| ~=~~~~~~~~~~~~~~~~~~~~~~~| -------------------------
Where
| : a wall = : a fortification W : a well - : the ground # : grates
This is fairly standard, and it's not particularly difficult to redirect a river (or even damming the old outlet of the river afterward- that's another story though...). However, pumping water up from an underground river leaves one with other considerations to make.
- Are we going with powered or manual pumping? Generally you'll want powered pumping for the main cistern, but you may want to use manual-only for the well to prevent overflows. You could also use a more complicated "autofill" system using pressure plates, but I won't go into that here.
- How much water should we store? Each level will be filled to pressure, but how big should those rooms be. This also plays into the next point- about "unfilling" in the event we need to do work in/extend the current system.
- How should we drain the system if the need arises?
Further, we need to worry about controlling the intake tunnel, setting up a power structure, etc. Obviously we want to minimize the number of axles/gear assemblies we use, since those increase power overhead.
One simple design is to simply create a shaft with pumps filling a series of stacked boxes. This method is simple, but somewhat featureless. We can get the water from A to B, but what about draining? What about controlled filling, eg, filling only certain parts of the shaft, and not the whole thing? For this, we need to have a more complicated design. Principally we need to think about two things:
Intake
Let's assume we're drawing from an underground river, since pumping is almost certainly a necessity in this case. We'll assume an ideal case, where we can easily build perpendicularly to the river, in the event you can't, it's not difficult to adjust these plans, even if it is a little more difficult to construct the appropriate filters.
Here's the map:
############################################ 77777777777777777777777777777777777777777777 77777777777777777777777777777777777777777777 77777777777777777777777777777777777777777777 ############################################ ### #X# #X# #X# #X# ###
Symbology should be fairly obvious, but here's a key:
X : up/down stair (or whatever) # : wall 7 (or some number) : water at a given (listed) depth.
The simplest intake system is simply a shaft into the wall, use a channel 1 z-level above to cut it on, and some fortifications to prevent any unwelcome guests. However, this misses a brilliant opportunity to not only save on power, but generate all you'll ever need too. For example
############################################
77777777777777777777777777777777777777777777
77777777777777777777777777777777777777777777
77777777777777777777777777777777777777777777
###################__#######################
#FF#
#GG#
### #__#
#X#################__#
#X................D__#
#X########.########__#
#X# #.....# #WW#############
### #.....# #WW=====*=====*#
#.....# #WW#####|.####^-main power
#L...L# #WW#####|.#
####### #WW=====*.#
#WW#####|.#
... etc ...
X : Stair
# : wall
| : NS Axle
= : EW Axle
* : Gear assembly
W
W : Water Wheel
W
F : Fortification (here it spans 2 levels)
G : Floodgate (this is 1 z-level below, just wanted to avoid needing 2 maps)
Using a pair of levers here to control main power (all routed through one gear assembly) and one for water intake (through the floodgates). In the event you decide to dam your UG river (which can be done, but that's another post), perhaps so you can (safely) redirect it to be in a nicer location, you may want to replace the top level of fortifications with walls.
This design is nice because it leaves us with an iterable (you can make the shaft with the waterwheels as long or as wide as you like. I typically use a 3x5 design, the first power unit will cost 30 units of power (30u) to run, leaving me with an total generation of 270u for the first row, each additional row costs 22u, so my total system costs 30u + 22u + 22u = 74u, and generates 1500u, for a net of 1426u total power generated. Now we can talk about pumping water through the levels.
A naive design is as follows:
...outside world... Z-level n #D# #*# ##|### #_XX.# #####.#### #........# #........# #........# #........# ########## Z-level n+1 #D# #*# ###|## #.XX_# ##.####### #........# #........# #........# #........# ########## XX : screw pump, pumps from the side with the channel. D : a door
This system is "good enough" for simple use, our goal will be to make some simple improvements. Note that, since stone is so
unbelievably abundant, we just prefer to disregard the cost of mechanisms entirely. In fact, we disregard cost in general, especially when we talk about using computing here.
First, we aim to design a system that's complete- but "unsafe" in the sense that it will allow for -- potentially -- opening up the flood valves and backflooding into the fortress, then we will talk about using computing/logic gates to prevent such dangerous behavior.
Extending the cistern design
We're looking to extend some useful features into the cistern design. The first obvious improvement is to add a floodgate to bypass filling the main cistern entirely.
#D# #*# ###|## #.XX_# ##F####### #........# #........# #........# #........# ##########
This allows us to potentially drain a particular cistern, or force filling of the top cistern before the ones below them. Drawbacks include not being able to force drainage automatically, and not having planned access to the tank even after it's drained.
These are easily remedied, first we can add an access hatch.
#D#### #*...# ###|##.#### #.XX_#....# ##F#######.# #........F.# #........### #........# #........# ##########
I'm using a floodgate, a door will do fine, but in the future, that may not be the case, I imagine that Toady is liable to make doors leaky in the future, I imagine that would be a move in the "accuracy" direction, so this plan should be future safe.
From here, it's easy enough to add some drainage, we have some options, either a Floodgate/Channel method, which is simple and effective, but takes up some extra space, or we can use hatches, since we already take extra space (near the access channel, we may as well use it.
#D#### #*...# ###|##.#### #.XX_#....# ##F#######.# #........F.# #........### #........F_# #........F_# ############
This has some issues with digging, ideally, we want to be able to dig this quickly, clean out the excess stone, and move to the next cistern, so we want to have a rectangular dig command, and have stair access up and down. Part of cleaning can be done by using the existing stone to construct stairs, walls, etc. It won't be 100% efficient in cleaning the area, but it should minimize the work involved, here's the redesign.
####D######## #..|.....D.S# #..|*....\--# #./-|--\....# #.|.XX_|--\.# #.\F---/..|.# #.........F.# #.........|-# #.........F_# #.........F_# ############# \,/,-,| : Constructed walls. (I need to figure out how to insert the pretty ones... S : Stairs in the appropriate direction.
This system has a total capacity of 40 squares, or 280u of water. We can also extend this system to not need the access door at the top, so that instead we leave the access door only on one level, or one several levels as you prefer. Since we have this nice access, we might want to add a lever room too this design, we also need to add a back-fill cistern for the bottom level or two. We also want to calculate the power requirements of the cistern. Let's take these one at a time.
Power requirements of the cistern
Well, we have 1 gear + 1 axel + 1 pump for a total of 16 power per cistern. This is a very simple cistern, the rate of fill works out to 1 pump, which is relatively slow. We rely on the size of the cistern to help prevent overuse, Later we may explore multi-pump cisterns, but for now, a 16u power requirement is a nice feature. Assuming we build a 30 z-level water tower, that works out to only 480u of power, which, with the 1424u generating power system listed above, leaves us with 944u of power left over. If we build this structure out of magma safe materials, it is also suitable as a magma pump.
Internal controls
The benefit of internal controls is the fact that they're simple to remember, if not always convenient in the event of an emergency.
tba
Back-filling cistern
tba
to be finished