Cunjo Carl

Unfortunately everything requires its own way to be handled. Conduction is the only easy one! Rather than just having one thing we're tracking for each cell (one 'state variable'), we'll soon have several. Enthalpy (rather than temp, enthalpy is a bit like the total chemical+thermal+pressure energy in the cell and is easier to use when we have different phases around) Pressure Composition (mass or mol fraction of each component) Velocity x,y (or momentum x,y) Crystal type and facing (for mush or solid cells) All of the above need their own equations to update them each timestep like temperature does now. To help with calculations, each timestep we'll use the above to calculate the following for each frame and also store that data: Temperature Mass fractions of liquid vs solid phase (for mush cells) Separately, Compositions of liquid and solid phases (for mush cells) Density Finally is calculating the net force (x,y) on each cell given the pressures, density (+gravity), and shear. The calculations for exchange between cells will always be simple linear equations like they are now, but calculating those things in the second paragraph within a cell will require simultaneous equations which are a huge slow down (I use heuristics and lookup tables instead). As a note, if we have pure Gallium, life will be much simpler! And with the assumption of one crystal type with the same conduction / solidification in all directions life becomes simpler still. @Nivee~'s paper goes through their approach on which equations to use for that case.

Ironically, we'd need light speed to be lower to get more thrust out of a photon rocket with a given power and efficiency. It would have lower Isp, but more thrust. for a photon Momentum = Energy/c so for a photon rocket, Thrust = Efficiency*Power/c (with Thrust in Newtons, Efficiency as a number from 0 to 1, Power in Watts, and c in m/s) Light would need to go very slow to get meaningful thrust out of it though. Maybe as slow as 17m/s https://www.nature.com/articles/17561. Now if only we had some clouds of dense nano-Kelvin sodium BEC gas to fly through... (Note, I'm not 100% clear if the c in the above equations are medium dependent. I think for this specific relationship it is because the slowing of light in media is dependent on interactions, which means momentum exchange right? In other words, the light pushes off the medium, though without scatter, permanent absorption or reflection. If there's any theoreticians out there, is that the correct interpretation?)

Place one motor atop another motor. Have the rotor blades on the top motor tilted in the opposite direction from the ones on the bottom motor. Turn on only the top motor, and automatically the bottom one will naturally counter-rotate without being turned on. At least that's what I found. Seemed kinda buggy with air friction though. Good luck!

Good question. Fortunately no reflection for normal insulators, just no heat flow. So as you say they have no effect. Just for academic interest, atomically smooth surfaces can have heat (phonon) reflections.

Value of alpha is actually .00001855 m^2/s . Screwed up my conversion- looks like it got you too. values: 40.6 * 69.7 / (5.91*(10^2)^3 * 25.86) units W/mK * g/mol / (g/cm^3 * (cm/m)^3 * J/molK) -> m^2/s This line: T_new[x][y] += coefficient*(T_old[x][y-1]-T_old[x][y]); Will try to access an out of bounds variable at the index T_old[0][-1] when y=0 . For starters, use an if statement to prevent. We also need to do each of its neighbors, not just the one above it, so a line for x+1, x-1, y+1, y-1 Presently walls not maintained at boundary conditions, just initially set to them. Is that intended? This line: T_new[x][y] = T_old[x][y]; Is backwards. Good luck

That's amazing. God I miss C, why did I ever leave? (Joking but also actually serious)

