Cunjo Carl

A quasar drive would really take the cake for drymass, but the Isp should be right up there! It's funny to think for how desperate rocket engineers are to shave every kg off their rocket, that this one caries an entire black hole.

It does though! Because of einstein's mass-energy equivalence, any form of energy storage actually has mass. It's pretty paradoxical but when you solve for mass-energy equivalence as you say, despite the photon being massless the Isp of a photon rocket is exactly equivalent to a normal rocket shooting reaction mass out at the speed of light. Mass-energy equivalence applies to all forms of stored energy from radioisotopes to batteries to chemical propellants. For a fun case-and-point, let's consider a photon rocket that operates by burning and holding onto 1kg of methalox, collecting the energy and using it to shoot photons out the back. What we'll find is our rocket becomes lighter by a tiny mass 'm', and our rocket gains a momentum of m*c. Again, this is the same mass efficiency as what we'd get from a normal rocket with an Isp of c/g0. Getting started, 1kg of burning methane will look like: CH4 + 2O2 -> CO2 + 2H2O + 16.7MJ of heat Assuming by magic we collect all the energy, the products of the above reaction will be lighter than the reactants by 16.7MJ/c^2 (1.9E-10kg) because of the mass energy equivalence. I think that's amazing! The chemical reaction actually changes the total mass, despite no particles ever leaving the system. Moving on to the next step, launching the collected energy out the back of the rocket as photons will provide us a momentum of: Momentum Gained = Energy Used / c .056 kg*m/s = 16.7MJ / c .056 kg*m/s = 1.9E-10kg*c (alternatively) And finally, we notice that our rocket has lost 1.9E-10kg of mass, and gained 1.9E-10kg * c of momentum! (.056 kg*m/s = 1.9E-10kg*c) Like we claimed at the start despite the photon being massless the photon rocket has the same mass efficiency as a normal rocket with an exhaust velocity of c (or an Isp of c/g0) . Crazy stuff, right?

I'm having the craziest deja vu with this, I swear I just wrote to someone about this but I can't find it here, so maybe it was somewhere else? Anyways, funnily enough, you actually want slower photons to make a better photon rocket. Rocket engines convert stored energy into momentum (in context, our deltaV). If you look at how photon rockets work, you find: Momentum Gained = Energy Used / c (where c is the speed of light) Notice how we divide by c in this equation, so a faster speed of light means we actually get less momentum for a given energy we put into our photon rocket. Put in another way, it's because the speed of light is so fast that the TWR of photon rockets is so small. On the flipside, the Isp (momentum efficiency) of a photon rocket is equal to c/g0 (with the c on top). So scifi slower photons would mean worse Isp but better thrust. Because it's the thrust of photon rockets that hold them back, we want a lower speed of light for better photon rockets!

Thanks for asking! I wound up doing exactly as you suggested and now the question is if we need to incorporate anything else. We're measuring the thermal conductivities of a few different structural materials (like metals and thermal ceramics). We're using the unusual technique of just flowing heat through the materials and measuring the temperature difference created across them! It's less accurate and convenient than other techniques, but has several advantages in the end and provides a nice confirmation point. To make thermal contact to the materials we use liquid metals or thermal paste (like in computers). I did an initial calibration run to measure the thermal resistance of our thermal paste, but I only did two runs! The values came out very close, but 2 points make for terrible statistics. I asked the students to do a battery of calibration runs on the paste so we could make statistics, but they must have forgotten so we had no idea what variability there is in our thermal paste's thermal contact resistance. Unfortunately we can't do the paste calibration runs now because we moved the tool and it might be sensitive to its surroundings. We now have quite a few experiments with one of the test structural materials using different numbers of material layers and thicknesses (along with different numbers of paste layers). So the question is if we can do multivariable regression to separate the effects of material thickness and paste layers. I went ahead and did the multivariable regression by hand, and it looks great! The residuals make a beautiful Gaussian curve and the p values all show signifigance, so I'm confident that it's a good application of the technique. There is an interesting wrinkle that runs with more layers of thermal paste tend to also have more total structural material thickness. I've calculated standard error in the structural material's conductivity as though the paste resistance were a known offset at the value we calculated from the regression, just as you suggested! It looks good on paper and it's as far as I've gotten. The question is then if I can get away with doing just this? Most experimentalists probably would, but I have a few weeks to play with so I think I'll plink at it a bit.

