OhioBob

That makes more sense then what I did. In fact, after re-reading Claw's answers, I'm pretty sure that I misinterpreted part of it. Hopefully we'll get a clarification, but I think we'll find that your method is closer to the facts.

You are correct, in real life Isp should scale linearly with ambient pressure. The thrust equation is F = á¹ÂVe+(Pe-Pa)Ae where F = thrust, á¹ = mass flow rate, Ve = exhaust velocity, Pe = pressure at nozzle exit, Pa = ambient air pressure, and Ae = area of nozzle exit. For a bell nozzle, Ae is constant, and for a given value of á¹Â, Ve and Pe are constant. F and Pa are the only variables. We can rearrange the thrust equation as follows, F = (á¹ÂVe+PeAe)-(PaAe) Thus we see that thrust varies by an amount that is directly proportional to the ambient air pressure. Since Isp is proportional to thrust, Isp = F/(á¹Âgo) then the change in Isp is also directly proportional to ambient pressure. I don't know why Squad has chosen to use non-linear curves. It seem to me that it would have been easier just to do it the correct way and use a linear function. After Squad has finished making all of their tweaks and bug fixes, I'm likely to go into the engine config files and change it myself. For example, the following is the existing 'atmosphereCurve' for the LV-T30, } atmosphereCurve { key = 0 300 key = 1 280 key = 7 0.001 } Changing it to the following would produce a correct straight line function with the thrust going to zero at 15 atmospheres. } atmosphereCurve { key = 0 300 0 -20 key = 1 280 -20 -20 key = 15 0 -20 0 }

Thank you very much for your fine explanations. If my understanding is correct, we have a system that looks like this (though I may have the direction of the X and Z axes incorrect): The top surface is the Y+ surface, the bottom is the Y– surface, the surface to the right is the X+ surface, and so on. For the Mk1 Command Pod we have, PART { url = Squad/Parts/Command/mk1pod/mk1Pod/mk1pod DRAG_CUBE { cube = Default, 1.015811,0.6656196,0.7373285, 1.015811,0.6769236,0.7315681, 1.250829,0.4787524,1.097382, 1.250829,0.9474788,0.3448916, 1.013055,0.6620117,0.7325699, 1.013055,0.6601633,0.7441065, 0,0.104412,-0.001005709, 1.268897,1.132536,1.270908 } } Therefore, tabulating the data into a more easy to read format, we have: [TABLE=class: outer_border, width: 500] [TR] [TD=align: center]Surface[/TD] [TD=align: center]Area[/TD] [TD=align: center]Cd[/TD] [TD=align: center]Depth[/TD] [/TR] [TR] [TD=align: center]X+[/TD] [TD=align: center]1.015811[/TD] [TD=align: center]0.6656196[/TD] [TD=align: center]0.7373285[/TD] [/TR] [TR] [TD=align: center]X–[/TD] [TD=align: center]1.015811[/TD] [TD=align: center]0.6769236[/TD] [TD=align: center]0.7315681[/TD] [/TR] [TR] [TD=align: center]Y+[/TD] [TD=align: center]1.250829[/TD] [TD=align: center]0.4787524[/TD] [TD=align: center]1.097382[/TD] [/TR] [TR] [TD=align: center]Y–[/TD] [TD=align: center]1.250829[/TD] [TD=align: center]0.9474788[/TD] [TD=align: center]0.3448916[/TD] [/TR] [TR] [TD=align: center]Z+[/TD] [TD=align: center]1.013055[/TD] [TD=align: center]0.6620117[/TD] [TD=align: center]0.7325699[/TD] [/TR] [TR] [TD=align: center]Z–[/TD] [TD=align: center]1.013055[/TD] [TD=align: center]0.6601633[/TD] [TD=align: center]0.7441065[/TD] [/TR] [/TABLE] Is everything correct so far? I’d like to now perform a sample computation to make sure I understand the math. If we assume that the cube is perfectly oriented (i.e. zero sideslip angle) then the Y+ surface contributes all the drag. The Y+ surface is this part’s "tip". The area of this surface is 1.250829 m2 and its drag coefficient is 0.4787524. Drag force is, Fd = ½ ÃÂV2ACd but we must multiply this by DRAG_TIP and DRAG_MULTIPLIER. DRAG_TIP and DRAG_MULTIPLIER are functions of Mach number. Let’s say we are traveling 600 m/s, which we’ll call Mach 2. According to Physics.cfg, the value of DRAG_TIP is equal to 1 at all Mach numbers, while the value of DRAG_MULTIPLIER is equal to 1.2 at Mach 2. Assuming the air density is 0.13 kg/m3, we have Fd = ½ * 0.13 * 6002 * 1.250829 * 0.4787524 * 1 * 1.2 = 16,815 N which is the drag produced by this one part. Now if the part is tilted, then multiple surfaces are exposed to the air stream, with each surface contributing to the drag force. The amount that a particular surface contributes is a function of the dot product of that surface’s axis and the air stream vector. Let’s say with have a sideslip angle of 5o and the orientation is such that the X+ surface is now exposed to the air stream. The amount that the Y+ surface contributes is COS(5o) = 0.996195, and the amount the X+ surface contributes is COS(85o) = 0.087156. To compute the drag contributed by the X+ surface, we use the area and Cd for that particular surface and we use DRAG_SURFACE instead of DRAG_TIP. Did I do that right, or I’m a still messing something up? I'm not too sure about that last part. It sounds like you have a good system that should work very well once the last few remaining bugs are fixed.

