The Transit Argument for Space Cities

I want to talk about a billion-person space city. These days, we often use the word space "habitats", which would be the livable volume in an engineered structure. In various cases I'll compare here, a city is a continual habitat, or a cluster of independent habitats that people can move between. The important thing about calling it a "city" is being a connected cluster of living spaces.... and a big one.

We might as well assume the location is somewhere in the Earth-Moon (cislunar) space. To fit the premise, a billion or more should be able to live there, and can commute to another part of the habitat on a daily basis. This distinguishes other visions where a cluster of habitats might exist, but one could not reasonably commute between them daily. That might describe some classic ideas of "flying formations" of rotating habitats.

Why Cities Matter

The real value of a city is not people per square mile. It is jobs, services, and culture (food?) reachable within bounded time. All of those things are complex and messy, but in the big-picture simply scale with the number of people. Thus, the approach I'm going to take is to give the number of people that can be reached within a certain time in transit. All of the other less quantitative sources of value can be said to flow from this.

I've put together some data and scripts to attempt to do this for 6 major cities of Earth, as things stand today. The approach here is a good-enough approximation in order to slap easy numbers on the matter. It takes some real metro stops, with known travel times, and then multiplies out the resultant area by expected population density. This gives the number of people that can be reached traveling to that stop and a time, making 1 data point. Repeat over and over again to get complete data sets.

https://github.com/AlanCoding/gravitational-balloon-mathematics/tree/master/transit/transit_argument

After reviewing the data, I would say that the single least satisfying thing about these results is that it assumes you are downtown in these places. Not only does it assume you're downtown, but that you're basically already inside of the best-available train station. This is not at all how life actually plays out and in Manhattan you're looking at a solid 20 minutes before you even get to that place. All of this is just to explain the unrealistically good numbers. If you add 20 minutes on the top of all of these numbers, it starts to feel more realistic. And that's if you live downtown to begin with! In real life most people are pushed further out from the center, making the curves even worse, by a large margin. Nonetheless, this is still something, and the curves give some satisfying combination of density plus transit capability.

Reachable Population of Earth Metros against Transit Time

This satisfactorily captures current Earth. What can we build in space?

In-Atmosphere Gravity Tubes

For this analysis, I'm assuming 250 meter radius tubes inside of a pressurized vessel in 1km x 1km x 1km lattice. Each tube is home to 1,000 people, making for 1,000,000 tubes in total throughout the volume. I'm using the assumption that people commute from their home tube to some other random tube every morning. They have to ride shuttles and transfer to others. This is done in the microgravity environment through the lattice, and uses different tiered shuttles. These shuttles (like the people) float in open atmosphere, they could use fan control or they could grab onto wires.

• local_float_shuttle: span 1 cell, 1 km hops, 22.2 m/s, 24 people capacity
• regional_express: span 5 cells, 5 km hops, 60 m/s, 192 people capacity
• trunk_axis_line: span 25 cells, 25 km hops, 140 m/s, 1,536 people capacity

Since 1 km is a single lattice, the local shuttle stops at every single tube, which you would expect. The faster shuttles are not unreasonably fast either. The entire structure is 100 x 100 x 100 habitats, so a 25 km hop is going 1/4 the entire edge length. Note that realistically the pressure vessel would be spherical but I'm using simple math here.

The simulation accounts for stopping time and transfer using a constant time for transfers. What does this get you?

Reachable Population of 1 billion Person Space City vs Earth

Same Graph in Log Scale

This is the "wow" factor of the whole idea. You really could transfer within the billion-person city reasonably morning and night. But this undersells it. See reference:

Bettencourt et al., “Growth, innovation, scaling, and the pace of life in cities” (PNAS, 2007)  

The key idea there, which is widely accepted, is that cities are super-linear. As agglomeration happens, the efficiency of delivering increases. Economic output increases faster than population by itself does. So the comparison isn't just 30 million versus 1 billion, but a factor higher than that. More to the point - there is a valid argument that a 1 billion person city will be more compelling to people than Earth cities. This is the transit argument.

If you read the log-scale plot really closely, you might notice that the space city actually reaches less people at small transit time. This is consistent with my assumptions of the city being rural-urban in nature. Specifically, I'm thinking that population density would be on the order of 1,000 square meters per person, or somewhere in that range (most of the current simulation is not exactly specific about this). This is more than comparable Earth metros, so on that factor alone it is expected that the short-time part of the graph favors Earth. Also, due to the lattice spacing itself we have a smaller local density. Basically we are not packing people in really tightly in all the assumptions. You could have assumed otherwise, but this isn't actually a negative. The combination of access + space is something that is actually unique to possibilities in space. That just isn't possible on Earth at all, because of gravity. This is another key reason to believe such space cities will be more compelling to live than on Earth.

In a future post, I hope to go into detail about the alternative where habitats are conventional O'Neill type designs, each having their own atmosphere. So that case requires docking to leave or arrive. But this can still form a 1 billion person city. It's just a little different.

