[0.22-0.23.0] Payload Fraction Challenge

[numerobis]

You've got nose cones, which is against the rules, but so little of your mass is nose cones it probably doesn't matter.

You can save over 200t with minor changes:

* 180t by replacing the last stage fuel with an X200-8 and an X200-16 instead of two X200-32 in each stack. You'll still have fuel left over.

* 8t by dropping the adapters and nose cones on the boosters. They're pretty, but this isn't a beauty contest (leave them on the payload of course).

* 20t by using smaller decouplers.

Then you'll have fuel left over again; keep cutting. But just those changes get you over 16% payload.

You can also replace each mainsail with 50x 48-7S engines, saves 1t each and it's a more efficient engine. This part might be too tedious to bother with though

[mhoram]

Can you add a category for people like my self who use FAR? I know it decreases the Dv needed to reach orbit, but it also make rockets less stable during their gravity turn. And if you include FAR, can you also include KW (for the fairings only, no engines or fuel tanks?)

Since I have no experience with FAR and KW, I do not think, that I am an appropriate challenge hoster for these Add Ons or should decide on rules about them.

Data point: a high TWR rocket (using a T30) launched from 76m altitude burns 12 m/s more than the same rocket moved up on clamps to 128m. So it is a measurable improvement.

That is the reason why I included the rule that you should "keep the bottom of the rocket near the ground" when using clamps.

So, I want to start by saying that this darn thing made my computer angry with me, but it did the job.

Also, this is a refueling station so even tho there's RCS tanks on the station, there are no engines or RCS ports on the station so it complies with the rules.

Ultra Max on the launchpad. Prelaunch weight: 4585.51 tons 1736 Parts

Payload Fraction: 15.33% 7 Stages

The rockets are getting bigger and bigger. Nice monster!

You've got nose cones, which is against the rules, but so little of your mass is nose cones it probably doesn't matter.

For a payload of over 700ton, there would need to be many more drag<0.2-parts to have a noticeable effect. And nose cones are allowed as long as the resulting drag coefficient of the payload is ~0.2.

[700NitroXpress]

You've got nose cones, which is against the rules, but so little of your mass is nose cones it probably doesn't matter.

You can save over 200t with minor changes:

* 180t by replacing the last stage fuel with an X200-8 and an X200-16 instead of two X200-32 in each stack. You'll still have fuel left over.

* 8t by dropping the adapters and nose cones on the boosters. They're pretty, but this isn't a beauty contest (leave them on the payload of course).

* 20t by using smaller decouplers.

Then you'll have fuel left over again; keep cutting. But just those changes get you over 16% payload.

You can also replace each mainsail with 50x 48-7S engines, saves 1t each and it's a more efficient engine. This part might be too tedious to bother with though

Yeah, the nose cones only have 0.03 mass and 0.2 drag so I thought they would be fine. I might make those changes and go again a little later. Adding all of those 48-7S engines would suck because of the particle effect rendering on each one, that rocket would take an hour to get into orbit. It's already running at like 5 FPS. Whenever I use the smaller decouplers I get structural failures so this model works well with the larger ones. I think my major change will be cutting down on the fuel just a bit.

[numerobis]

Just replacing the 8 mainsails on the last stage with the 48-7S would take 800 parts. You'd still maybe manage as high as 3.4 FPS (at least if you turn off the particle trails). Of course at that point you need MechJeb.

[blizzy78]

My second entry in the 100 t category.

Standard asparagus design using 8 boosters. Final stage had only 4 m/s left before decoupling. Hands-free MechJeb launch.

Payload mass: 108.9 t

Liftoff mass: 644.0 t

Payload fraction: 108.9 t / 644.0 t ~= 16.91%

Number of stages: 5

Craft file

Javascript is disabled. View full album

[mhoram]

Yeah, the nose cones only have 0.03 mass and 0.2 drag so I thought they would be fine.

They have 0.1 drag.

My second entry in the 100 t category.

Payload fraction: 108.9 t / 644.0 t ~= 16.91%

Number of stages: 5

I like the Aerospikes and thanks for sharing the craft file! Moved your previous entry to the Attic.

[blizzy78]

I like the Aerospikes and thanks for sharing the craft file! Moved your previous entry to the Attic.

Well I have nothing to hide