All the planets have had the depth of their atmospheres changed from what they were in 0.90. Starting with 1.0, atmospheres now start at the following altitudes: Eve - 90,000 m Kerbin - 70,000 m Duna - 50,000 m Jool - 200,000 m Laythe - 50,000 m

There are ways to determine it experimentally in the game. If you use the AeroGUI mod you have a display giving dynamic pressure, drag force, and Mach number. Dividing drag force by dynamic pressure gives you ACd. You then just have to divide by the area to give you the drag coefficient. The exact value of the drag coefficient is depended on the reference area that you use, therefore Cd can vary. You just have the state what the reference area is and be consistent. I like to use A equal to the frontal area of the rocket. Once you've computed Cd you can plot it as a function of Mach number. You can also compute Cd from terminal velocity, but the above method is easier.

I've been doing some similar debugging and I'm finding the same thing. Some parts are producing far more drag than they should. For instance, I'm discovering that heat shields produce a large amount of drag during launch even though they are occluded and covered by a fairing. In another case I found that the large reaction wheel module produced a incredibly large amount a drag in proportion to its size.

Claw, I think I understand your general description of how drag is calculated, but I'd like to understand the practical details. First, a drag cube is computed from the data in PartDatabase.cfg. Below are some examples. Can you explain what these numbers mean and how the faces are computed? It appears that each cube has 24 numbers, so are these numbers XYZ coordinates for the eight corners of the cube? Are these numbers in units of meters, such that when the area of each face is calculated it is in units of m2? } PART { url = Squad/Parts/Command/mk1pod/mk1Pod/mk1pod DRAG_CUBE { cube = Default, 1.015811,0.6656196,0.7373285, 1.015811,0.6769236,0.7315681, 1.250829,0.4787524,1.097382, 1.250829,0.9474788,0.3448916, 1.013055,0.6620117,0.7325699, 1.013055,0.6601633,0.7441065, 0,0.104412,-0.001005709, 1.268897,1.132536,1.270908 } } PART { url = Squad/Parts/FuelTank/fuelTankT800/fuelTankT800/fuelTank_long DRAG_CUBE { cube = Default, 4.421483,0.7855119,0.6937256, 4.421483,0.7857171,0.6937256, 1.213026,0.9634836,0.1404351, 1.213026,0.9634838,0.1716429, 4.421483,0.784988,0.6937259, 4.421483,0.7850318,0.6937259, -1.376047E-16,-0.01320377,-3.882692E-08, 1.25,3.778993,1.250001 } } PART { url = Squad/Parts/Engine/liquidEngineLV-T45/liquidEngineLV-T45/liquidEngine2 DRAG_CUBE { cube = Fairing, 2.120381,0.7789587,0.7138752, 2.120381,0.7795625,0.7138752, 1.225164,0.9361377,0.2293777, 1.225164,0.8617272,1.553849, 2.120381,0.7755077,0.7138755, 2.120381,0.775539,0.7138755, 0,0.05659348,1.192093E-07, 1.256305,1.686817,1.256306 cube = Clean, 0.9306615,0.7107355,1.02353, 0.9306615,0.7169976,0.7278433, 1.213026,0.9359285,0.193909, 1.213026,0.8411375,1.608727, 1.138486,0.7378568,0.7221571, 1.138486,0.7381418,0.7278435, 0,0.08432049,5.960464E-08, 1.25,1.631363,1.25 } The curves in Physics.cfg appears to compute the drag coefficients. I assume we compute the face area from the cube data above, multiple that area by the curve for the appropriate face type (tip, surface or tail), and then multiple that by the drag multiplier. That is, ACd = Face Area * DRAG_(TIP,SURFACE,TAIL) * DRAG_MULTIPLIER Am I correct so far? Does the above then get multiplied by the maximum_drag and/or minimum_drag value from the Part.cfg files? If not, how is maximum_drag and minimum_drag used? When is one used versus the other? Once the above is computed, I assume the drag produced by each part is found by the drag equation, Fd = ÃÂV2ACd/2 with the total drag force simply being the sum of the parts. Regarding occlusion, you said "parts that are connected to other parts via nodes have the size of that cube's face reduced by the size of the parent/child part." Does this mean that the tip area of a trailing part is reduced by the tail area of the leading part? Or is it more complicated than that? I assume a leading part's tail area is likewise reduced. What if the leading part has a bigger frontal area than the trailing part? Does that have any effect on, say, the surface drag of the trailing part? Physics.cfg also includes the following multipliers. Can you explain how these factor into the computation? dragMultiplier = 8.0 dragCubeMultiplier = 0.1 angularDragMultiplier = 2 Thank you very much for taking the time to explain this stuff. Your explanations so far have be very enlightening.