+1. Poetic.

Yeah, if the calibration files weren't hosed I could use them to treat this as two separate problems rather than one combined one. Unfortunately, that was the thing that was lost! I feel like the formula will wind up being more complicated because physically I feel like not all the error in Y should lie with either B1 or B2 individually, and maybe their errors should be added in quadrature to get the standard error in Y or something like that. Ah, man, I wish I had that kind of budget! I work for one of those small-miracles-on-shoestrings sorts of labs. If no one on the forums happens to know, I'll just have to grit my teeth and dive head first into a stats textbook!

So an experiment at work went pear shaped today when we discovered the calibration data was completely out of whack. There's a couple months of experiment data on the line, and I think I can save it by calibrating our data against itself. It would involve multivariate linear regression though, and I have a question about that. My data is a bunch of y values that vary with x1 and x2. If we put it together, and draw a best fit line for y (called yhat) it will take the nice happy linear form of: yhat = B0 + B1*x1 + B2*x2 And we can calculate the standard error in our fit line yhat by: SEyhat = sqrt( sum( (yi - yhat)2 ) ) But what's the standard error in the slope B1? If this were single variate, it would be: SEB1 = (SEyhat/SEx1)/sqrt(n-2) Does the other dependent variable x2 change this? Physically I know the degrees of freedom term (n-2) should become (n-3), but are there any other changes? Thanks in advance!

That's an interesting idea! We could even avoid the canisters altogether by just bringing up a liquid that could evaporate like like liquid nitrogen (or perhaps even water). For maximum effectiveness, we would want to bring the gas up into a retrograde orbit, so each atom will hit the satellites/debris as hard as possible. Even still, given the scale of space it would still take a great number of orbits through the gas to meaningfully slow a satellite. But here's the tricky part, anywhere near the Earth our gas atoms will drag on the tenuous atmosphere and deorbit themselves much faster than a satellite would. Meanwhile if the atoms were farther away from the Earth, they'd get swept away by the solar wind! I don't think there's any happy medium for our gas atoms to orbit stably. Perhaps this is a good thing, because if gas could orbit stably, each time a rocket burns in orbit it could smear quite the mess across the sky! The alternative would be to try to deorbit the satellite it all in one shot with tons of gas particles. A great source of directed gas particles would be a normal rocket engine! It's funny to think about the physics of deorbiting a satellite by pointing a rocket engine at it. The present ideas in progress are instead a space harpoon, and a space net. If I've understood it correctly, the idea behind the net is to attach a big high drag surface onto the satellite so it naturally drags harder against the atmosphere. They've actually even tested it in orbit!

@Klapaucius (Edit: forgot to quote) There's two tricks involved for this particular setup. It was a single craft from stock v1.0.5, I think. The first trick was that each domino is actually two connected wing pieces rather than one long one. Single wing pieces would tend to glitch out circa v. 1.0.5, so using 2+ connected objects was the best approach for domino behavior. I suspect this is still the case, but don't know! Then, you can attach the dominoes using some sort of decoupler and separate them! All of the decouplers need to be set to the same stage of course so they'll all seperate at once. I was running this on a toaster, so to avoid having spent decouplers hanging around and doubling the craft count I used pyrotechnic decoupling instead which fully destroyed the "decouplers" in the process. Each domino is connected to the next through basic fins. Each basic fin has a sepratron hovering beneath it. When you stage, the seperatron fires and destroys the connecting fins, then flies into the ground and blows up. It sounds tedious to set up, but because you can copy huge sections at a time, in practice it only took 20 minutes to go from initial concept to photo. I think this is far from the end-all be-all of dominoes, which is why I made the challenge! Still, hopefully it makes for a good starting point.

They wouldn't store energy very well, but would provide a 'good' way to convert the thermal energy of the nuke into useable electrical energy. (speaking relatively of course, most of this is just brainstorming for the fun! Given the size scales involved it would be hard to make work IRL) Once this electrical power is made, it would need to be stored in batteries or similar, which would be pretty prohibitive come to think of it. What other ways could we store that sort of energy though... I see now why you wanted the Mm piston. Perhaps rather than a mountain, if we used the energy of the nuke to push water. Ah, @Katten just suggested this. It has some real advantages for storing silly amounts of energy! Just putting some numbers on paper, the Hoover Dam in the States can store (very roughly): Energy = m*g*h 7.6*10^16J = (35.2km^3 * (10^3 m/km)^3 * 1000kg/m^3) * 9.8 m/s^2 * 220m ... relative to the 10^14J of the nuke. So maybe instead we should do something like the Hoover dam but backwards. We could find a suitably deep fjord, dam off the entrance, nuke the water out of the inside and then gather energy by letting the water flow back in from the ocean! I'm sure nothing could go wrong...