Thanks for the syntax correction, @Flibble, that stuff never sticks for me. I'm also noticing my for loops on x were all starting on 1 when they should have been starting on 0. I'll just go fix that. I definitely left a lot to the imagination with the pseudocode! I'm not surprised it won't run by copy pasting. I can help a bit with debugging semantics problems, but it's been so long I'd need to sit down in front of C for an hour to get the syntax back in my head. Mostly, I think you should be lined up in the right direction now though as far as what you're trying to accomplish, and exactly how is now part of the fun challenge. Just as a note, by habit I'm one of those teachers with a mildly sadistic bent who'll purposefully leave hidden hurdles in the way of a problem for people to crash into. Overcoming them is where the best growth happens! When I work with people in person I tend to know how high to size them, but in this case I think I've been going too large! Sorry. It sounds like this may be your first time coding in C++, and if so you might actually get the fastest results by doing simple silly things to start that have nothing to do with CFD. Just make it say "Hello World" 1000 times, do the Fibonacci sequence, that sort of stuff. It should help you understand the overall mechanics of it, which will be invaluable moving forward. Also, please make sure you have a debugger, at least one which can tell you why the program isn't running like "Expected ___ line 66" So you can have an idea of why it's not running. It's always something silly... In this case, it'll almost definitely be an "Error invalid index, Line XX" where the line refers to " T_new[x][y] += ... " and when y = 99 for the first time. Something like that should work for the boundary condition, following Flibble's correction of course. If you use this approach, you'll need to apply those temperatures to the boundary in T_new in each step of the program just before copying T_new to T_old. Otherwise, we'll accidentally overwrite our boundary conditions during the program! I was hinting that you could also just apply the effects of the boundary conditions using if statements within the main code, but this would be way slower computationally, so go with however makes sense to you! I'd recommend not applying it to the entire wall though, just a patch in the middle. Maybe 40-60? Unfortunately, I've really overdone typing in the last few days, so I'll be needing to mostly tune out for a week. Best of luck moving forward!

Let's start by making something simple, a program to model heat conduction in a 1mx1m uniform square of metal. It starts at some temperature (say 30C) and is coated mostly in insulator. At time=0 we suddenly apply heating and cooling a patch on top/bottom to hold the surface at 50C, and a patch on left/right to hold the surface at 20C. Let's track the temperature over time. (A preface for others: For the sake of a good explanation, I'm going to fib a few times, and present a way that's computationally quite silly, but easy to start thinking about. Also as a note, I haven't coded in C++ for about a decade, so parts may be off... let's call it good pseudo code!) To start, imagine our metal is made of a grid of 100x100 of little square 'cells'. Each cell is so small that only the temperature at the center of each one is important. So, at the center of each square cell we can imagine a point, and the that point will determine the properties of everything in the cell. For this heat conduction program, the only information that needs to be stored is the Temperature at the center of each cell, and everything else (like density, heat capacity, etc.) will just be considered uniform throughout all cells in the metal block. Because our cells are so small, and our time steps are so short, we can use the simplest of heat transfer equations, the steady state heat transfer for linear temperature differences. These are shown in the spoiler and digested into a convenient form for our program. So we need our program to make a matrix of 100x100 variables that can store the temperatures at each of the 100x100 points. We'll do this using what's called a 2D array. Making one is simple in C++! double T_old[100][100]; //Makes a 100x100 matrix of variables called an 'array' double T_new[100][100]; /* Each value (called an element) in this array will represent the temperature at the center of one of our squares. Specifically it's stored on the computer as a double. A 'double' is a kind of computer variable that can store numbers with good accuracy, and is fast to use on newer computers. You could also use the very similar kind of variable 'float' which is half the size. */ // The numbers stored in the arrays are random to start, so first you need to use for loops to set every value to 30 (because we start at a uniform 30C). int x = 0; int y = 0; for (x=0; x<=99; x++) { for (y=0; y<=99; y++) { T_old[x][y] = 30.00; T_new[x][y] = 30.00; } } //Then we make the rest of our variables: double alpha = 0.01855 0.00001855; //This is Gallium's thermal diffusivity EDIT: Missed a few zeroes putting it into SI double cellSize = 0.01; //The distance from the center of each cell to the one next to it is 1 cm double timeStep = 0.0001; //Make sure timeStep is ~~ cellSize^2 or smaller to avoid divergence double coefficient = alpha*timeStep/(cellSize*cellSize); //see spoiler double time = 0.00; //We make a variable to track time for (time=0.00; time<=300.00; time+=timeStep) { //Starting at t=0 and stepping forward .0001seconds at a time until 5 minutes for (x=0; x<=99; x++) { for (y=0; y<=99; y++) { Trade heat with the neighboring cells following T_new[x][y] += coefficient * ( T_old[x neighbor][y neighbor] - T_old[x][y] ) doing this for each neighbor to add in all their contributions. If we're at a boundry heat/cold supply, trade heat with that boundry, again following T_new[x][y] += coefficient * ( BoundryTemp - T_old[x][y] ) } } // Copy T_new over T_old , just using another pair of for loops and T_old[x][y] = T_new[x][y] ; } //Display T_new