Given its size and mass, if Kerbin were a real planet, it couldn't retain an atmosphere at all.

Kerbals aren't humans. Why would we expect their engineering solutions to be the same as ours?

Nice work, AaronLS. I started doing some similar tests by computing the drag coefficient from the terminal velocity. I've only tested three shapes so far, here's what I got: My results are in agreement with yours in that the shapes with the lowest drag coefficients attained the greatest altitude.

There is nothing mysterious about making an engine that will work on Eve with reasonably good performance; it just has to have a low expansion ratio. If Squad didn't give us one we can always engineer our own. For example, copy the LV-T45 and make the following changes to the config file: title = EV-E45 "Adam" Liquid Fuel Engine description = The EV-E45 engine is a low expansion ratio version of the popular LV-T45, designed specifically for use in the thick atmosphere of Eve. maxThrust = 168.75 atmosphereCurve { key = 0 270 key = 1 260 key = 5 220 key = 25 0.001 } It's not cheating because such an engine is entirely feasible. The trade off for having good high-pressure performance is lousy vacuum performance. We could also make Eve versions of other engines.

I don't fly planes, I'm strictly a rocket guy. For rockets, I prefer 1.0.2. Launch vehicles: Version 1.0 had more realistic drag coefficients, but I think 1.0.2 is a bit easier to fly. Flying a good efficient ascent profile comes more naturally to me in 1.0.2 than it did in 1.0. The drag coefficients are higher than real life, but I'm OK with that because I thought it was too easy to get to orbit in 1.0. Reentry vehicles: The game doesn't make much of a distinction in the drag coefficient between blunt bodies and streamlined bodies. Blunt body drag coefficient in 1.0 was way too low. Version 1.0.2 is much better but could still be improved. Squad should consider modifying the drag coefficient for heat shields by increasing the Cd in the hypersonic region. - - - Updated - - - Technically, it's the parts that are more "draggy". The atmosphere is no different.

