Maximum Delta-V rocket

[nosirrbro]

Using a gaunt monstrosity of Xenon tanks and ion engines I was able to get tens of thousands, however it's TWR was so abysmal that it would probably take months of ingame time to use it all and it cost more than anything I had ever built before.

Edited April 9, 2016 by nosirrbro

[Archgeek]

4 hours ago, nosirrbro said:

Using a gaunt monstrosity of Xenon tanks and ion engines I was able to get tens of thousands, however it's TWR was so abysmal that it would probably take months of ingame time to use it all and it cost more than anything I had ever built before.

Yup.  What's really funny is it'd actually be great in real life -- my 84km/s extremis test has 12 ion engines, which get it an acceleration of 5.1cm/s^2, which is actually more than the Hermes gets in the Martian.  With these kind of number in the Kerbol system, we could get away with crazy torch-ship trajectories -- periapse kick out from Kerbin until escape, then aim just barely in front of Jool and burn to the halfway point, turn around and burn away from it 'till capture.  Would be terrific if we could have the game apply super-low thrust sources like ions in time-warp.

It does get insanely expensive, though.  That stage test would be 22.3 mil if I saw fit to build it, even more to get it upstairs...'looks like 9 launches with creative packing and some orbital construction.

[iLikeRovers]

I'll leave this here (not my video) It looked like it had a dV in the region 130 000 m/s, but some staging damage did waste some.

 

[MaxL_1023]

To get to Valentine in that new extrasolar mod you would need something like that just to launch a probe core, unless you want to wait hundreds of years. 

[Padishar]

On 4/9/2016 at 8:01 AM, Archgeek said:

KER was failing at the staging for some reason

It appears that the deltaV simulation is failing to fire stages 8 through 3 until all the engines stop burning.  This may be an unavoidable (without allowing user input for the staging conditions) consequence of your vessel design or it may be due to a bug in the code.  Can you upload the craft (preferably in the KER thread) so I can take a look?  I don't really want to hunt through a full debug simulation log of a 1239 part vessel (especially where most of the parts are fuel tanks), I suspect the log output will be many megabytes in size, but the simulation staging in KER does need tweaking for various edge cases and this looks like one of them...

[Archgeek]

38 minutes ago, Padishar said:

Can you upload the craft (preferably in the KER thread) so I can take a look?  I don't really want to hunt through a full debug simulation log of a 1239 part vessel (especially where most of the parts are fuel tanks), I suspect the log output will be many megabytes in size, but the simulation staging in KER does need tweaking for various edge cases and this looks like one of them...

Ah, this probably isn't the best realization of said use case -- you're looking at KER-1.0.18.0 on KSP 1.05 (It even comes up with a complaint "Unsupported KSP version... Please use 1.0.4").  'Not sure why I've got an older version here, but I do recall VAB-breaking issues with 1.0.5 (Stock Bug Fix Plus, KER, KAC).  I'll give it a shot in a 1.1 build after work and see what comes up.  I will note the issue came up with part counts in the low hundreds -- that giant thing was just an extremis test.

[MalfunctionM1Ke]

@Whackjob Buddy, where art thou?

I hope you are already having fun with the 1.1-Prerelease

[Whackjob]

On 4/11/2016 at 9:09 AM, MalfunctionM1Ke said:

@Whackjob Buddy, where art thou?

I hope you are already having fun with the 1.1-Prerelease

Oy, haven't been around.  I'll have to check in to it!  I've been distracted for quite some time.  What do I have to look forward to?

[Archgeek]

12 minutes ago, Whackjob said:

Oy, haven't been around.  I'll have to check in to it!  I've been distracted for quite some time.  What do I have to look forward to?

So very, very much.  Prithee look upon the changelog: 

 

[Whackjob]

7 hours ago, Archgeek said:

So very, very much.  Prithee look upon the changelog: 

Looked it over.  Lots of very nice optimizations,  but tell me;  Does this affect part count for the better or worse?

I note the wheel changes.  That could be beneficial for a very large rover.

[Archgeek]

1 hour ago, Whackjob said:

Looked it over.  Lots of very nice optimizations,  but tell me;  Does this affect part count for the better or worse?

I note the wheel changes.  That could be beneficial for a very large rover.

Having derped about with the pre-release, I can say, significantly better.  Though it's best when multiple ships are around (each tends to get its own thread).  The current build does have a tendency to slow down a lot when one of my thermal extremis test craft hits a solar escape trajectory, though this may only occur when the thing's really hot and thermal data's being displayed in several pinned context menus.  But pre-release bugs should have no bearing on the 1.1 release itself.

[Renegrade]

On 2016-04-07 at 10:59 AM, Teutooni said:

The way I understand staging is, parallel or onion staging is less efficient than serial (stages on top of each other, i.e. the normal staging method), but they benefit from all kinds of TWR considerations. Asparagus is one of the most efficient staging methods when considering delta-v, mass and TWR. TWR (or TMR) was left out of this consideration on purpose. In any onion or asparagus staging that preserves centre of thrust and mass, two fuel tanks need to be dropped at each stage. In serial staging only the dead weight of one near empty fuel tank needs to be dragged along until each separation, thus making it slightly more efficient in terms of delta-v.