The size of a mountain, and down through the mantle... That would be some piston! Like any piston, it would need some working fluid to be moved by the energy of the blast and not just... melt. Maybe pressurized Hydrogen would be appropriate? It would be a great gatherer of neutrons, and has a low enough viscosity to really accelerate our mountain! Rather than just relying on height to store energy we might be able to save vertical space in our piston by turning it into a solenoid generator. If the mountain we're pushing were a giant magnet and the tube's walls were filled with alternating wire coils, we could generate electricity while the mountain was still on the rise using Lenz's law. It would become the world's largest generator! I'd need to think about it a while to make a real estimate, but it's fairly normal for the forces involved to be 10-100x greater than gravity, so our piston may only need to pierce the crust and not fully the mantle .

Thanks for checking in! I used to do mega projects too, they're definitely gratifying to finish- best of luck . Just thinking about it, though I liked big challenges too, I always learned a ton from doing these silly 1-2hr challenges. They're fun to read, too! I wonder what sorts of entries we'll get.

Yeah, building in sections vertically and then integrating horizontally sounds like the easy approach. Just like a submarine, right? (image from http://www.hisutton.com) Edit: I feel like I'm not writing well tonight, so just to be clear what I'm getting at, I'm thinking the easy approach would be to construct starship just like the grain bins in 10m segments, then turn them horizontal to be integrated together. The ~~10m segment size sounds convenient to me, because it should have good rigidity while being tall enough to tip easily (for maneuvering), but also not tip *too* easily like hopper's hat. I know, they'll be doing the real ones indoors out of the wind, but still, it's a lot safer to work on something that has a 0% chance of toppling no matter how you lift or load it, right? Well, I guess we'll get to hear about what the SpaceX teams have come up with soon enough! That's cool they're set to compete with construction methods, I hadn't heard that. I'll see if I can find it, but I remember Gwynne saying once that for assembly buildings, vertical and horizontal space winds up costing fairly similar, with horizontal being a bit cheaper. It sounded like you're basically paying for the volume by the time it's all told!

Domino Demo Day This is a reboot of an earlier challenge by @DoctorDavinci. Build a domino run with at least 10 dominoes, and take a picture or video of the results! You can make the dominoes out of whatever parts you find convenient. DLC and mods are a-ok, in fact I'm very curious what people can do with them! Cheats are ok during setup, but please turn them off when the dominoes start falling. Also, any venue is fine for this, but KSC does make a nice backdrop for sense of scale. Rube Goldberg machines are encouraged, but for thematic reasons the contraption must start and end with a domino. Feel free to take these words liberally. Score: Everyone gets 9,999 points- Hooray! It's really all about the spectacle.

Sorry, it looks like I should have put a </s> tag at the end of that! I think the technique in the video would be perfect for a shorter something like hopper because it's very easy to position metal sections for attaching and everyone gets to stay on the ground which lets them work faster. But, unlike hopper or a grain bin, Starship will be 16+ stories tall and made of heavy steel! They definitely won't be using jacks on it, for stability reasons if not anything else. All this said, I wonder if they'll assemble starship in rings like a submarine or whether they have another approach? Yeah, I've seen those before- they're really cool! It's a bit strange to watch a building build itself... It makes them feel eerily alive in some sense of the word, but maybe that's just me.

I just watched a video about how they assemble grain bins (silos) on site in the fields. So they won't need cranes, they assemble it one ring at a time on the ground and then use hydraulics to jack the whole structure up for the next ring. I hope Elon's taking notes... (the video, from Smarter Every Day) Edit: </sarcasm>

We could get even more permutations by crossing or splitting fingers (live long and prosper!).

Wow, funny timing. We were doing the Boron reaction last week at work! We built our parts with glue filled with Boron Nitride, a low mass high thermal conductivity powder that's very useful for electronics in parts that experience certain kinds of radiation. We, of course, wanted to see what protons would do to our parts and they came out of the proton beam "screaming" according to the tech in charge who pointed a geiger counter at them. I think it would be very hard to get useful power from though. The 8.7MeV energy isn't _that_ high, and the vast majority of protons will probably get stuck in the Boron before they can react. Once the protons get down into the keV, their range before they stop in Boron or Boron Nitride will be very short- order 1s or perhaps 10s of um just as a guess. All the electrons around the Boron just serve to slow the ~500keV protons down! Despite the high cross section (the high reactivity), I don't think the protons will travel far enough to meaningfully react. On the other hand, higher energy protons (50 MeV) can go quite far (1s of cm), but don't have anywhere as close to the same cross section (reactivity), so I think there's no good way to do it for Boron solids. Lithium though I've never worked with. I'm curious now!

There's been enough back and forth that I figured I should make a little example FEA to demonstrate the idea. And just to reiterate from before, this way of doing it is quick and simple but computationally silly! Still, excepting for some error accumulation (which can be estimated) and a few oddities (like not all directions being the same in some specific cases), it works well enough to look good which was kinda the goal! www.paikogame.com/simplefea/SimplestFEA.html I did it in Javascript for portability- the actual FEA part should be close enough to C++ that the ideas can come across. In the demo here, you can click the 'place hot' or cold buttons and click+drag the mouse around the picture to make more heat sources. There's lots of option! I went a little nuts. The actual FEA code is very short, and is in the box below. Here's the description of how it works: So the most important variables are 'now' and 'next', which are arrays filled with every temperature in our simulation. (just old and new from before). At the start of our round they're identical. The outermost cells of these arrays are 'insulator', and will always have the same temperature as the cell it touches just inwards from them (just like in real life). For all of the cells representing Gallium (cells from 1 to numCells in both x and y) we need to calculate the temperature change each round. First we doublecheck the cell is gallium and not a heat source by checking the array isSource. If isSource[x][y] is false, we know the cell is gallium and we should continue, otherwise it's a heat source and we ignore it. For Gallium, we look in all 4 directions around our cell (up, down, left, right) and for each of these directions do the following: change in temperature = coefficient * temperature difference. When you add the changes from all 4 directions together, it becomes this line: next[i][j] += coef*(now[i-1][j] + now[i+1][j] + now[i][j-1] + now[i][j+1] - 4*now[i][j]); After doing this for all the cells, the gallium will be complete. Then, we go along the 4 edges of the 'next' array and set each insulator cell there to be the same temperature as the gallium cell it touches. Again, that's just how insulators works- no heat flows when there's no temperature difference! The index for insulator on the left side of the array is x=0, and the right side of the array is x=numCells+1. Top and bottom are likewise for y. To allow for these extra insulator cells, all of our arrays are actually numCells+2 large! Now, the 'next' array has exactly what our temperatures should be for the next round. So, we step INTO THE FUTURE by copying 'next' back onto 'now', and increasing the system time by one tick. The variables: for (i=1; i<=numCells; i++) { //update temperatures for (j=1; j<=numCells; j++) { if (isSource[i][j] == false) { next[i][j] += coef*(now[i-1][j] + now[i+1][j] + now[i][j-1] + now[i][j+1] - 4*now[i][j]); } } } for (i=1; i<=numCells; i++) { //maintain temperature at insulator boundry conditions next[0][i] = next[1][i]; //left next[numCells+1][i] = next[numCells][i]; //right next[i][0] = next[i][1]; //top next[i][numCells+1] = next[i][numCells]; //bottom } for (i=0; i<=numCells+1; i++) { //Copy 'next' onto 'now' to prepare for the next timestep. for (j=0; j<=numCells+1; j++) { now[i][j] = next[i][j]; } } curTime += timeStep; Here's full the code. You can copy-paste it into a text editor, save it as an HTML file and run it from your own computer! Not sure why you would, but I need to have some excuse for using a language as knotty as JS. The 'important' FEA part is in a function called AdvanceFEA() { , and the active part of that is shown above in its entirety. Alright, time to disappear for a while and pass this torch along. Cheers!

I like it! If it pans out, it's a source of free energy that runs on Hydrogen, which I've also seen being discussed for near-future scifi. It could be used to make a rocket engine in one of a few ways: by heating a working fluid with a heat exchanger (like an NTR), by catalyzing deuterium cold fusion with muons to make a _very_ high velocity exhaust, or directly by some mechanism no one understands to make _very_very_ high velocity exhaust... probably of exotic particles. To put it short, you flow Hydrogen (or deuterium) gas onto a certain common iron-oxide surface, zap it with a low power (few hundred mJ) pulsed laser for a few minutes and suddenly relativistic exotic particles and molecules start zinging out. That's what they're seeing anyways! This kind of fringe science is normal, and most things that look like this peter into nothing. I happen to have a real soft spot for this one though; experimentally too many things line up for this for it to be easily dismissed as a fluke. Something interesting is going on, there's no doubt. Whether it's exactly as the lead proponent says though is another story entirely; I don't believe it is. Still, it should make for an excellent fringe science rocket engine for a scifi novel, and have seen it discussed as such. If confirmed, developed and scaled, the technology would make for very high thrust and Isp, at the expense of being very radioactive while running! Just because I'm on a roll and starting to ramble, I put more in the spoiler.

Yeah... It's 330k though, and I try not to post images over 60k for people on mobile! Maybe that's not such a big deal any more. It is pretty fun to stare at.

Glad you like it! I don't think the people would ever need to move. In this idea, the saucer would probably be several stories tall, 100s of meters wide, and would house people on the inside. People would only live in the outer 75% of the saucer shape, and would never need to enter the central engine section except for the engineers on their work shifts. Because of the way it's set up, the forces would always 'push' people down in the same direction on the saucer, so I don't think they'd ever need to move. Though, in most setups, they would need to go 0g for a time while the system spins up to make artificial gravity. Still, that's an easier problem to deal with than accelerations in all kinds of directions! I think we could get away with engines all in the central pod. If the central engine pod took up 25% of the total area (and volume), it would take up 50% of the radius, so RCS thrusters put at the sides of the central pod would have about 50% the efficiency of engines out at the rim of the ship. We should then subtract a bit of that for the horizontal roll thrust due to cosine losses of angling the thrusters slightly outwards from the saucer, maybe 40% efficient total? Still, if fuel's not a big deal, we could get away with having all the thrust equipment in the central area, so it could be some really cool and fringe-science like UDH fusion that you may not want too close to the habs. The crew would just have to run along the inside of the ship to keep up!

Here's a full res picture of the roomba from @tater's post: https:\\i.imgur.com/g8tvBKm.jpg I'd always wanted to see the inside of that thing! I was curious if they had an electromagnet set up inside to help hold it to the steel deck, or if it was just really dang heavy.

I think I'll muddy up the works and suggest the saucer. If the ship's really 'super massive' it would need a lot of surface area for landing legs when landing on a planet (which could be full of soft squishy things like forests or cities). The area needed for landing legs feels like it's one of those things that should go with square-cube, and there's no way to make the ground less squishy so I'd base my design on that and worry about the space stuff second. Next, it would be nice if the downwards direction of gravity (when landed) matched the direction of centrifugal artificial gravity (in space) and also direction of force from acceleration when the engines burn (when going between the two). Otherwise you'd need to move all your furniture from the floor to the walls every time you move or land! We could line up these 3 things by having the engines in a separate pod set into in the center of the saucer pointing 'downwards'. This would works well for takeoff and landing, and when you get to space, you can send the engine pod 'up' away from the saucer on a tether and when it reaches the end have it turn 90 degrees and give a bit of thrust to start the whole thing spinning. It's a similar idea to the tether used on Zubrin's Mars Direct. With this approach, we'd need to slam our way out of the atmosphere broadside first, but if fuel really isn't an issue then we could just burn slowly straight up 'till in space, then turn and burn until orbit achieved! (I really do like @kerbiloid's hamster ball idea though!)

You're correct that the other directions are missing. It's been mentioned, so they're probably plugging away at it. Thanks for noticing and nice picture hack! This overall shape of the FEA was the dummies version I learned back in chemical engineering undergrad, sans some pieces I didn't talk about about for calculating accumulated errors. Besides a couple odd balls, it's actually all I've ever used for my own FEAs, and though easy to apply and debug I could imagine it's not the fastest. I didn't consider matrix solution approaches, would they be appropriate here? If so I'd love to learn!