I'm confused, why would anyone bother covering this up?

A song like this needs a bit of introduction I think, but my goodness, it's been stuck in my head for a month. The fact the visuals are cute and my 5yo little one keeps asking us to play it may be part of that . Anyways, the song starts slow and very patiently builds tension to what feels like the maximum at the 3 minute mark, but then it changes texture, cools off a bit and keeps right on ramping up... And it just never stops! You know things are about to get serious when they bust out the cow bell at the 10 minute mark . It's a 20 minute song, but dang it goes places. I'd been craving some new jazz for a while and this really did it for me. The thumbnail with the horrified faces says: She's singing in 7 time!? You definitely can't take it too seriously! The song's gimmick is they have computer generated vocals singing only "tettey terettey" (an equivalent to dum dum dee dum). But then they frame this silly melody with an intense piano counter melody, a frenetic rhythm and a charming chilled out bass line. Their other songs are just as silly, including such titles as: "We told computer voices just to yell things" and "We only played two chords to make this song" Final fun fact, the character drawn in for the bassist shows up in tons of other places as well, which never ceases to amuse me in a "Where's Waldo?" sort of way. She happens to be the mascot for a successful Japanese private space program called Interstellar Technologies, and even for an ongoing KSP career by @Pipcard where she makes a rather adorable rocket size comparison. Anyways, I hope someone else gets as much of a kick out of this song as I do.