Water Cooled Gravity Tubes

 The standard idea presented on this blog includes some of these following points, relevant to the argument I want to make here:

• A very large outer pressure vessel holds in air, and the space inside is micro-gravity as the outer pressure vessel does not rotate
• Tubes inside rotate to provide gravity
• The tubes are surrounded by nested flow dividers to make fluid forces workable
• People, cargo, and many utilities go in and out via 2 openings at either side of the tubes

On that last point, the movement of air removes the heat produced in the tube and the excess CO2. I wrote about the thermal limit that this imposes here:

https://gravitationalballoon.blogspot.com/2014/12/natural-circulation-heat-removal-from.html

Here, I will revisit that, and add a new idea that breaks the upper limit. For the numbers, I'm using this script:

https://github.com/AlanCoding/gravitational-balloon-mathematics/blob/master/thermal/gravity_tube_scaling_sweep.py

(I am using AI for many of my scripts and data generation now, but not having it write for me)

In all cases, that script assumes a heat production of 20 W/m^2 on the inner surface of the rotating tube. This is much lower than the 400 W/m^2 number for Earth equator, but still probably a dramatic under-estimate because it is not thought that people will grow food inside of these tubes (low-g tubes specifically for farming are more likely). Given that, a rough reproduction of the prior result would be this:

Air velocity through the access opening, acting as inlet/outlet

A couple of numbers and assumptions here:

• L/R, length over radius for cylinder, is 2.0
• q'', mentioned above, 20 W/m^2
• Air Delta T is 5 degrees F for comfort, 2.77 Kelvin
• 6 m/s is allowable speed for the tip of the access tunnel and air flow in/out

We don't really need to discuss population density as a real metric. Depending on the density you're interested in, you update that 20 W/m^2 number. It would obviously increase if you have people packed in living on 10 levels. Lower population levels might not _necessarily_ decrease it by much if you still expect the inside to be brightly illuminated.

So for these numbers, natural circulation is effective until about 2 km. And above, I used a lazy free jet condition. Natural circulation might only get you to 1km before it starts to heat up. This is very large. Keep in mind you have to increase the number of dividers almost linearly. So if R=250m requires 16 dividers, and R=500m requires 32 dividers, then R=1km requires 64 dividers, and R=2km requires 124 dividers. Knowing that these will require some form of stabilization, that seems like a tall order. But we don't know for sure! It could be active control by valve modulation, which scales very well, or it could even be the negative pressure design with some form of fully passive stabilization! No one really knows.

I came here to answer the absurd question of "can we go bigger?"

Let me start by rejecting forced air flow. This is probably a bad idea. Even if it allowed you to make things a little bigger (disrupting traffic a lot) that solution won't work for very long before the velocities get too big.

To go bigger, let's review the parameters that are holding us back. The 5 F temperature change is very stifling. That requires large volumes, plus the very low density of air. What could do better in both respects? Just do water cooling. For this, I'll invoke a prior post about water supply:

https://gravitationalballoon.blogspot.com/2016/03/water-sewage-service-between-space.html

You could have continuous water supply. So scale that up to supply a LOT more water, and use that water for cooling. And because people aren't in direct contact with the water, you can accept a much larger temperature difference.

Water-specific assumptions:

• water velocity 2 m/s (probably conservative)
• water temperature drop 20 K = 36 F

Now I'm going to give a very boring graph to ballpark the pipe size of a water pipe for different gravity tube sizes.

It's fully linear. And qualitatively, we have very large water pipes in real cities on Earth. About 0.5 meters is normal for water supply. But stormwater and other things will go to extreme sizes, I would ballpark at 5 meters which is a more relevant number here.

But how would this affect the rotating transfer joint for water? Well, we might sacrifice some of the center space to make this more viable because for the quantities involved it might get splashy. This might be an unnecessary change, I'm not sure.

Now for the conclusions. If a 5 meter diameter pipe is reasonable, where does that put the maximum radius under this scheme? Around 4km, which is substantially larger. Almost unthinkable. You could make it even bigger, you would just need a larger pipe. I have basically rejected the natural circulation outcome because it would make the water flow too fast. This, itself, would become a problem.

But to sanity check some things about a R=4km tube:

• population ~60,000 people
• L=8.6 km
• CO2 rise under stated assumptions, 0.97 ppm if 1 acre per person, 2 ppm for more reasonable 500 m^2/person

Even all other things being workable, the simple transit in and out of this starts to look absurd and/or impractical. The entire point of the shared atmosphere from a superstructure is to make transit fast, but you would wind up spending a lot of time in the shuttle just in and around the tube itself. That said, these sizes might still be physically plausible. Water cooling might, in general, be a good idea for all sizes. And because it is so viable, I have to change my position somewhat from 800m being an upper limit for a tube, to, I don't know what the size limit would be.