There were changes to the atmospheres between 0.90 and 1.0, but no changes between 1.0 and 1.0.2. The difference between 1.0 and 1.0.2 is in the drag and lift multipliers. Drag losses in 1.0.2 appear to be roughly double what they were in 1.0.

What Slashy did was to study the ISP curves as defined in the engine config files to estimated what the ISP would be at 5 atm pressure. The only two engines that he thought would have adequate ISP and thrust to launch from deep in Eve's atmosphere were the Aerospike and the Mammoth. I haven't studied it myself to either confirm or deny.

GoSlah27 investigated this and concluded that the only two viable options are the Aerospike and the Mammoth. - - - Updated - - - Thank, Nathan. That pretty much confirms what I already thought.

Kerbin Atmospheric Temperatures (Moderators, feel free to split my posts off into a separate thread if you don't think this is the appropriate place for them.) I'm starting to get a handle on the atmospheric model. I've obtained some good temperature measurements and a logical pattern is starting to emerge. I obtained atmospheric temperatures using two methods. First, I sent up a probe and took direct temperature measures. To do this I used the debug tool's "external temperature", which is a better tool than the 2HOT thermometer for obtaining instantaneous ambient air temperatures. This method only worked below 25,000 meters when I could suspend the probe on a parachute. Above that altitude the probe was experiencing aerodynamic heating, either from powered flight or reentry, which elevated the temperature reading and made it useless for my purposes. For the second method I sent up a probe with a barometer and took over 100 pressure measurements as the probe descended through the atmosphere. By analyzing the pressure rate of change I could calculate the scale height. From scale height, temperature could be calculated using T = Hg/R. For R the value 213.75 J/kg-K was used, which I computed from temperature and pressure measurements obtained at the KSC launch pad (described in my previous post). From the direct measurements it became obvious that the temperatures are based on the U.S. Standard Atmosphere (USSA). Major changes in temperature gradient were observed at 8.8 km and 16 km. The USSA has the same gradient changes occurring at 11 km and 20 km. This tells me that the vertical height scale of the USSA has been compressed by a factor of 0.8 to make it better fit the smaller scale of Kerbin. Between the altitudes of 16 km and 25 km, the observed temperatures correspond exactly to the USSA (accounting for the compressed height scale). Below 16 km the measured temperatures were greater than the USSA, though this is likely to be due to a latitudinal modifier. The USSA is based on cooler mid-latitudes while KCS is located at the equator. More measurements are necessary to know for sure, but my guess is that Squad applies a temperature modifier based on latitude and time of day. This modifier is added to the USSA temperature. The adder is greatest at sea level , follows a curved function, and eventually tappers off to zero at 16 km. My second method of temperature determination is less accurate and displays considerable fluctuation. However, the results clearly show that the Kerbin temperature profile follows the general shape of the USSA temperature profile. Once above an altitude of about 35 km, the pressure-derived temperatures are consistently lower than the USSA. Because of my inability to take direct temperature measurements at these altitudes, I don't know if this is a real observation or an artifact resulting from some inaccuracy in my method. I would not be surprised if Squad has also applied a latitudinal-diurnal modifier to the upper atmosphere temperatures as well. As a general rule, when lower atmosphere temperatures are greater than the norm, upper atmosphere temperatures are lower than the norm, and vice versa. This pattern seems to hold true in my pressure-derived temperatures. All of the above is summarized in the graph below. The USSA temperature profile includes the 20% reduction in vertical scale. I'm encouraged enough by the pressure-derived temperatures that I think this method should work reasonably well to obtain temperature-height data for other planets. So far I've focused entirely on Kerbin, though I hope to also reconstruct other atmosphere models. One final note regarding the specific gas constant. Although R = 213.75 J/kg-K produces some unrealistic values for molecular weight and air density, it seems to be the value that you want to use for anything involving pressure and scale height calculations. A more Earth-like value of 287 J/kg-K seems to be what you want to use for any calculation involving density, speed of sound, drag, etc. This is an internal inconsistency that exists in KSP that wouldn't in real life. In KSP, air pressure decreases with increasing height more rapidly than it should according to the values of temperature and density. Next up, a discussion of drag coefficients. I'll post some experimental results latter today.

I was going to start a new thread but this one looks like it might be a good place to have this discussion. I've always enjoyed performing simulations outside the game in order to test/optimize my designs and to predict performance. Even though the old aero model was flawed, it was well understood and easy to simulate. I'm now trying to get a handle on the new physics model so I can update my simulations. I've performed several experiments to try to reconstruct what's going on, but I'm seeing some things that don't quite add up. First off, the old model was internally inconsistent and couldn't have existed in real life. For example, at constant temperature we have the following relationships: Hg = RT = P/ρ where H is scale height, g is gravitational acceleration, R is specific gas constant, T is temperature, ρ is density, and P is pressure. In the old model we were given the following sea level values: H = 5000 m, g = 9.81 m/s2, T = 293.15 K, ρ = 1.223095 kg/m3, and P = 101325 Pa. With these numbers we see that Hg does not equal P/ρ. One of the first things I did was to test the conditions in the new model for internal consistency. Taking pressure, temperature and gravity measurements at different heights at the launch pad I was able to reconstruct the following sea level conditions: H = 6749 m, g = 9.81 m/s2, T = 309.75 K, and P = 101325 Pa. (I can show the work if anyone wants to see it.) Assuming that everything is internally consistent, I computed R and ρ as follows: R = (Hg)/T = (6749*9.81)/309.75 = 213.75 J/kg-K ρ = P/(RT) = 101325/(213.75*309.75) = 1.5304 kg/m2 And from R we can compute the gas molecular weight, M = 38.9 kg/kmol. Right away we see some issues. Squad has always made Kerbin very Earthlike in terms of its gravity and atmosphere, yet these values of R, ρ and M are very un-Earthlike. I do not trust that these are the numbers actually being used in the game. In fact, I've conducted some other experiments that suggest that the density of Kerbin's atmosphere is similar to the old model. I am therefore left to conclude that we again have some internal inconsistency in the way the atmosphere is modeled. This leaves me with a problem. It is difficult to reconstruct an atmospheric model if the atmosphere doesn't follow real-world laws. I'm sure I can devise a model that can reasonably replicate the results that I'm seeing in the game, but my task would be much easier if I could understand exactly what Squad has done and use their modeling method and equations. In additional to the above, I've performed other experiments and measurements that have provided useful information, but I keep getting to a point where the computations stop making sense. For example, I dropped a barometer through Kerbin's atmosphere and recorded a series of pressure-height measurements. From this I was able to compute the scale height at various altitudes. From H, T can be computed if R is known. Although I don't trust the R value I computed earlier, using it does produce temperatures that are in line with what I expect. However, I also performed tests in which I experimentally derived the drag coefficients for some difference nose cones. In this case, using R = 213.75 produced wonky results. I got much more realistic and believable results using an Earthlike value of R = 287. I looked through most of the game .config files hoping that I'd find something that reveals how the game computes some of this stuff, but I found nothing. If anybody here has any additional data or advice, it would be extremely helpful. (EDIT) After making my original post I discovered that the flight stats in the debug menu includes "external temperature". This a better means for measuring air temperature than the 2HOT thermometer. I've already edited the above post to include some revised data. I've also been able to collect some temperature-height data that should prove quite useful. I'll post the results latter.

As described in the opening post.

Parts Just performed a fuel cell test. Fuel cells do not need to be connected directly to a fuel tank. They work like RCS thrusters in that they can be placed anywhere and will draw liquid fuel/oxidizer from the available tanks through an implied piping system. They appear to draw LF/O from all tanks evenly, even across decouplers.

The LV-T30 Reliant looks like it might not be too bad. (ETA) Never mind. I see now that the ISP does not scale linearly. The LV-T30 kind of sucks.

Ohio, USA

I don't think there is an easy way to calculate the things you are asking for because it gets very complicated when there is an atmosphere. I attempted to determine the ideal 2-stage design by performing a series of launch simulations. With a simulation I could break the launch down into many small time steps so I could frequently update all the changing variables. I reported the results of my findings in this thread. Those simulations were based on pre-1.0 stock aerodynamics. I just recently switched to FAR and started to modify my simulations to see if I could find a FAR-optimized design, however I've put a hold on that. Now that version 1.0 is only days away, I'm planning to ditch FAR and try out Squad's new aero model.

I don't know if anybody will find it useful or not, but I just derived the following equation Vsoi2 = 2μ * (1/Rsoi - 1/Rbo) + Vbo2 where Vsoi is the velocity at the sphere of influence, Vbo is the burnout velocity, Rsoi is the radius of the sphere of influence, Rbo is the radius at burnout, and μ is the gravitational parameter. This equation is the KSP version of V∞2 = Vbo2 - Vesc2 except is takes into account that patched conics are used by giving the velocity at the sphere of influence rather than at infinity. Note that the equations are the same if we set Rsoi = ∞. In the KSP universe, Vsoi is functionally equivalent to V∞ because it represents the velocity remaining after escaping the planet's gravity.

impyre, TWR as a function of local gravity I find useful only when I'm launching from the surface of a planet. Once in space, TWR is not important. What is important is acceleration. I may sometimes incorrectly use the term TWR when referring to a spacecraft in orbit, but what I'm really talking about is the acceleration expressed in units of standard gravity. I can't speak for others, but I assume they are doing the same thing. Stating that the TWR is 8547 I find to be completely useless information. What I want to know is that the acceleration is 13 m/s2 or 1.3 g. Acceleration is a function of only mass and thrust, so a LV-T45 isn't going to push around a stack of tanks any easier at 47,000 km than it will at 70 km. When we start adding tanks the ÃŽâ€v goes up because we're increasing the mass ratio, but that has a diminishing margin of return. We can only add so many tanks before the gain in ÃŽâ€v is no longer worth it. The downside of adding tanks is that we decrease the acceleration and increase the duration of the burn. The only really valid part of your argument that I see is that we can more easily endure a long burn from a high orbit. For example, burning 30 tanks of propellant (120 t) with a single LV-T45 will take about 36 minutes. It is impractical to perform a 36 minute burn from low Kerbin orbit, but it is certainly feasible from a high orbit.

I've flown only three missions to Moho. The first was a simple one-way unmanned lander. I tried a trajectory like this: The idea is to start out in a zero-inclination orbit and then perform a plane change when 90o from the planned intercept point. I'm still not sure where I miscalculated but, when I got to Moho, it took so much more ÃŽâ€v than planned for orbit insertion that I had to scrub the landing. It was one of my worst failures. I ended up just having to collect what science I could from orbit. The second mission was essentially a repeat of the first in terms of objectives, and the third mission was a manned landing and return. Both of those used a direct transfer, however I strategically waited for launch windows in which Moho was ideally located near one of its nodes at the time of encounter. This allowed for a low-inclination, low-ÃŽâ€v transfer (low for Moho). I have some recollection that it was more difficult than usual to get the maneuver node set up just right to produce the encounter I wanted, but it was far from an impossible task. (This was also before I started using Precise Node.) Once the injection was completed, I don't recall there being anything especially difficult about flying the mission. I may have had to perform a course correction at some point, but that's nothing unusual. I would never attempt a direct transfer to Moho when the encounter occurs far above or below the ecliptic. Such a transfer would be needlessly costly in terms of ÃŽâ€v.