K^2

Members
  • Content Count

    3,932
  • Joined

  • Last visited

Community Reputation

1,451 Excellent

2 Followers

About K^2

  • Rank
    Particle Theory ABD

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Well, a real tank wouldn't fill out a 4 x 3 x 8 meters block, either. That's probably why the density comes out so low. The volume that actually excludes water is going to be many times less. That's generally what happens when you start making loose assumptions without bothering to check them.
  2. Of course. I think p1p1o's point is that kerboloid didn't even pause about quoting density 3% higher than that of water for something that's intended to float. The fact that average density can be much higher for a space station goes without saying. Although, if you're trying to build for extreme size, you're probably going to end up with considerations not unlike these of a warship. Make it too light, and there isn't enough armor. Make it too heavy and it collapses on itself. So using a battleship as a reference is probably the right call. Not realizing that the number has to be less than 1,000kg/m3, not so much. And looking at other numbers, "60 000 / (4 * 3 * 8) ~= 600" ??? 24*8 is closer to 200 than 100. By quite a bit. I went after core assumptions, but somebody should probably check the rest of that math. (Ok, that's actually me failing to multiply 4 * 3.)
  3. You decide to estimate lethal dose of a poison. You give your test subject 1kg, and subject dies. You then procede to remove poison bit by bit to see when subject comes back to life and insist it will still be a fair estimate. In technical terms, it's called histeresis, and it's not a small error. And yeah, I'll write up a proper derivation when I get to an actual computer. The math isn't that hard. You just have to have studied material strength (сопромат). Standard course for engineers and physicists, but does go well beyond high school physics. Though, the later (and common sense) should have taught you to understand why hydrostatics is a bad estimate for when a structure collapses.
  4. Cool. All the rooms inside your Death Star have just collapsed, because it is a fluid. The whole point of exercise is to find the size before it becomes a fluid. Size at which solid stress is still the dominant force. The stress tensor in this problem is diagonal in polar spherical due to symmetries, but it's not degenerate. Outer layers may actually be stretched radially and compressed horizontally, so even the sign of terms isn't the same. Taking it to be a scalar pressure (fully degenerate stress) is a gross underestimate of structural strength. In the words of Han Solo, "That's no moon. That's not even a station. That's a ball of homogeneous incompressible fluid with no structure whatsoever. These Imperials are getting really weird."
  5. Except it's not a fluid. Stress is distributed through the structure, not concentrated at its center. Because of that, the structural limit is going to be larger by a considerable factor.
  6. I don't know about a "few orders of magnitude", but yeah, definitely a lot larger than a chunk of rock. The fact that construction materials are likely to be selected for their compressive strength is likely only to improve that. 1000km across without collapsing into a homogenous ball is probably doable even with materials we know today. Especially, if you keep your heavier stuff close to the center, and move all of your hollow spaces, like living quarters, to the outside. That said, SW routinely uses antigrav suspension and the ships and stations have artificial gravity. How that plays out in the construction of a megastructure I'm not really sure, nor can I be sure with such soft sci-fi world, but it sounds like they'd have a few tricks for supporting the weight of the outer shells without having to resort to brute strength of construction materials. So it's something that can be hand-waved away even if it was far beyond the structural strength of any material.
  7. Both skills, doing mental math and doing math quickly and efficiently with electronic aids (from calculator to specialized math software) are very useful. There should definitely be some classes that do not allow use of the calculator. In terms of higher maths, calculator stops being useful circa analysis, so it doesn't even matter at that point. But requiring students in, say, algebra and calculus to do without any electronic aids is a good idea. Classes like physics or specialized courses in numerical analysis should be the place where you learn to do math with tools. If we're talking strictly school education, saying that calculator is off-limits for anything described as a math class is probably sensible. The math you're likely to see there is of the aforementioned algebra and calculus variety. If we're starting to look at a more specialized technical education, it becomes situational.
  8. Doing velocity portion properly is critical when you have position-dependent (or velocity-dependent) forces. For example, if you were building a KSP clone, and you wanted to add joints, which are simulated as springs, the forces on joints would depend on relative positions of your ship parts. And if you didn't properly account for Ft and Ft+dt, your ship will get Krakened almost instantly. In your case, your main forces are gravity, which is constant, and thrust, which depends on time, but not position or velocity. So the worst you'll have is thrust effectively changing half a tick out of sync with your simulation, which is such a minor effect, that you really don't need to bother. For future reference, if you did have forces that depend on position, there is a super simple hack to account for it in Velocity Verlet. # Compute acceleration at time t force_t = compute_force(time, position) # Compute F_t accel_t = force_t / mass # Use rocket's current mass to compute accel. # Update position and time. position = position + velocity * dt + 0.5 * accel * dt * dt # Update position. position is now position_t+dt!!! time = time + dt mass = mass - compute_mass_flow(time) * dt # Simple forward-Euler on mass, if you're even keepint track of it. # Now compute acceleration at time t+dt force_tpdt = compute_force(time, position) # Compute F_t+dt, because time is now t+dt and position is position_t+dt accel_tpdt = force_tpdt / mass # Mass has been updated as well, so this is accel_t+dt # Update velocity velocity = velocity + 0.5 * (accel_t + accel_tpdt) Note that on the next iteration of the loop, accel_t will evaluate to exactly the same value as accel_tpdt from the previous iteration of the loop. So as long as you initialize accel_tpdt sensibly outside of the loop, then inside you can replace first two lines with accel_t = accel_tpdt. Where things get worse is when your force depends on velocity. And technically, drag does. So your code will have compute_force(time, position, velocity), and because of that, the Velocity Verlet becomes an implicit method. So a little bit of jargon. Explicit methods are the ones where previous steps of integration provide you with all the variables you need to know to compute the next step. So in the loop above, we are using position_t and position_t+dt, but by the time we need the later, we have it computed. So Velocity Verlet is explicit when forces depend only on position and time. The method is called implicit if it relies on information from a future state, one that you're yet to compute, in order to advance. Because we need accel_t+dt to compute velocity_t+dt, if force_t+dt depends on velocity_t+dt, you got yourself a circular dependence. The proper way of getting about it is by using an iterative methods that solves for accel_t+dt and velocity_t+dt simultaneously. For drag, it'd probably be sufficient to simply take current velocity to compute accel_t+dt, and use that to compute velocity_t+dt, then use this as your velocity to compute accel_t+dt again, and update your guess for velocity_t+dt, and so on until the two values stop changing (converge). It shouldn't take too many iterations. That said, drag rarely changes in a way that produces resonance. You'd have to have some model that produces realistic turbulence to have that, and if you're dealing with that, it's a whole another class of problem. I would honestly not bother. Just use the current value for velocity when running force computations, and treat it as an explicit method. As a general rule, if you're forced to use an implicit method, odds are, you can just reduce step size, and use an explicit method, and still get better precision out of fewer computations. The only hard exception I know are central potential problems, such as gravity. If you're trying to predict a path of a comet through Solar system with enough precision to distinguish between close fly-by and a planetary impact, you have to use implicit methods. For basically everything else, you should be able to scrape by with explicit methods. Moment of inertia tensor is a 3x3 matrix. That matrix is diagonal in coordinate system spanned by its principal axes. For a rocket with typical symmetries, the minor axis will run along the center line of the rocket (so directly up when rocket stands on the ground). If your rocket has rotational symmetry around that axis with any angle less than 180° (So if you have 3 identical fins, 120°, or 4 identical fins, 90°) then the other two axes will be degenerate, and you can point them wherever you like. Along rocket's X and Y is usually convenient. So if you set your coordinate system up like this, then you don't really need to track the full matrix. You'll simply have the angular_velocity_x = angular_monentum_x / inertia_x, etc for y, z. But this only works in coordinate system of the rocket. This is not the X, Y, Z of your world. So your update loop might look something like this: # First, compute torques, just like with forces. torque_t_w = compute_torques(time, rot_matrix, ...) # The parameter list might get a little crazy if you arne't doing this with objects. torque_t_l = vector_to_local(torque_t_w, rot_matrix) # This function will take world coordinates vector and transform it to local (rocket) coordinates vector. # Now we need to compute update to orientation (rot_matrix) of the rocket. ang_momentum_l = vector_to_local(ang_momentum, rot_matrix) ang_velocity_l = ang_momentum_l / inertia # This should be a component-wise division. If you aren't using numpy, might need to be a loop. ang_delta_l = ang_velocity_l * dt + 0.5 * dt * dt * torque_t_l / inertia # Here, we use torques by analogy to acceleration in position update. ang_delta_w = vector_to_world(ang_delta_w, rot_matrix) # Finally, we have to apply this and udpate time. rot_matrix = rot_matrix * rodriguez(ang_delta_w) # Double-check if you should be multiplying from left or right. rodriguez() is Rodriguez rotation matrix. time = time + dt # And now we do update for the things that happen at t+dt torque_tpdt_w = compute_torques(time, rot_matrix, ...) torque_tpdt_l = vector_to_local(torque_tpdt_w, rot_matrix) ang_momentum_l = ang_momentum_l + 0.5 * (torque_t_l + torque_tpdt_l) ang_momentum_w = vector_to_world(angl_momentum_l, rot_matrix) Ok, so two things to note. The primary quantity we're keeping track of is angular momentum, not angular velocity. Because the former is conserved, ant the later isn't. Second, note that I'm updating time = time + dt in the middle. This is because this block of code isn't meant to be separate from the position update above. The two are meant to work together. In fact, you'll probably want to compute torques and forces in one pass both at the top and at the bottom of the loop. Mostly, the order isn't critical, but you need to make sure that everything that happens before the time update happens before, and everything after happens after. I've also shorthanded a LOT of matrix math. I hope you can follow it, but that's going to be a big chunk of your effort. The one thing I want to call out specifically is that I'm treating inertia as a vector, rather than matrix. That's because everything's in principal axes coordinates, and the only numbers I care about are on the diagonal of that matrix (everything else is zero in this CS). So we can store it as a vector and not bother with the full tensor. Again, so long as your rocket's local Z runs along the symmetry axis.
  9. Thrust from teather can actually be respectable. Way higher than ion. And nobody is stopping you from milking Oberth. Just keep raising apogee until you hit translunar, and a boost there can put you on a course to a Venus/Mars fly-by (via angular momentum trade in a self-fly-by with Earth.) From there, we know that free trajectory is available to anywhere in Sol or beyond for cost of minor correction burns. If you have the time to wait for all favorable alignments, there isn't a mission we've sent that we couldn't replicate with teather. Then again, we are an impatient bunch.
  10. In the interest of keeping things ethical, I move that we use gliding frogs for this.
  11. I'm honestly not trying to step on how cool paramagnetic levitation is. And it only gets cooler once you start diving into math and physics of paramagnetism. (And also, because of all the liquid helium.) All I'm saying is that at 1G you can "levitate" a human on a bed of nails. The mark to beat is 15-20Gs. That said, even 1G, if it's uniform enough, can be great for all the times your engines aren't running. Mag fields have a wonderful property that they don't diverge, so a relatively light Helmholtz coil can provide fairly uniform B field throughout a rather large ship. I don't think mass requirements will scale well for small exploration vessels, but if we have liners like what BFR is meant to lift, the additional mass might actually be sensible. Granted, on a larger ship, it's significantly easier to set up something like tethered centrifuge as well, but having a solid-state system without hundreds of meters of cables involved seems beneficial. And keeping superconductor magnets cool in space is significantly easier than on Earth. I'll throw some numbers at it. See what I get for tonnage of the coil rings to get artificial gravity on BFR's Starship.
  12. For a mag field, it's a hard limit. Not something you're going to be able to compensate for. It's like trying to levitate a cake with a fire hose. It should technically be possible, but we all know what happens in practice, because you'll never be able to create a flow that perfectly cancels all the imperfections in the surface creating a pressure differential. The way a magnetic field penetrates materials that interact with it in any way really is more like a flow than anything. That's definitely doable. There are limits on how much you can push even fully submerged - even if you manage to fill all the voids, at some point, density difference between bones and flesh will be sufficient to separate the two - but you'd be able to go way higher than anything a modern fighter pilot can handle. Without somebody carrying out definitive tests it's hard to say for sure, but I'd be surprised if you can't go well into triple digits in units of G. Even without breathable fluid, human body can handle several times higher g-forces submerged in water than simply in a g-suit and a proper chair. And these, on their own, provide a factor of 3 or so from unequipped person. Abyss - yeah, but with caveat that despite some successful tests on animals, and limited pressure chamber tests on the same, the tech was never really proven. Russia has recently restarted the research in that direction, but what I've seen hasn't really done anything the old Soviet research hasn't. In fact, it seems to be catching up still. That said, still probably the most believable part of the Abyss.
  13. Even at MRI strengths, human body distorts the magnetic fields, and you have to correct for it when reconstructing the slices from corresponding Fourier spectra if you want high quality imaging. If you were compensating high acceleration with a magnetic field, the gradients from that distortion would be the thing that kills you. You have to apply force evenly throughout the body and in direct proportion to density in order to get anything but marginal improvement in maximum acceleration. And the only force that can do this is gravity. The good news is we know how to generate gravity artificially and on demand. An electric field orthogonal to a magnetic field produces energy flux in direction orthogonal to both and of strength proportional to the product of two field strengths. (see Poynting Vector) Modulating either of the two fields, consequently, produces modulation on the energy flux. And that can be used to generate an effect that is the gravitational equivalent of electromagnetic induction. In other words, you can briefly generate a gravitational field that doesn't terminate on any mass. It's true artificial gravity, however brief. The bad news is that the most optimistic estimate I could come up with for the field strength could compete with gravitational field of a grain of sand. There's a factor of 1/c4 that shows up in the relevant equations, and no matter how much magnetic and electric field you can throw at it, and how quickly you can can kill the electric field to produce the effect, you just aren't picking up enough decimal places to compete against the c4. Now, if we could get our hands on some of that negative-mass dark matter/energy fluid from the other thread, I could probably come up with a scheme that gives you effect of an at least limited inertia dampener. But that's a separate story entirely.
  14. For real engine, ISP will, in fact, vary with throttle. And the max ISP is not necessarily at max throttle, either. I could probably list nearly a dozen factors that ISP generally depends on, and amount of fuel you inject into the chamber will impact, directly or indirectly, a third to a half of these. I'm not sure if the impact of throttle position on ISP will be higher with or without an atmosphere. The fact that the bell for atmospheric operations is shorter might actually help reduce the impact, at least, in some throttle ranges. This will probably depend a lot on the engine design.
  15. The aliens let the first one slide, but now we're definitely getting a fine for littering. An object on hyperbolic trajectory is in an orbit, but I'm not sure if I'd call it orbiting, because then we'd have to say that everything orbits everything else, making it a kind of a useless definition. I wouldn't even be able to claim that Earth orbits the Sun at that point, because there is nothing inherently special about the Sun as far as Earth's track through cosmos goes. So to me, saying "A orbits B" implies that the two objects are gravitationally bound, which is no longer the case for an object above escape velocity. At that point, it's more of a scattering. The trouble is that semantically the words "orbit/orbiting" can imply both the trajectory and periodic motion. I'd usually go to Latin root as a tie-breaker, but it's the same issue there. 'Orbis' is something round, and 'orbita' is a track made by a round object, such as track left by a cart. And while I'm pretty sure that the noun 'orbit' is derived from the later, and that's consistent with standard scientific usage, when we talk about 'orbiting', things get fuzzier. Bottom line, I don't know if I'd correct someone when they say that Voyagers aren't orbiting the Sun. Although, if we look at it that way, they haven't stopped orbiting when they left Heliopause, and rather back when they did their final fly-by boost to get the necessary velocity to leave the system. So if they aren't orbiting now, they haven't been for decades.