First Glimmers of Experimental Confirmation

I want to be clear that I am very bad at building things, and am humbled by the process of setting up a real experiment. A whole lot goes wrong with doing the things in practice. But I am still happy enough with how things are going to share this attempted 3-divider setup:

You can see staggered heights and radii. In my ideal world, I would have just put these carefully-measured plastic crafts into a bucket, one inside the other, and see the result I'm looking for. It hasn't quite gone so well, but I still think I'm tracking towards the data I'm looking for in the bigger picture.

Phases of Experimentation

There's a lot to think about for putting together the water-medium bucket-scale simulation of flow dividers. I usually don't really think about those things until it goes wrong when I try and actually spin it.

For the first overall geometry, I tried to do a floater-sinker combination on an open cylinder. So nothing holding the cylinder in place, just some things attached that keeps it vertical. This always went wrong because it's fundamentally not stable - it was interesting to measure significant decrease in drum speed, reflecting increased drag from the wobbling state. But even before I got far into this observation, I observed that my first choice for floater material dissolved in water. That went so badly it was almost funny.

Moving on, clearly it was time to experiment with some "spacer" approaches. I tried to Jerry-rig this with a few household items, such as toothpicks. These items were not up to the task. The one exception of note was ping-pong balls. I could believe those would work to hold a divider in place and not add too much extra friction. However, those things are maybe 1/100th the density of water, and I had more practical problem that the divider didn't extend out of the water, vertically, far enough. So with enough speed these just flew out. But a taller divider might still work. Partially sinking the balls was a cute idea, but if it works, it requires less-sticky materials than what I have.

Still not realizing exactly the extent that stickiness (general friction coefficient) is playing, I tried some cardboard spacers. In retrospect, why did I bother? It gave me some good numbers on what happens when something substantially increases the friction the motor is seeing.

This all led to the current approach, which is to cut a circle for the top and bottom of the cylinder that has a hole in the center just large enough to let the metal shaft through. This seemed to address the wobbling issues I was seeing. But the first time, I incorrectly made the thing too short.

In the meantime, the drum itself had a tremendous amount of wobble because I was just bad at drilling the holes. After getting some help with re-doing that, the reference speeds showed dramatic improvements and the fluid movements were a lot more gentle.

Finally, to what was hopefully my last critical oversight, after building the 3 color drums, I included a spacer on the bottom for the drums to "sit" on. I did not realize that they didn't need to sit at all. After a certain speed, there we get a significant lifting force. If you look at what I just wrote on the negative pressure designs, this is already foretold. Fluid forces will push the ends in if the dividers are open to the fluid. Well the connection I'm using is definitely not water-tight so we can be pretty sure this is happening. Because only 1 of the 2 cylinder's end are under water, this... pushes it up. There was nothing to stop its movement up, so the "hat" I created for them would all start flying off and everything went off the rails.

Pretty Sure Working just a Little Bit Now

To set expectations, I have ran a few references with water and no water in the bucket. This gives a sense of the fluid-dynamic specific contribution to the torque. The speed moving the drum (due to the bearings and stuff) was quite significantly less than the motor free spinning the shaft.

For adding a single divider, I have a best-case scenario of adding about 4 RPM speed. This is if the divider itself doesn't add additional friction (which it will) or generally cause chaos as all the other experiments have.

Running all 3 dividers nested in each other (before the hats flew off), it was hard to tell what was going on but speed measurements seemed to be at around parity with the reference. This was encouraging. I did another go with a single divider, and again, before the lifting problem it seemed to be touching parity or maybe sometimes just a little better. It was unclear when the lifting problem was becoming terminal so it's hard to say what range the effect was expected to be measurable.

So onto this configuration, where I might have corrected enough things for it to not be terrible.

Just running with the middle divider present (blue). Down at the bottom, there is a spacer both under and above the bottom circle of the drum. I obtained some numbers, and they're not much:

V	Reference	With blue divider
6	135.8	135.4
7	159.4	160
8	183.5	184
9	207.1	207.6
10	232	233

But we are now hitting around 1 of the 4 RPM. I'm using an automotive tachometer, and because it's doing a timing measurement, I actually believe it is accurate to the 0.1 RPM. The larger problem is the physical speed stability, and it tends to get worse before the dividers break apart. Otherwise it is >1 RPM roughly, in good conditions. So this still might be better to call it a statistical suggestion of a speedup.

I need to go higher voltage & speed, but still have a problem with the hat flying off... right around the 10 V mark, which is also the speed the expected 4 RPM speedup would apply to.

This is still extremely underwhelming, but these experiments have seen a gradual improvement from the dividers making the speed drop, to reaching parity with the reference, to now, maybe just dipping into the improvement territory. Still lots of build quality issues to address. Once I get a much more satisfying speedup, and generally ability to spin the thing faster, that will open up a number of theoretical questions to testing.