K^2

That's unfortunate. I do wonder if there are supersolid states at low enough temperature that might be more interesting, but given how high the specific energy is at that pressure, I doubt that any quantum effects will make a practical difference.

The error bars on the measurements are significant. You really should be averaging across several days of data, and the trend on these is still down. Though, it does seem to slow down, yes, so it might have, indeed stopped dimming. We'll know for sure in a few days.

Not to mention, Betelgeuse rare is the brightest star in Orion anyways. So most of the time, the designation for Orion is already wrong. Might as well simply skip alpha and keep current designations if Betelgeuse does explode in the near(ish) future.

It mostly is, except, again, the way they're measuring mortality is a useless metric for comparison against SARS and others. People who are getting confirmed infections today aren't going to die or get better tomorrow. It takes time, in which the disease spreads dramatically, and so proportion of infected individuals is always going to be way higher than these who died. Looking at dead vs recovered is more sobering, with 171 vs 170 as of January 31st. Of course, that doesn't imply a 50% mortality rate either, but the true value is somewhere in between, on the order of 10%. I can't find the data I need to give a good enough estimate to say for sure if it's more or less deadly than SARS, but it's definitely in the ballpark with way faster spread.

Actually, if you figure out how to make a "nozzle" for it, a miniature black hole is an almost perfect propulsion method for a ship in a few thousand ton range.

I get a good view of Orion every time I go up the stairs to my apartment coming back from work this time of year, and it's been clear almost every night for the past couple of weeks. So I can't help trying to guess if Betelgeuse looks dimmer than Bellatrix or not. So I'm not the one to judge.

I've been watching the AAVSO data on a daily basis for the past couple of weeks. Part of the problem is that the only thing we're getting live update on is volunteers contributing measurements made with amateur equipment. Some of these people are by no measure amateurs themselves, and they're using high grade amateur equipment, but even then, there's only so much you can do with a telescope sitting in your backyard. As a result, data sets vary by location, weather, and who's been taking the data. But if you plot any single observer, you can see that the trend is still going, if possibly slowing down a bit. We'll get nice, clean data on all of this, I'm sure, but it will probably be in a few months, once papers with results start rolling out. For now, we have to keep wondering how low can it go! And yeah, while the odds of anything visually spectacular happening any time soon are absolutely minimal, I've been checking up on Fermilab's Nova for any signs of a supernova. Seen some interesting triggers fire, but nothing remotely resembling a supernova within our galaxy. And yeah, neutrino detectors will give us several hours of warning, and it will probably be all over news and social media if it explodes, so you can stop going outside and looking every hour. Not an error. It just depends on how you bin the data and compute the averages. The continuing dimming attracted new contributors, so the AAVSO data is messier than it has been, and there have been a few points that are way too low, as well as some unusually high ones. If you look at error bar on that last point, it falls well within the trend. The brightness is still roughly exponentially decaying in visual band.

Oh? You can do hypersonic flow computations on a calculator? THAT I got to see. Please, go ahead. Demonstrate this miracle of simple math to us.

Cool. Since it's simple, what's the dynamic pressure on a R = 1m sphere traveling at 5km/s through diatomic gas with average molecular weight of 29AU as a function of temperature and pressure? You may plot temperature dependence as individual curves for pressure values from 1bar to 1μbar decreasing by factor of 10 between curves.

There is no evolutionary pressure to make the virus more deadly. Only to be more infectious, and there's a hard limit on that for this type of virus. We're just as likely to get a deadlier form as we are to get one that is less deadly and effectively inoculates you against the deadly form. Anything can happen, of course, but current trajectory is not a doomsday one.

Definitely not at anything like 1atm, but there might be a pressure range at which it is metastable that is attainable in fuel tanks. If it also turns out to be a superfluid or supersolid, we might be able to work with it as a fuel even then. Yes, lots of "if" statements there. Just saying we can't definitively discount it, but it's definitely in the "don't hold your breath" category. Could still be useful for things, even if we can only maintain necessary pressure on microscopic levels.

Primarily, but there's always a distribution, even with common flu, and since this disease has mortality rate that's orders of magnitude higher, we will see deaths across the demographic spectrum. Latest I've seen (Feb 1 data) is 300 deaths against a little under 15k confirmed. Modeling suggests about 75k infected in total at that time, with about 2 weeks lead time. The confirmed cases are doubling roughly every 3 days. So we're talking about something closer to 2,400 people having been infected at the same time as the 300 that died. That puts mortality rate at about 12%. Keep in mind, this is a conservative estimate. I really do hope that it's significantly lower, but the 2-3% that people get by taking dead/confirmed ratio is way too low. The new virus is likely nearly as dangerous as SARS or even a little worse with faster spread. It's definitely not in world-ending category, but it's going to have very significant impact anywhere it's not contained.

And when the average thermal energy of particles corresponds to a few hundred meters per second, and something's passing through this medium at a few kilometers per second, that matters absolutely naught. You should be looking up formulae for hypersonic flight. Not propagation of subsonic waves. There is a reason why supersonic and hypersonic are two different terms.

Re-entry is so energetic that temperature of atmosphere makes almost no difference at all. Only density. All of the interesting things are happening in the shockwave, and its temperature is basically determined by density and speed of the craft. Shape also plays a role there, but maintaining a dense, slow moving (relative to the craft) shockwave far ahead of the shield is more important, so blunt shapes are practically universal. @mikegarrison covered the rest in his reply.

Prime doesn't always denote a derivative. In this case, it simply denotes velocity gained in the moving frame of reference. You'll still have to convert this to rest frame if you're interested in rocket's acceleration in rest frame. Further, in this case, all of the d-variables will be taken to zero in the limit as the final step so that you can get the actual acceleration - dv/dt. It's a very ugly way of deriving the acceleration of the rocket, IMO, but it will give you correct answers if you take the limits properly and do all the cancellations. Wikipedia article gives a much cleaner derivation. Although, they skip a lot of intermediate steps. Nonetheless, if you want to understand a relativistic rocket, that's what I would recommend looking into. - Relativistic Rocket

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.

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.)

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.

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."

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.

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.

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.

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.

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.

In the interest of keeping things ethical, I move that we use gliding frogs for this.