Well, asparagus staging is the same as serial staging - the only difference is you save on engine mass with asparagus, assuming you have a TWR (TMR) goal of some kind.  If you do have a TWR goal (say in a lifter that puts things in orbit from KSC), your ship will have to have enough engines to lift the current stage and ALL the stages above it in a serial stage design, but an asparagus will only need to have enough engines to lift the CURRENT stage (plus some tiny fraction of the payload), greatly reducing engine mass required.

And, let's be honest, there's always SOME floor to TWR/TMR you wouldn't want to cross.  Ships in that are landing have to have a TWR larger than 1 (it doesn't have to be a lot larger - but it does have to be >1.0 by touchdown or else you'll have to rely on lithobraking), obviously, as do ships launching from a planet, but even ships in orbit face constraints.  Oberth isn't a friend for a real life ion drive.  Even in KSP, periapsis kicking can only take you so far.  You only have about 1h30m when crossing Moho's SOI.  And if you got your TWR/TMR low enough, eventually the phantom forces that exist in ships would be too great for your engines to overcome, and you'll find that you can get to where you want quicker by turning your engine off and letting those phantom forces carry you (and they may very well be opposite to your line of thrust.  Probably opposite, in fact.  Murphy is quite mean)

On 2016-04-07 at 6:35 PM, wumpus said:

Before 1.0, traditional onion made zero sense.  By "traditional onion" I mean drawing from multiple fuel tanks (more than one pair) and feeding multiple engines.  You would always get more delta-v (and higher TWR) by grouping the engines together and dropping each pair of fuel tanks as drop tanks, and then finally dropping all the engines along with the final pair of drop tanks.

Uhh, what?  While a drop tank ship with a single terrier would have more delta-v than the same ship with terriers attached to each tank, but I really doubt that a poodle ship could do the same (a poodle being roughly the same as four and change terriers. It has a slight Isp advantage).

Here's an example ship, with a 1.3t payload (basically a re-entry mk1 capsule, chute, heat shield, no tweaking). Doing two asparagus stages with two tanks and two engines in each stage (terrier+2T fuel tanks, on the long decouplers), you get figures like this:

Wet Mass  Fuel Mass   DeltaV  Thrust  TWR (vs Standard Gravity)
      4t         2t     2345      60  1.53
    9.7t         4t     1799     180  1.89
   15.4t         4t     1018     300  1.99

Total Delta-V: 5161

(dry mass is wet_mass-fuel_mass - this is an actual ship from 1.1 in my nasty little spreadsheet I built for lifter design.  I'm rounding half-up some of the numbers like delta-v, and the VAB only gives vague masses.  However, the spreadsheet is carrying on in full spreadsheety precision in the background so the final number is correct within the limits of the VAB mass indicator)

Now if you attach all five of the engines to the central core (I'm not including any mass penalty for that, I'm just stacking them on top of each other and pretending it wouldn't immediately blow up), it looks like this:

Wet Mass  Fuel Mass   DeltaV  Thrust  TWR (vs Standard Gravity)
      6t         2t     1372      60  5.10 !!!!!
   10.7t         4t     1584     180  2.86
   15.4t         4t     1018     300  1.99

Total Delta-V: 3973

So unless I misunderstood what you're saying, no, no it is not better to haul the engines with you.  Not unless said engines are a lot better than the ones you're dropping.  They are dry mass that every stage has to carry now.

(note that if you only used ONE terrier on the core and NONE on the tanks (a pure drop-tank arrangement that cares less about TWR) the delta-v would be 5628, but the TWR would be 0.46 and 0.70 instead of 1.99 and 1.89 for the lower stages)

Just to be clear, by the way, the first design is to the left of this image, and the second, to the right (inset):

Also - it bears repeating that I'm assuming a stack of 5 terriers work for the case of delta-v calculations. So just ignore the fact that the right ship wouldn't actually fly.  The engines could be mounted on octags and squished in to actually work properly etc etc.

[wumpus]

1 minute ago, Renegrade said:

Uhh, what?  While a drop tank ship with a single terrier would have more delta-v than the same ship with terriers attached to each tank, but I really doubt that a poodle ship could do the same (a poodle being roughly the same as four and change terriers. It has a slight Isp advantage).

The whole point of an onion configuration is TWR.  It had engines on the bottoms of each tank, and as the fuel burned out the TWR would increase (and go higher than asparagus) until the stages around the final tank ran out of fuel and were discarded.

It wasn't commonly used (thus nobody bothered to point out the obvious flaw), but I did need it for one design challenge: launching a rocket (well before beta) with the parachutes open.  This challenge was interesting in that Scott Manley did it as a live stream: at the time you could challenge yourself to see if you could do it faster than Scott.  https://www.youtube.com/watch?v=PY6xjCKsIMk  (I think I got into space with the same parts roughly as fast (I didn't start at the same time), but I really don't think I ever played with a version that old).  The onion configuration helped blast through the souposphere when the SRBs ran out (I think that at the time mainsails and 2.5m tanks were the best, so there was little point of not having a single engine at the bottom of each tank).

This experience lead me to try different configurations, understanding that the "one true means of asparagus" wasn't the only way to go.