I'm just sad I can't get over the 17% mark. And I'm not sure what gives :-(

[Kasuha]

I'm just sad I can't get over the 17% mark. And I'm not sure what gives :-(

You need to drop your empty tanks in smaller chunks. The larger tanks, the more dead weight you're carrying up to drop it later.

And that mainsail in the middle is just wrong. When you get up there you don't need that much thrust, you need an efficient engine.

My ship (use full resolution view to see the first image if you don't see the bottom, imgur seems to be screwing it up) was just a bit smaller than yours and used airspikes and nukes. I admit, four nukes were a bit weak for almost 100 tons payload, the ship dipped back to the atmosphere before it got up to speed. But maybe it could have been steered better.

[blizzy78]

You need to drop your empty tanks in smaller chunks.

I've tried that with my earlier 100 t entry - it didn't work out too well. I don't quite remember why, though. On top of that, it gets quite complicated because it adds a lot of stages.

And that mainsail in the middle is just wrong. When you get up there you don't need that much thrust, you need an efficient engine.

That's what my calculator (see signature) recommended, so I just took it. Also note that yes, the thrust is necessary, because it's an asparagus design. This single engine is lit the entire time. I do agree however that it might be replaceable with more efficient engines to match the same thrust, but that can be impossible at times because of the no-clipping rule.

[numerobis]

The 20.1% solution can be scaled up trivially any integer number of times: make it a subassembly, and slap on a few 20.1% towers. I did that at 4x and of course it worked fine for 30t of payload, precisely the same payload fraction.

Unfortunately I haven't managed to get much in the way of synergy. You save decoupler mass by merging the towers, but that's already very little mass. Alternately you can ditch tanks sooner, but again, not major savings (you could also dump engines for every 2t of tank dry mass dumped -- if you're going for more than 4x). Lastly, I tried staging the nukes: the circularization burn and coasting through the atmosphere don't require much thrust. That lets you reduce the total fuel on the nuke stages, by a whole half-tonne. Lastly, all this work makes the rocket tall. But even with all these tricks I'm only improving to 20.2%, doesn't seem worth an entry.

I think the more important bit is finding a better flight plan for the rocket; at this point it feels like only reducing the deltaV requirement is going to let me save mass.

[Forgot to mention: I coded up shutting off engines in order of Isp if throttle falls, which occurs for about 5 seconds in my flight plan. That made a tiny improvement.]

Edited November 15, 2013 by numerobis

[Kasuha]

I think the more important bit is finding a better flight plan for the rocket; at this point it feels like only reducing the deltaV requirement is going to let me save mass.

Finding optimum ascent strategy for given ship sounds like intriguiging problem. The phase space is not too big - it has only three dimensions, altitude, vertical speed and horizontal speed. Then optimally reachable states at given time t form a surface in it. It could be possible to iterate these surfaces over time till we reach the required point, then backtrack optimum approach from that point back to the launch. We can assume some 98% constant thrust to give the drive some space for corrections and thanks to iterating over time we get staging events at given surfaces so the sudden change in thrust and weight is applied at once.

[numerobis]

I just saw kOS. Looks like a good way to be able to try radically different strategies than what MechJeb offers!

[mhoram]

The 20.1% solution can be scaled up trivially any integer number of times: make it a subassembly, and slap on a few 20.1% towers. I did that at 4x and of course it worked fine for 30t of payload, precisely the same payload fraction.

That is quite interesting as it is very modular and scaleable, but this also means a lot of parts are needed for all the 48-7S and struts.

From the entries it is quite clear that the most efficient engines are the 48-7S and LV-N. Perhaps the 48-7S will be nerved again in 0.23.

Finding optimum ascent strategy for given ship sounds like intriguiging problem. The phase space is not too big - it has only three dimensions, altitude, vertical speed and horizontal speed. Then optimally reachable states at given time t form a surface in it. It could be possible to iterate these surfaces over time till we reach the required point, then backtrack optimum approach from that point back to the launch. We can assume some 98% constant thrust to give the drive some space for corrections and thanks to iterating over time we get staging events at given surfaces so the sudden change in thrust and weight is applied at once.

It is not that simple. The phase space as you describe it, contains also infos like remaining fuel and orientation.

In order to find the optimum ascent strategy for a given rocket, I would rather set certain parameters like altitude, duration and angle of pitchover maneuver, ... and simulate the ascent with lots of random values. In an iterative process the best values can be found. This approach however is restricted by the flight-paths that can be described by the parameters.

I just saw kOS. Looks like a good way to be able to try radically different strategies than what MechJeb offers!

Looks very interesting.

[700NitroXpress]

They have 0.1 drag.

Yeah, I just saw that when I looked at the part. I'm making a bigger vessel now tho that doesn't have any. Over 1.2 kilotons!

The Goliath Fuel Depot 1281.62 ton payload! and it can currently gets off the ground so that's a start.

Edited November 16, 2013 by 700NitroXpress

[JUDUFU]

8.97 payload

56.43 ship mass at launch

15.90% payload decimal

5 stages (initial + 4 drop)

Drag coefficient shows up as .197 because of mechjeb on the payload. I hope that's not disqualifying considering you did say we could use mechjeb.

I used a similar design to Scott Manley's ship in this video. I'd call it Donkey Kong staging.

There's a few extra images of moar boosters in the album.

Javascript is disabled. View full album

[Kasuha]

It is not that simple. The phase space as you describe it, contains also infos like remaining fuel and orientation.

In order to find the optimum ascent strategy for a given rocket, I would rather set certain parameters like altitude, duration and angle of pitchover maneuver, ... and simulate the ascent with lots of random values. In an iterative process the best values can be found. This approach however is restricted by the flight-paths that can be described by the parameters.

Remaining fuel is given by time which is constant for given surface and so is TWR (TMR). I said we assume constant 98% thrust all the time. Orientation is irrelevant, by extending each point of the surface using its optimum orientation you ensure the orientation change is smooth throughout the trajectory, whatever trajectory you choose.

Using lots of random values may sound simpler but in fact it's only scanning individual curves in the phase space instead of scanning it entirely.

Edited November 16, 2013 by Kasuha

[mhoram]

The Goliath Fuel Depot 1281.62 ton payload! and it can currently gets off the ground so that's a start.

Good luck with that one, the part count should be quite memorable

8.97 payload

56.43 ship mass at launch

15.90% payload decimal

5 stages (initial + 4 drop)

Thanks for the entry! It has an unusual layout.

Remaining fuel is given by time which is constant for given surface and so is TWR (TMR). I said we assume constant 98% thrust all the time. Orientation is irrelevant, by extending each point of the surface using its optimum orientation you ensure the orientation change is smooth throughout the trajectory, whatever trajectory you choose.

Using lots of random values may sound simpler but in fact it's only scanning individual curves in the phase space instead of scanning it entirely.

Taking thrust as constant will not always result in the best trajectory, because the TWR of some ships is so high that it wil travel faster than the terminal velocity, which results in non-optimal draglosses.

Scanning the phase space entirely seems like a theoretical approach while testing random values is more a practical approach.

How do you measure if a state is an "optimally reachable state"?

[Kasuha]

Taking thrust as constant will not always result in the best trajectory, because the TWR of some ships is so high that it wil travel faster than the terminal velocity, which results in non-optimal draglosses.

You're right but in my opinion, if you need to throttle down during ascent then your ship is suboptimal already because you're carrying unnecessary engine weight. But I believe my approach could be improved in the sense that the surface in phase space is representing not certain time since launch but certain amount of remaining fuel. If you can reach that point with more fuel if you throttle down, it becomes part of potential solution.

Scanning the phase space entirely seems like a theoretical approach while testing random values is more a practical approach.

Random path search is just an ineffective approach to mapping the phase space. You map a path, then abandon most of what you scanned and go mapping again. Systematic mapping of phase space consists of actually storing information not just about the end point you reached but also all points you passed so they can be used in future searches. It's irrelevant whether these points are chosen randomly or systematically but of course it's the more effective the more of the phase space is covered.

How do you measure if a state is an "optimally reachable state"?

I'd declare the way to reach the state with most remaining fuel the optimal solution.

[700NitroXpress]

Good luck with that one, the part count should be quite memorable

Yeah, it's the heaviest sucker I've ever attempted to put into orbit. Payload fraction or not, I do this also for the challenge of extreme weight payloads. I haven't tried lightweight things yet, although I might submit something for that too. Is it ok for the same person to submit for multiple weight categories?

[Nao]

@Kasuha and mhoram discussion

Actually i think good way of tackling the problem would be to devise an optimal flight profile for a craft with infinite TWR (instant speed changes). It looks simple but actually has much behind it, and i'm not good enough in maths to do it.

After that adding TWR requirements and ISP changes for particular craft could be much easier.

[mhoram]

Is it ok for the same person to submit for multiple weight categories?

Yes that is perfectly ok. Originally I made the three categories to tackle different problems: the <10 for easy going, the <100 for standard rockets and the >100 for cases where one has to take care about structural problems.

if you need to throttle down during ascent then your ship is suboptimal already because you're carrying unnecessary engine weight.

I see it the same way. But since we have only a limited set of engines, it will never be possible to get the perfect engine distribution. So either they are too strong or too weak - pick your poison.

But I believe my approach could be improved in the sense that the surface in phase space is representing not certain time since launch but certain amount of remaining fuel. If you can reach that point with more fuel if you throttle down, it becomes part of potential solution.

Sounds like a good idea.

Random path search is just an ineffective approach to mapping the phase space. You map a path, then abandon most of what you scanned and go mapping again. Systematic mapping of phase space consists of actually storing information not just about the end point you reached but also all points you passed so they can be used in future searches.

I'd declare the way to reach the state with most remaining fuel the optimal solution.

I see - so this is some kind of Dijkstra's algorithm.

@Kasuha and mhoram discussion

Actually i think good way of tackling the problem would be to devise an optimal flight profile for a craft with infinite TWR (instant speed changes). It looks simple but actually has much behind it, and i'm not good enough in maths to do it.

After that adding TWR requirements and ISP changes for particular craft could be much easier.

I think, that this would help designing optimal rockets, but not help finding the best ascent path for a given rocket.

The flight path depends very much on the TWR distribution, so I am not yet convinced that this method has advantages, although it should be quite easy to simulate.

[Nao]

I think, that this would help designing optimal rockets, but not help finding the best ascent path for a given rocket.

The flight path depends very much on the TWR distribution, so I am not yet convinced that this method has advantages, although it should be quite easy to simulate.

But that's the thing. If we don't even know a solution to an unrealistic ideal case, how can we try solving a much more complex problem.

The infinite TWR case actually has most of what we try to optimize for.

Right now we know only about ~7km of vertical ascent, and that is: follow terminal velocity. But after starting gravity turn (at 10-12km) we already need to throttle down to coast through part of the turn, then throttle up as we go more horizontal then throttle down again while gravity drag goes down and we approach corrected terminal velocity again, and then throttle up once more at the end when we are going out of atmosphere.

The infinite TWR idea just makes sure our simulation craft can change speed as it suits the flight path. Without including an additional parameter to work with: actual thrust.

When we know the perfect path, then we can impose restrictions on acceleration and see what brings us the least losses, and then combine that with actual KSP part data (engine weight, isp etc.) to get the best ascent path for an actual design.

[Seanner]

My preferred method for solving this would be random search, either by explicitly doing something like random walk or using a genetic algorithm. The math seems a bit complex to "solve" but a computer flying millions of variations of the path per second can probably come up with a near-optimal solution fairly quickly...so if we can live with knowing what gets us 100.0002% of best fuel usage, I believe the problem is simple enough.

If I can find enough info on the physics within KSP I shall make one today (seems to be the hardest part).

[Nao]

The physics will be pretty simple, both for drag and gravity. The bigger problem would be the things like, randomizing non linear changes in thrust and steering error.

Thing's like randomizing a height at witch gravity turn takes place would be easy, but I fear that we would need to make some simplifications to make the random method work for non linear changes. Like set a randomized thrust for a randomized start and stop duration. And this comes down to granularity(word?) of changes, so the good enough solution could take some serous computing power.

... After thinking about this for some time before posting, it looks possible. Like each X seconds the rocket could randomize thrust and steering error, and for each flight randomize starting height of gravity turn.

Oh and the granularity should probably be adjusted to be denser during gravity turn (mid ascent).

Anyways good luck then, can't wait to see any results .

[mhoram]

Anyways good luck then, can't wait to see any results .

As it seems, this is an interesting discussion and since it is a little bit off-topic I created a separate thread for this discussion to continue, where I included my implementation of the ascent-simulation.