Looks good so far! Gallium is a nice choice because it has a huge energy barrier to nucleation, so we should be safe just assuming the one front. Also nice for Gallium, it doesn't change density much when it melts and doesn't form complex macroscopic shapes when solidifying, which are all big blessings. The model shown appears to be with nice low temperature differentials (10C) on large size scales (2-20cm) and long-ish times (~~1s timesteps.) Also, for larger systems, the trick in this paper became a standard- modeling all the complexities of those dendrites at the solid-liquid interface as just a thin 'mush' with scalable properties. All of this works together to make the square grid a great choice for the materials, time, temp and size scales. I like it. I've never heard of the two techniques before. That said, I'm happy to take a look! Just looking at how they're derived, I think the enthalpy porosity model is more appropriate to us here, whereas the effective heat capacity model would be more at home with polymers or amorphous materials which have low nucleation energy barriers and wide melting temperature ranges. I'll give your paper a quick read and see if I can learn more what it's up to. Next is choosing what we want each loop to look like. We need to calculate a bunch of different physical processes like conduction, convection, phase change, etc and all of these can happen on different time scales. What's more, if we have sharp geometries or very nonlinear governing equations, it's possible to accidentally overshoot what should happen in a given timestep and cause crazy oscillations or divergences. To explain divergences, let's consider KSP. Here think of a rocket glitching and falling through Kerbin. When it touches the center, the model 'diverges' = miss calculates and launches our craft off to infinity at light speed despite this being a thing that wouldn't physically happen. Physically our craft should just get stuck at the center but because the timestep was too long and the physics too nonlinear, the program miscalculated what should happen. Alternatively, a bit more complicated, any time a craft wiggles itself to death while just hanging out in space, that would be an oscillating divergence. We need to deal with the same sorts of problems in our models too. The options for dealing with this are: Single physics loop with short timesteps: We have all of our physics being run on the same timescale (in the same for loop), allowing for quick execution and clean code. However, we choose timesteps that are short enough to always avoid divergence for our model, which can be wastefully slow. It's typically not the most efficient way to go computationally, but in the cases where it's close enough it's definitely worth it for the simplicity. KSP uses this structure. Because they rely on rapid simple calculations, these setups benefit hugely from precomputed heuristics and lookup tables. My very favorite approach is to use one of these and have the setup calculate the optimal timestep on the fly. Nested physics loops: Those parts of physics that are more prone to divergence are run with much shorter timesteps than the rest of physics. This requires nested forloops and is much slower computationally. However, if there's only one part of your physics giving divergence problems it's typically faster than slowing down everything. I tend to avoid these though, in general. Convergence loops: We full on embrace the terrible non-linear nature of our system and for each cell we have a solver (often similar to Newton's method) determine what the values of the next timestep should be. These solvers are specifically tuned (by you) approach their value slowly enough to never have each solver step diverge, but quickly enough it doesn't need to run until next week. Though they're often necessary, these are extremely cumbersome computationally. Given our specific system, I can happily recommend the single physics loop for starters. And though there's a lot more to the details, if we went with the single physics loop the shape would look like: Create two two arrays called "old" and "new" representing our system as grids of square cells, both identical and with the correct starting conditions for (each timestep) { for (each cell in "old") { for (each neighbor) { (using Enthalpy/Pressure/etc. values from "old") calculate heat flow from conduction and add/subtract the enthalpy from the cells in "new" calculate heat flow from convection and add/subtract the enthalpy from the cells in "new" calculate heat flow from viscous friction and add/subtract the enthalpy from the cells in "new" etc. etc, going through all of our governing equations also including for mass flow. (exceptions for boundary conditions) } } for (each cell in "new") { Update physical properties (amount of phase change, the temp change from phase change, density change, etc.) } for (each cell in "new") { copy over cell in "old" } Display } Cheers!

Oh! I watched a documentary about all this as a kid!

@Nivee~ I had to write one of these about 15 years ago, I'll do my best to remember what's up and get you going in the right direction. Come to think of it, computers are like 20 times faster now. That should be extremely handy. Unfortunately, I've long since forgotten C semantics beyond the basics! Ok, so to get started, we need to pin down more precisely what your goal is. Then, depending on the specifics we can pick which of the 50 bajillion kinds of FEA (numerical method) we want to use for the job! I'll go over a bit of the basics just to get conversation rolling. I don't know what level you're at, but I'm assuming this is a grad course? A. Vakrushev, M. Wu, et al. Numerical Investigation of Shell Formation in Thin Slab Casting of Funnel-Type Mold 1. Pick the system we're trying to model So if you're doing this for a class, the good news is you just need to make good looking results! It doesn't need to predict anything, you can instead massage the program to make results like how you want them to look. But we need to find out what kind of materials we're trying to model. In other words, do we want to see a very simple solidification like in plastic, a somewhat interesting solidification like water+ice, or a more complicated one like the dendritic solidification of metal castings shown above? Specifically, the things we need to nail down: Is our model 2D or 3D What size/time scale of effects do we want to see Do we need to model nucleation Is the solid crystaline or amorphous Do we need to model different solidification rates on different solid crystal faces Do we need to model different thermal conductivities in different directions of the solid Do we need to model dissolved materials (like solutes or dopants) Do we need to model bulk flow or convection in the fluid (like for injection molding or extremely high temperature differentials) Since this is for a class if you've never heard about some of these things, then we don't need to worry about them. Hooray! Easier=better. 2. Pick mesh type The mesh is the shape of the little cells we've divided the world into so we can compute it. We can go with 3 kinds of mesh: Fixed uniform, Fixed, or Dynamic. Then, we can go with 2 basic kinds of shapes: triangles/tetrahedrals, or squares/cubes. If at all possible, we'll go with a fixed uniform mesh of square cells, which makes life so much easier. With one of these, we divide the world into a big square grid, and all the programming and mathematics work out nice and simple. For small/simple systems these are fast to write and fast to run, but they have a really hard time with things like dendritic solidification fronts. Next in line are fixed non-uniform meshes, where you can make smaller cells (= more accurate results) in areas where you think you'll need it, like on sharp corners of a melting ice cube. Finally is the dynamic mesh where the computer automatically makes smaller cells where it detects they're needed. This is hard because it makes information tricky to find in memory- as a side note, how fast your FEA runs has much more to do with how hard it is for the computer to find things in memory than it does with how many commands the computer needs to run. If your program makes the processor 'unexpectedly' look something up from your RAM it can take 75-100 computer cycles to do it, and when it happens a lot this time delay (called cache thrashing) plagues most FEA designs including my nemesis COMSOL. Anyways, if we do simple squares in a fixed uniform grid for a mesh we get to avoid all the hassle. Hooray! Easier-better. 3. Pick governing equations Specifically, we need an equation of state for the solidification (most simply just the enthalpy of melting), equations for heat and mass flow (most simply just thermal conduction and negligable fluid flows), and equations for materials properties like density at different temperatures (most simply just ignored and assumed constant). We'll probably pick our governing equations based very specifically on what we're trying to model and what mesh we went for. It's always tempting to get really fancy with how to do your governing equations because SCIENCE, but to be honest, it's typically fastest easiest and most effective to just precalculate whatever we need and toss it into a lookup table . Once again, Hooray! Easier=better. It's a lot, but hopefully enough to start thinking? Always remember that bottom line. Easier=better!

Just a couple followups. @sh1pman, so I went and asked the astrophysicists at work about dark matter falling into black holes, and they agreed that it's assumed it'll increase the black hole's mass just like normal matter. For the more in depth study though, none of them knew of any! The general consensus was that there wouldn't be much we'd actually be able to see in a simulation- we've recently observationally ruled out large range dark matter to dark matter interactions, and really have no idea about the short range interactions (though most theories indicate very little or no interaction). So, dark matter would be able to fall into the black hole if it was heading straight for it, but the dark matter wouldn't (to our guessing) have any crazy accretion-disk-like interactions to help it collide, drag and spin down into the center. Because of this, one of the cosmologists said they'd be surprised if more than 5-10% of a typical black hole originated as dark matter. For the evaporation, from the article I put up the red region on the left should be the region of black holes excluded because we'd be able to observe their hawking radiation Most black holes, even tiny ones, really shouldn't evaporate much. I remember calculating it for something a while back, and found that a moon-mass black hole would be roughly indistinguishable energy-wise from the faint glow of the cosmic microwave background. The lighter the black hole, the 'hotter' the particles it can emit, so at a few thousand times smaller a black hole will appear with the intensity of the sun! But this black hole would only have the area of a tiny dust speck, so it'll ultimately be less bright than a light bulb. The line on the chart suggests evaporating black holes would just be too faint to notice until it's finally small/hot enough to pump out (apparently) a few watts of gammas each. At this intensity, it would still be bajillions of years before we'd see the exciting final 'Vwip!' as it explodes into some kilotons of exotic matter (which would in turn become a massive burst of Gammas and neutrinos for us to witness.)

Negative things in a general way, huh? Hmm... let's go with disease sucks! Like for reals though.

Nice connection! Looks like it's a thing: Existing Source for Muon-Catalyzed Nuclear Fusion Can Give Megawatt Thermal Fusion Generator They use a similar muon production method in conjunction with ultra dense Hydrogen-1 (some kind of condensed matter which is totally new to me), to get some pretty impressive looking power gains on paper. Will definitely be reading up more. Edit: More reading on that ultra dense Hydrogen phase.. Several elements of this throw up hoax red flags for me, but honestly the bulk of it passes the smell test for good science done in good faith. As a whole, I'm inclined to believe it. Definitely going to run a copy over to a condensed matter group at work to see what they think. If even a quarter of what's presented is true, it's jaw droppingly amazing- Hydrogen at a density of 100, able to exist as a stable free phase! Too good to be true doesn't begin to cover it.

Liquid metals have exceptionally high cohesion, owing to their sea of electrons. From our perspective it means they have extremely high surface tension, even relative to water. Their adhesion depends 100% on what surface they're on. When we want low adhesion, we tend to use specific ceramics or sometimes vitreous carbon. There's several forms of electric levitation that work on molten metals. The main one I'm familiar with uses eddy currents for levitation much like the standard Physicist's jumping ring trick. It's used very rarely in specialized 'inductive' evaporators. As far as I'm aware, it should work in the 1s of kHz region but the paper I link to suggests using RF. You can also use a quadrupole electric field if the molten metal is provided a net charge to ground (which in practice is fairly easy). About a decade ago I really wanted to build one, but fortunately discovered before starting they're a huge pain in the rear end. I think the version shown would be the preferred method. Levitation paper Directing alphas using the electric field is apparently very difficult. An old coleague of mine told me once that there was a lot of work done on this during the 70s to try harnessing electric power directly from alpha particles and initially the work looked quite promising, but in the end controlling them in large amounts in any meaningful way was just too difficult. Even with magnetic fields is quite tough apparently- I guess that's one of the reasons Tokomaks are so tricky.

And apparently NASA wasn't able to get their mission plan and budget request to congress on time, which was... less than positive for funding prospects moving forward. Just from the perspective of rockets=good, I'd hate to see the accelerated moon shot get nipped in the bud, but there's a lot of reasons it's understandable. Just have to wait and see which way the wind blows I suppose!

Oh I see, so the rear fins won't need to provide active control any more, that's all gone to the canards, so instead they can just be locked into one of two positions. That does sound a lot easier!

The actuated fins still sound really tricky to me. They need to be fast, high torque and reliable. But then, we also need to land on them! That poor bearing. What else could you use though? Now they have the canards up front, maybe solid fins with deceleron style maneuvering airbrakes? Sounds heavy, but functional....

@farmerben, sorry I'm not quite following, but maybe I can provide some more information? A common device containing liquid metal and high vacuum in a single chamber would be the "evaporator", which is designed to deposit thin films of metals onto things. There are two main kinds of evaporator, separated by how they heat up the metal: Thermal evaporators, which heat up the metal using electricity (typically going through a resistor in which the metal sits), and E-Beam evaporators which use a beam of high voltage electrons to heat the metal. When heated, most metals will liquefy before they evaporate, and don't disturb the high vacuum. In fact, they often help the vacuum through a process called gettering, where the evaporated metal vapors react with the tiny amount of gas in the chamber (typically water at 1*10^-8 atm), and then stick the resulting compound as a metal oxide/hydroxide on the chamber wall. There's many excellent metal amalgams. The most common one these days for being a room temp liquid is Galinstan, a mixture of Gallium Indium and Tin. It's quite expensive, but is much less toxic than most other options. Transition metals can dissolve into semiconductors to varying amounts, where they're typically called dopants. They heavily effect the semi-conductor's conductivity. Some metals are highly mixable (like iron and silicon), and others not so much. Molten metals and salts have all kinds of fun electrical properties. There's research done on molten metal spheres, doing a quick internet search (Youtube Video).

Samsung's modern flash memory (V-NAND) is somewhere in the 2-4 Terabits per square inch ball park (Oh no, imperial units, run away!), and will probably be made on thinned wafers stacked to 200-300um thick, so if we could do the packaging to stack them on the die level we'd be looking at about 300mm^3/TB (byte). For a real device we could probably happily triple that taking cooling, datalines and such into account. Let's call it 1cm^3/TB. So if sufficiently motivated, I'm getting about the same values as everyone else that we should be able to cram the whole Exabyte into about a 1m cube. It would cost a bloody fortune both for development and manufacturing, and the datarates out would not be particularly impressive, but it could be done! If we want to go near future though, single atom storage is starting to peak over the horizon! Ars Technica article Edit: Got a better source for the stack thickness: here.

Fluorine's actually a less bad actor than things like Hydrazine or N2O4... I mean they're all pretty bad. I was also curious about these combinations and looked into it a while back. The book Ignition (distributed for free!) talks about how that particular combination was tried but failed due to poor and inconsistent burning. Modern binders though like unzipping polymers (Paraformaldehyde) might provide much better performance though. They're designed specifically to chemically unravel at the first sign of oxidation leading to some very ... vigorous reactions. A little side story relating to how these unzipping polymers should help hybrid booster performance: Paraformaldehyde is also common tweezer material (Delrin/Celcon/etc) and can unfortunately look just like the nearly inert teflon in dim lighting. One day, one of my lab users must have left a pair of Paraformaldehyde tweezers in the aggressive chemical bench, and I think you can see where this is going. I mixed a boiling fresh batch of one of the world's greatest oxidizers (peroxymonosulphuric acid, we called it Piranha because of how well it gets along with organics), then I put down my teflon tweezers and accidentally picked up the Paraformaldehyde ones. When I went to give the oxidizer a final stir the reaction was hypergollic, instantaneous and complete. Kerpow! It sounded like the crack of a shotgun, and sent a fireball of burning acid everywhere. Nothing remained of the tweezers but a comically short burning stub. Fortunately I was dressed in the appropriate gear and don't rattle much, and after tamping out a few little fires I got to spend the next 2 hours cleaning up the lab while reflecting on how chemistry is always happening whether we expect it or not. I'd been a safety trainer for years at that point, and given it was me at fault I'm happy to get to tell the story to all my trainees from then forward. Wear your safety gear. Anyways, I think these unzipping polymers will really help the combustion efficiency issues in Hybrids. They've very recently been getting a lot more attention (paper) Personally, I've become interested in Liquid Hydrogen / Lithium Borohydride Gel fuels for use with oxidizers like supercooled F2O. I think it's clearly a step in the wrong direction for anyone with interest in practicality (and not exploding), but the Isp... I wants it.

The good news is the Vy term should drop to 0 at both the Periapsis and Apoapsis, which is part of what made that earlier equation so easy! But I think you're right that it's that Vy messing with the direction that's at fault, and I think the root cause is my instantaneous burn assumption being bad for that situation. The only good fix (closed form) will be to use a burn that changes direction mid-burn and expect the burn deltaV to be a few percent higher than the equation initially predicts. This new equation is for the inwards/prograde direction we can burn that won't change our Apoapsis at any instant, whereas the old one was in essence this equation averaged across the duration of the burn. The new burn will be less efficient by some percent due to something akin to cosine losses (and so less efficient than the DV equation predicts), but I'd guess probably not enough to worry. In the end, the new direction equation should work if dropped directly in to your current code, with the requirement the rocket can turn fast enough to keep up! I think it'll be ok for everything except the Battlestar Galactica. Let's see. BurnAngle = (I'm away from my normal computer, so I have a rather clunky equation editor. r is radius, A is Apoapsis, M is Mu (or MG), and v is the v_theta from before) Also here's the equation text, with parentheses balanced and such for easy plugging in: arctan( ((r/Ap)^2 - 1) / sqrt( ((r/Ap)^2 - 1) + (2MG/(r*v_theta^2))*(1-(r/Ap)) ) ) Thanks for doing the experimentation work! If this doesn't work out I'll put together the derivation over the coming weeks and we'll see where it went wrong. Edit: Found a much cleaner simplification... editting.... Ok, maybe it looks uglier, but this shows the new equation as a correction factor built upon the original one! This sort of thing always makes me happy to see. The -Vy has become the -1 on top, and the old equation for Burn DeltaV Theta is now living on the bottom. And here's the now much simplified form for the typing it out arctan(sqrt( ((r/Ap)^2-1) / ( (2*MG/(v_theta^2*r*(1+r/Ap))) - 1 ) ))

I'm so happy they made it! I wasn't even sure they'd get another shot given they were crowd funded, so to suddenly hear about them breaking the Karman line is amazing! I guess a bit more about the rocket- It's called MOMO. Ostensibly the name is a reference to a reading of word "100-", as in "This rocket's going up 100-km" , but the same pronunciation also means "Peaches", and given Interstellar Technologies has had rockets named "Strawberry" and "Snow Sparkle", I think it's pretty clear what they were really going for. Really, it's hard not to root for a rocket named Peaches. Momo is a 1 tonne sounding rocket with a 1,200kgF pintle engine running on LOX and Ethanol of all things. It's designed to provide about 5 minutes of microgravity to a 20kg payload (a comparable mission to New Shepard), while also acting as a stepping stone for their upcoming microsat launcher, the Zero. The first two launch attempts of Momo rockets were less than successful, so it was great to see a success for number 3. After watching their launch, I'm starting to dig back through the live stream. Just for the heck of it, I'll try to keep a translation log going here, but I need to skip town for a couple days and haven't made it very far yet.