sevenperforce
-
Posts
8,925 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Bug Reports
Posts posted by sevenperforce
-
-
7 minutes ago, Exoscientist said:
The main goal is to create a super heavy lift launcher at a much lower cost than the SLS. Then an approx. 90+ tons to LEO launcher is acceptable as it makes possible a single-launch architecture for manned lunar missions.
In keeping with the low cost goal, using liquid fueled side boosters is acceptable as they would be much lower cost than the SLS solid boosters and would be reusable.
90 tonnes to LEO is not enough for single-launch manned lunar missions.
To be clear, the Falcon 9 SLS booster concept I describe above is absolutely NOT a reusable architecture. SLS liquid booster reuse is a VERY long pole.
-
47 minutes ago, Kerballlistic07 said:
The only issue I can really see with using an inflatable heat shield is that it might not be reusable. I haven’t looked into it a ton, but wouldn’t it be too damaged to reuse? Also deflating it and getting it ready for reuse might be too much. If they can make it cheap enough, it might not matter though.
Oh, I doubt the recovery elements would be particularly reusable. That's in line with ULA's overall approach to reuse. With SMART, they aren't going to be reusing the tanks or the heat shield or the parachutes; just the engines. So it would make sense for them to use disposable recovery elements to recover the more expensive hardware.
I would really love to see an exploration of new recovery modes and an expansion of available data. One near-future concept for reusable re-entry vehicles is the reversible deployment of large-volume drag structures (deployed either by pressurants or electromagnetically) that slow vehicles rapidly at ultra-high altitude before there is appreciable heating. We need more data on inflatable heat shields to see how that would actually work.
-
10 hours ago, Exoscientist said:11 hours ago, tater said:11 hours ago, Exoscientist said:
Do the calculation with the Ariane 5 core as the upper stage.
Would not fit in the VAB as he said, so why bother doing the math?
Actually it would. The limits for the length of an upper stage for the SLS are based on specs for a supposed second mobile launcher for the SLS which has to be provided to the manufacturer of the mobile launcher. But that second mobile launcher has not been constructed yet, and the manufacturer has been greatly criticized for costs overruns and delays. A commercial approach would probably just choose a different manufacturer for the second mobile launcher such as SpaceX.
The doors of the vehicle assembly building are quite huge and can accommodate the size of the SLS core and Ariane 5 as a second stage:
Vehicle Assembly Building.
There are four entries to the bays located inside the building, which are the four largest doors in the world.[14] Each door is 456 feet (139.0 m) high...With the existing mobile launcher design, there is an 18-meter height available for the upper stage. The current mobile launcher base comes 7.6 meters above the ground and has a launch umbilical tower that is 108 meters higher than that, reaching 5.7 meters higher than the max height of Block 1B.
The Ariane 5 core is 23.8 meters high. Putting it into SLS as the second stage would lift the height of this new "Block 1F" (F for Frankenrocket) above the height of the current launch umbilical tower, which is already what limits the height relative to the VAB doors.
The only option is to build a crawler-transporter that carries SLS lower to the ground. I'm not sure how we are going to manage that. SLS is heavy.
12 hours ago, Exoscientist said:22 hours ago, sevenperforce said:To start with, let's do a one-to-one comparison with the current SLS to see if we have improved anything. If it's not improved, then swapping out upper stages is something that could as readily be done on the current SLS.
Do the calculation with the Ariane 5 core as the upper stage. A commercial space approach wouldn’t use such a tiny upper stage such as the ICPS for a rocket this size when larger, appropriately-sized upper stages are available
As I said, you need to start with a one-to-one comparison to see if ditching boosters and using RS-68s improves anything on the lower stage, before proposing a different upper stage. Otherwise you're changing multiple variables at once, which muddies the water. If changing the lower stage makes things worse, then you should drop that plan entirely, before talking about combining a bad lower stage with a new upper stage.
Also, the Ariane 5 core is not "available" at all; it's not even being made.
Also also, the Ariane 5 core had a Vulcain 2 on it, which is not a vacuum engine and gets really poor vacuum specific impulse compared to a proper upper stage.
But if you're calling the ICPS "tiny" then you should also be calling the Ariane 5 core "tiny" in comparison to the EUS for Block 1B. The EUS carries 76% more propellant than the Ariane 5 core. The Ariane 5 core is extremely narrow compared to EUS. A reasonable space approach wouldn't use such a skinny, narrow stage as the A5 core for an upper stage when larger, appropriate-width upper stages are available.
1 hour ago, Exoscientist said:10 hours ago, SunlitZelkova said:As long as we’re doing a total franken rocket, couldn’t we put Crew Dragon on top?
It would probably need a proper service module though, and I’m not sure how that would impact mass. And of course, a beefed up heat shield.
As I recall, the crew Dragon for a lunar mission would need only minor modifications such as a more powerful communications system for communication from the Moon. It was already given sufficient heat shield capability in its design for return from escape velocity, which is higher than just return from LEO.
Crew Dragon has some re-entry stability issues due to the greater height-to-width ratio of its OML compared to more traditional capsules. It's fine for LEO returns but I don't believe it can handle the higher angle of attack needed for cislunar returns.
More importantly, though, it doesn't only need a more powerful communications system; it needs a service module. Its onboard propellant reserves are not enough for a lunar return, and certainly not enough for a lunar orbital insertion (in fact it can't even fire its main propulsive vacuum thrusters while attached to another module).
And again, at this point, why are we bothering with SLS at all?
21 hours ago, tater said:23 hours ago, sevenperforce said:ape the old Saturn S-1D Mega Atlas design
I frickin love that thing.
Now you've got me wondering what the maths would look like.
The SLS core carries 29.9% more propellant than the Shuttle did. The intertank is essentially identical (not unlike the Ariane 5, the thrust of the solid boosters is transmitted in large part through the intertank in both the SLS and STS designs, leaving the hydrogen tank to hang in tension until booster separation). The SLS core masses 85.3 tonnes without engines. Crunching the numbers, you get roughly 34.4 tonnes for the tankage, 16.1 tonnes for the forward skirt section, and 34.7 tonnes for the engine boattail section sans engines. Note that SLS Block 1 also carries the 4.5-tonne LVSA adapter for ICPS.
Let's imagine a few alternate possibilities inspired by the S-1D design. With all of these, I'm going to compare solely to SLS Block 1 to get an idea of what is actually possible, with the understanding that adding EUS to the design will create further improvements. To that end, everything north of the LOX tank remains identical: the same forward skirt, the same stage adapter, the same ICPS, and so forth, and total height must remain the same as well.
For reference, here's the aft end of the current SLS:
We plug in the following values for SLS Block 1 to LEO with Orion:
Booster 1st Stage 2nd Stage Dry Mass, kg 102058.3 103872.1 3490 Propellant, kg 623689.5 952544 30710 Thrust, kN 17595 9116 110.1 Isp, seconds 268 452.3 462 We use default prop residuals, a restartable upper stage, and set a "payload fairing" of 6,926 kg (that's Orion's LAS) to jettison at 120 seconds. Launching from Cape Canaveral to a reference orbit of 185x185 km at 28.5 degrees using a two-burn ascent gives 85,671 kg to LEO. Note that this is under the earlier estimate both because of the addition of Orion's LAS and because I was using a number for the dry mass of the first stage that didn't include the mass of the engines or the LVSA.
Time to get creative! Let's start small. Suppose that we keep the existing RS-25s but split that 34.7-tonne boattail engine section into two parts, one of which is attached to the core stage and one of which can be jettisoned:
When do we jettison the outboard engines? Well, the boosters burn out and separate at T+131 seconds, after the core has burned 269.1 tonnes of hydrolox. At separation, then, SLS Block 1 has a T/W ratio of 1.13, not including payload. If we want this same T/W ratio to be maintained at outboard engine jettison, where our thrust will be cut in half, we need to wait to T+331 seconds, at which point there will be just 272.7 tonnes of hydrolox remaining in the tanks. For the purposes of plugging everything into the launch performance calculator, this creates a simulated three-stage architecture, where the "dry mass" of the "1st Stage" is merely the mass of the discarded outboard engines and engine section and the "propellant" of the "1st Stage" is the total prop burned at jettison, with all four engines as the "thrust" of the "1st Stage" and only two for the "2nd Stage":
Booster 1st Stage 2nd Stage 3rd Stage Dry Mass, kg 102058.3 24404 79468.1 3490 Propellant, kg 623689.5 679858 272700 30710 Thrust, kN 17595 9116 4558 110.1 Isp, seconds 268 452.3 452.3 462 Plugging this into the calculator, with the same other parameters listed above, gives 94,523 kg to LEO. Now, before you go and say "wait, that's only what SLS Block 1 can already do!", remember that this is comparative to the 85.7 tonnes that the calculator gave us for SLS Block 1 before, which was notably low (in part because of the Orion LAS jettison). So in reality, we're talking about a ~10% improvement in payload just by dropping these engines at the correct time.
Now, let's go one step further and replace those two outboard engines with RS-68As and only put a single RS-25 on the core:
The RS-68A is only ever so slightly larger than the RS-25. The major issue with putting them on the aft end of the planned Ares V was that the heat flux from the solid boosters would have melted them, but hopefully with greater distance from the solid motors they will be in better shape here. I'm sure we can afford to slap some extra heat shielding on here somewhere if necessary.
Together, a single RS-25 and a pair of RS-68As produce 9396 kN of thrust, just slightly more than four RS-25s. Good start so far. The specific impulse of the trio in combination is now going to be 421.8 seconds, based on thrust-specific Isp. The weight of the engine section is a function of the max thrust it has to transfer to the vehicle, so the total engine section weight is going to go up from 34.7 tonnes san engines to 35.8 tonnes. However, 75.7% of that is going to be in the thrust structure for the RS-68As, meaning more mass can be jettisoned. However, we'll have to burn all three for longer in order to make sure our thrust-to-weight is in good shape when we jettison. Because we are going to be jettisoning later (as in, nearly-to-LEO), gravity drag will be much lower and we can get away with a T/W ratio on the order of ~0.85.
In the end, we get this:
Booster 1st Stage 2nd Stage 3rd Stage Dry Mass, kg 102058.3 40608.4 62730.2 3490 Propellant, kg 623689.5 782100 170444 30710 Thrust, kN 17595 9396 2279 110.1 Isp, seconds 268 421.8 452.3 462 Once again plugging this into the calculator with the same parameters as before, we get a disappointing 86,717 kg to LEO. This is still technically an improvement over SLS Block 1, but it's not nearly as much of an improvement as our first concept. That's not too surprising; that extra 40 seconds of specific impulse on the RS-25 over the RS-68A makes a big difference. This is a sustainer architecture and so the extra thrust on the core stage doesn't do all that much for us.
Finally, let's try a combination of these two designs: two RS-25s in the center and two RS-68As outboard:
Now the core is really starting to get beefy. The total core thrust comes up to 11.7 MN so we need to beef up our engine section weight to 44.5 tonnes. Doing all the math as above, we get this:
Booster 1st Stage 2nd Stage 3rd Stage Dry Mass, kg 102058.3 40608.4 79468.1 3490 Propellant, kg 623689.5 679858 272700 30710 Thrust, kN 17595 11675.3 4558 110.1 Isp, seconds 268 427.7 452.3 462 Unfortunately, this only gets us 84,567 kg to LEO. The extra thrust isn't being utilized well, and the extra weight is prohibitive.
The RS-25 is a hard engine to beat.
Just for the fun of it, let's come up with a REALLY wild proposal. Let's get rid of the SRBs entirely and replace them with Atlas V first stage boosters, and let's put a grand total of five engines on the core (four RS-68s and one RS-25). We'll stack a pair of additional Atlas V LOX tanks on top of each one, which we will use to crossfeed the RS-68As:
Things are a little bit different now. The boattail section doesn't have to transmit nearly as much booster force and so I'll leave its total mass no greater than for the 2-and-2 design (though obviously it is getting two more RS-68A engines at an unpleasant 6,740 kg each). The empty mass of each booster is 21,054 kg, plus the weight of two LOX tanks which I will ballpark at an additional 30 tonnes per pair. Here the dry mass is added to the boosters but the propellant mass is added to the core, effectively, thanks to crossfeeding. Each pair of extra LOX tanks will hold 415442 kg of LOX (we will move the bulkhead in the core but otherwise everything will be as it was). Our numbers look like this:
Booster 1st Stage 2nd Stage 3rd Stage Dry Mass, kg 51054 54088.4 62730.2 3490 Propellant, kg 284089 1510742 170444 30710 Thrust, kN 4152 20072.2 2279 110.1 Isp, seconds 337.8 417.6 452.3 462 To my delight, this gets 86,952 kg to LEO -- not as high as some of the other designs above, but really very impressive considering that we've completely ditched those big solid boosters entirely!
We can also do the same design but use expendable Falcon Heavy side boosters (still sticking with the Atlas LOX crossfeed tanks so I don't have to rework the math):
The numbers:
Booster 1st Stage 2nd Stage 3rd Stage Dry Mass, kg 55600 54088.4 62730.2 3490 Propellant, kg 395700
1510742 170444 30710 Thrust, kN 8227 20072.2 2279 110.1 Isp, seconds 311 417.6 452.3 462 This configuration gets an absolutely whopping 121,720 kg to LEO with just ICPS on top. Replace ICPS with EUS as planned for Block 1B, and it can send 144 tonnes to LEO or 63.7 tonnes to TLI, nearly 40% more than the mythical SLS Block II and well over what Saturn V could do.
-
31 minutes ago, Kerballlistic07 said:
I think that if they don’t use an aerospike engine like Stoke, they would use an inflatable heat shield similar to what they currently plan to do with SMART reuse. (A Starship style second stage doesn’t seem likely to me.) They could either then try and flip the stage around and propulsively land it, or they could use parachutes and catch it with a helicopter.
Agree that ULA is less likely to just ape SpaceX on the second stage.
A Stoke-like aerospike adaptation of ACES isn't out of the question. But of course I want to see new and better ideas. It would be really cool if they used SMART reuse as a testbed for an inflatable ballute heat shield. ULA is much more likely than SpaceX to utilize disposable elements on an otherwise-reusable vehicle (see, e.g., Starliner). Prior to re-entry, the upper stage could vent remaining hydrogen pressurant gas into a series of inflatable phenol-impregnated bladders that would form a ring around the payload adapter, stretch up the sides of the vehicle, and shroud the engine bay. Those inflatable bladders would both increase the re-entry cross-section (which decreases heating) and absorb the bulk of the heat flux, then finally act as airbags to cushion the vehicle on its desert touchdown.
It's still not the VTOL spaceplane we all REALLY want, but it would be cool if they could get it working.
If they REALLY wanted to think outside of the box, they could build a lifting-body design with aerospike engines located in the wing strakes, perpendicular to the long axis of the vehicle. The booster carries the vehicle up and out of the atmosphere, so after separation the vehicle could simply rotate 90 degrees and thrust to orbit that way. That helps with the descent and landing portions of the re-entry because the vehicle can glide to the landing site and then fire its landing engines to hover its way down.
-
5 hours ago, Kerballlistic07 said:
I live 20ish miles from the pad and I’ve started taking my telescope out for the launches and tracking them. The views are spectacular. This one was probably my favorite I’ve ever tracked. The way the plume changes colors is just incredible!
Damn I'm jealous
-
On 10/17/2023 at 1:49 AM, Exoscientist said:On 10/16/2023 at 11:01 AM, sevenperforce said:
Your blog post also speculates that 2,500 kg is enough for a 3-person crew capsule. It is not. Your example, Cygnus, has a mass of 3,300 kg in its smallest configuration, BEFORE a heat shield, aeroshell, life support, parachutes, seats, or actual passengers. Using the two-person Gemini capsule as an example, the heat shield alone needs to be on the order of 7-10% of the total re-entry vehicle weight. Even setting aside the need for a new aeroshell, a Cygnus-based capsule would be on the order of 4,700 kg (339 kg heat shield, 230 kg for chutes, 133 kg integrated RCS, 78 kg RCS propellant, 350 kg crew seats and provisions, 270 kg crew). We haven't even talked about a launch escape system, which adds extra weight for the first few minutes of launch.
Actually, the relevant scenario is the two-stage case of a half-size Ariane core with a ca. 10 ton upper stage, so it is loftable by a single Vulcain.
Your post is the one that said 2,500 kg is enough for a 3-person crew capsule, which is not correct.
As for this other proposed vehicle...
QuoteWe can get a higher payload manned launcher by making it TSTO. We'll use the cryogenic upper stage the Ariane H10-3. The Astronautix page gives it a gross mass of 12,310 kg and dry mass of 1,570 kg, for a propellant mass of 10,740 kg. The Isp is listed as 446 s with a vacuum thrust of 62.70 kN. However, this extra mass for the upper stage would mean the single Vulcain II on the core could not loft it.
Then we'll reduce the propellant load in the core stage. It might also work to run the Vulcain at some percentage above the rated thrust, or use a varied mixture ratio at launch compared to high altitude. But using a reduction of the propellant load method, we'll lessen the propellant in the first stage by the mass of the upper stage, so by 12,310 kg. This brings the propellant load of the first stage to 66,690 kg. There is about a 35 to 1 ratio of propellant to tank mass so this will reduce the tank mass of the first stage by 12,310 kg/35 =350 kg. Then the dry mass of the core becomes 7,750 kg.
Per my notes above, the dry mass of this core would actually be 8,175 kg, taking the rest of your new numbers as assumptively correct (which I think is a generous assumption). For a crew launch vehicle you're also going to need an LAS, which I will ballpark at 2,030 kg for a notional 2,900 kg command module (the weight of the Cygnus-based capsule described above less the 1,800 kg service module) based on weight ratios of the Orion and other abort systems. I will set it to jettison 10 seconds after booster burnout to give time for separation and second stage engine startup.
1.34 MN divided by 431 seconds of specific impulse gives a propellant flow rate of 316.9 kg/s, so those 66.7 tonnes of propellant will be burned through in 210 seconds. Thus LAS jettison takes place at 220 seconds.
Finally, to try and begin to account for the extra 300-400 m/s of gravity drag, I'm going to set the destination orbit to 185x1300 km, which is the equivalent of burning into a 185x185 orbit and then adding 300 m/s of additional dV. All told, this results in an estimated payload of 3,834 kg, still about a tonne shy of what is actually needed.
On 10/17/2023 at 1:49 AM, Exoscientist said:All would be reusable and manned-flight capable.
Such a first stage would not in any way be reusable.
12 hours ago, Exoscientist said:No one in European space community is willing to ask or answer the question, “How much just to add a second Vulcain to the Ariane 5/6 core?”
No matter how cheap it is to add a second Vulcain to the Ariane core, it's still too expensive if the resulting vehicle can't reach orbit.
-
On 10/17/2023 at 11:19 AM, Exoscientist said:
Instead, for a commercial replacement keep the hydrolox core stage but replace the expensive SSME’s with RS-68’s, to save on costs. Five RS-68’s would be required to enable lift-off.
It could also be done with 7 SSME’s but the so-called “improved” versions now have bloated prices of ~$150 million per engine, compared to the original price of $50 million each. Seven of them would be a billion dollars just in engines alone.
The RS-68 in contrast costs in the range of $10 to $20 million each, So 5 would be just $50 to $100 million. Note the RS-68 was considered for the SLS but its ablatively cooled nozzle would not handle well the extreme heating from the side boosters. But without the side boosters, that’s no longer an issue.
A regeneratively cooled nozzle version of the RS-68 was investigated. It would raise the vacuum Isp to ~421.5s compared to the 412s of the current version, and increase thrust about 20 tons. You would want to do this at some point to improve reusability.
For the upper stage, we could use the Delta IV core, or the Boing EUS, or the Ariane 5 core. I favor the Ariane 5 core because it has both a high mass ratio and high vacuum ISP.
The Ariane 5 core is twice the max height of the VAB.
On 10/17/2023 at 11:19 AM, Exoscientist said:I estimate in the range of 100 tons to LEO.
Well, let's not get ahead of ourselves.
To start with, let's do a one-to-one comparison with the current SLS to see if we have improved anything. If it's not improved, then swapping out upper stages is something that could as readily be done on the current SLS.
Taking the specifications of SLS Block 1 as follows...
Booster 1st Stage 2nd Stage Dry Mass, kg 102058.5 85275 3490 Propellant, kg 623689.5 952543.9 30710 Thrust, kN 17595 9116 110.1 Isp, seconds 268 452.3 462 ...the Silverbird Astronautics calculator gives an estimated 97.2 tonnes to a 185x185 orbit from Cape Canaveral, with the 95% confidence interval running from 79.0 tonnes to 118.6 tonnes. That's just 2% over the actual stated LEO performance of SLS Block 1 according to NASA, so we can be pretty confident that Silverbird is giving us good results in this configuration.
So now let's redo it, but get rid of the boosters altogether and replace the four RS-25s with five RS-68s. First stage dry mass goes up by 19 tonnes (each of the RS-68s is almost twice as heavy as each RS-25), first stage vacuum thrust goes up to 17800 kN, and first stage vacuum specific impulse drops to 414 seconds:
1st Stage 2nd Stage Dry Mass, kg 104275 3490 Propellant, kg 952543.9 30710 Thrust, kN 17800 110.1 Isp, seconds 414 462 Running the numbers to the same orbit, we get a truly abysmal 35.7 tonnes, with a 95% confidence interval running from 28.7 tonnes to 44.6 tonnes.
On 10/17/2023 at 11:19 AM, Exoscientist said:I have argued large solid rocket boosters are not cost effective.
I don't like large solid boosters any more than the next person, but you can't discount the heavy lifting they are (literally) doing in the SLS design. Removing the boosters would mean removing 40% of the total propellant in the stack and you can't make up for that much of a loss with a higher-thrust core.
If we are speculating wildly about a better SLS design that would still use the same core tankage, one tempting option would be to ape the old Saturn S-1D Mega Atlas design:
One RS-25 in the center, four RS-68s on the outer thrust ring. Use Atlas Vs or Falcon 9s as side boosters and mount Delta IV common booster core oxygen tanks on top of them, so that you feed the two of the RS-68s their LOX from the side boosters. All four of the RS-68s get all of their liquid hydrogen from the core. Two of the RS-68s lose LOX and shut down at side booster separation, and then the other two shut down a minute or so later and the entire skirt is dropped once the thrust to weight ratio of the stack is optimal. No crossfeed necessary (although crossfeed would definitely improve performance). The core common bulkhead would need to be shifted slightly but the tankage mass and vehicle height would remain the same.
-
16 hours ago, Exoscientist said:
The leadership of the Vega team can not acknowledge the same issue as the Ariane 6 team, large solid rockets are not price competitive. Like with the Ariane 6, to be price competitive the solid rocket launcher Vega needs to be replaced by an all-liquid rocket:
Saturday, November 29, 2014
A half-size Ariane for manned spaceflight.
https://exoscientist.blogspot.com/2014/11/a-half-size-ariane-for-manned.htmlYour blog post at that link contains assumptions and calculations that are not representative of reality.
As previously discussed, the Ariane 5G hydrogen tank is a hyper-thin balloon tank that is "hung" from the JAVE element; it is supported by tension rather than compression when it is under regular Earth gravity. If you remove the JAVE element then you'd need to strengthen the balloon tank by at least half the weight of the JAVE if not more.
This completely newly-designed first stage you're contemplating would have a dry mass of at least 8525 kg. With your contemplated ~2500 kg payload and 79 tonnes of hydrolox propellant, gross liftoff weight is just a hair over 90 tonnes. At sea level, the Vulcain 2 developed 318 seconds of specific impulse and 0.99 MN of thrust; in vacuum it developed 431 seconds of specific impulse and 1.34 MN of thrust. With a 90-tonne GLOW, that's a liftoff T/W ratio of 1.1, which is too sluggish for an SSTO design that needs high initial acceleration to avoid gravity drag penalties. Compared to a more typical launch vehicle we are talking about an additional 300-400 m/s of gravity drag.
Plugging the wrong numbers into the launch performance calculator will produce fictitious results. If you give it the wrong specific impulse then it's going to overestimate, particularly with an SSTO concept where specific impulse has such a high impact. Additionally, because the Vulcain 2 is highly underexpanded at sea level, the calculator will be using too high of a sea level specific impulse and too high of a sea level thrust, so it will underestimate gravity drag. Using the actual dry mass and actual vacuum specific impulse, the calculator gives just 1539 kg of estimated payload, and that's using too generous of a sea level specific impulse and ignoring that extra gravity drag.
Your blog post also speculates that 2,500 kg is enough for a 3-person crew capsule. It is not. Your example, Cygnus, has a mass of 3,300 kg in its smallest configuration, BEFORE a heat shield, aeroshell, life support, parachutes, seats, or actual passengers. Using the two-person Gemini capsule as an example, the heat shield alone needs to be on the order of 7-10% of the total re-entry vehicle weight. Even setting aside the need for a new aeroshell, a Cygnus-based capsule would be on the order of 4,700 kg (339 kg heat shield, 230 kg for chutes, 133 kg integrated RCS, 78 kg RCS propellant, 350 kg crew seats and provisions, 270 kg crew). We haven't even talked about a launch escape system, which adds extra weight for the first few minutes of launch.
You then suggest that altitude compensation can raise the vacuum specific impulse of Vulcain 2 to 466 seconds. It cannot. It is thermodynamically impossible for a gas-generator hydrolox engine to achieve 466 seconds of vacuum specific impulse. The reality: as a sustainer architecture, Vulcain 2 is already an altitude-compensated nozzle akin to the RS-25. Adding a more complex altitude-compensating nozzle might help with sea level thrust and thus counteract some of the gravity drag issues, but it would decrease vacuum specific impulse. So putting those fictitious numbers into the calculator will produce fictitious results (and even the fictitious 4,544 kg isn't enough to get a Cygnus-based capsule into space).
Subsequent calculations merely compound the error.
-
On 10/13/2023 at 10:40 AM, Geonovast said:On 10/13/2023 at 10:19 AM, sevenperforce said:
Successfully landed the boosters! Quite a significant difference in timing between the return of the two boosters...more than I remember from earlier FH flights.
Yeah... pretty big difference. Long enough for the panic of "Oh no, they lost one!" to start.
On 10/14/2023 at 1:30 PM, tater said:I really wonder why. Even the guy on the NASA livestream (I refuse to watch this stuff on Xwitter) said it was noticeably different.
There are a few options, I guess:
- SpaceX could be transitioning to a longer, staggered booster separation process, either to reduce the odds of a post-separation impact or to increase performance
- SpaceX could be experimenting with a new return boostback trajectory to increase performance
- One booster could have experienced a randomly greater wind buffeting, engine thrust fluctuation, or other random event which altered its return trajectory
Of these, 3 seems least likely (those things can happen but it's hard to imagine them having THAT big an impact). Both of the others seem reasonably possible. A staggered booster separation could increase performance by allowing one booster to burn out sooner than the other, making it more like three separate parallel stages than two.
-
On 10/15/2023 at 1:19 AM, kerbiloid said:
We don't know the exact value of the light speed in sci-fi movie.
Say, in the Pratchett's Discworld, the light from the sun slowly expands along the planet.
Probably, this should make laser beams and light bolt spells be well visible.
If the blaster bolts in Star Wars were moving at light speed in a galaxy with a slower speed of light, fast punches would produce relativistic effects, and ground speeders would experience time dilation.
-
And finally, SECO-1 with nominal parking orbit insertion. Go Psyche!!
-
T-60 seconds, vehicle on internal power, all systems go.
All 27 engines firing -- leaving Terra Firma!
Center core throttling down (visible in fire trail).
Booster burnout. Booster separation successful.
Center booster burnout. Successful stage separation, MVac ignition, and fairing separation.
Side boosters started landing burns. Massive sonic booms.
Successfully landed the boosters! Quite a significant difference in timing between the return of the two boosters...more than I remember from earlier FH flights.
-
13 minutes ago, tater said:
SpaceX launches the Big Boy to a metal asteroid and I get my bar results, all on the same day.
Metal.
-
Have you ever seen someone fire a gun? Unless someone has a very good suppressor, you can still see exactly where "slug thrower" shots are coming from.
-
23 minutes ago, Exoscientist said:
The solution is obvious...using instead multiple Vulcains on the Ariane 6 core would result in launchers cheaper than the Falcon 9, able to be made reusable like the Falcon 9....
...but, unlike the Falcon 9, incapable of reaching orbit with meaningful payload.
-
Advertising the ability to grab a satellite and move it to a different orbit is pretty neat, although it's hard to come up with circumstances where that would be necessary.
Orbit refueling is of course badass.
And landing on the moon is sweet. I really want some dry mass and specific impulse data.
-
On 10/8/2023 at 9:20 AM, Exoscientist said:
Thanks for that. I don’t know why the ESC-A has such a poor mass ratio when the earlier H10 cryogenic upper stage on the Ariane 4 was much better at ca. 10 to 1. Perhaps because the Ariane 5 had to carry much greater payload at 20 tons that the ESC-A needed greater structural strengthening.
The ESC-A (and ESC-B) stage included a full maneuvering package/system on the stage itself for precision maneuvering and orbital insertion, while this was all located on the VEB ring for the Ariane 4's H10 stage.
-
On 10/6/2023 at 1:58 AM, monophonic said:
A very interesting approach. It feels like your approach would share a lot of traits with radix sort. But the ability to tweak the curve to fit the expected data set might provide an advantage in some uses.
Well, looking at radix sort led me to the actual bucket sort which is essentially what I proposed, at least in the linear curvesort case.
While unsourced, the Wikipedia notes in passing:
If the input distribution is known or can be estimated, buckets can often be chosen which contain constant density (rather than merely having constant size). This allows O(n) average time complexity even without uniformly distributed input.
That seems very close to what I was proposing, where the initial low-k bucket sort is used to estimate the distribution. It's also reminiscent of a note concerning radix sort:
Computerized radix sorts had previously been dismissed as impractical because of the perceived need for variable allocation of buckets of unknown size. Seward's innovation was to use a linear scan to determine the required bucket sizes and offsets beforehand, allowing for a single static allocation of auxiliary memory.
Seems quite similar on the whole. Both appear to share a relationship to counting sort.
-
3 hours ago, StrandedonEarth said:
Whoever names things is doing a great job. Stoke is getting people stoked, and the natural evolution of Nova will be:
SUPERNOVA!
I approve.
-
27 minutes ago, Kerbart said:
So... you look at the element value, see where it fals on the curve and then use the corresponding x-value to place it in a new array that uses floats as index values? Wouldn't you then have to sort that list as well to get things in the right order?
For linear curvesort, the new array doesn't need floats as index values; they would be ints and it would be the same length as your original list. And you don't need to sort it; the whole idea is that you are moving each element in your original list, one by one, directly into the index point on the new array that they SHOULD be when the list is sorted. Then you can just read the new array from start to finish to get the sorted list.
A good real-world example would be if you had the pages to a book (let's say pages 25-35) and they were all jumbled up, and you wanted to arrange them properly. You could leaf through and sort them page by page (bubble sort), but the easier way to do it would be to eyeball 10 page-sized spaces on your table, put them all in the proper space, then pick them all up in sequence. For example, if the first page was 31, you'd take 31-25 = 6 and put that page in the 6th space on the table. If the second page was 34, you'd take 34-25 = 9 and put that page in the ninth space, and so forth.
But of course it's rare that you need to sort a series of ordinal numbers. Let's suppose it's more complicated: you need to put a stack of invoices in order from lowest billing to highest billing. If you're clever, you might flip through the stack quickly and note that (a) there are 10 total invoices, (b) the lowest invoice amount is $201, and (c) the highest invoice amount is $5,022. The difference between $5,022 and $201 is $4,821, and since there are 10 total invoices, you know that on average there will be $482.10 between individual invoices. Assuming you're REALLY good at mental math, you decide to divide each value by $482.10 in your head in order to space them out on the table by that amount. The first invoice is for $3,016, and 3016/482.10 = 6.3, which rounds to 6, so you move it to array_table[6]. The next invoice is for $3,715, and 3715/482.10 = 7.7, which rounds to 8, so you move it to array_table[8], and so forth:
When you encountered $2,659, the math told you to go to array_table[6], but when you got there, there was already something there. So you group them together and move on. Same with $4,086 going to array_table[8].
Then you can simply scoop up the whole list, running across your table, skipping any empty spots, and sub-sorting any stacks you encounter. Nothing further needed.
(Note that when I say "table" here I mean a literal table. Probably should have said "desk" instead.)
27 minutes ago, Kerbart said:Also, how expensive is it to do the reverse lookup on the curve?
That's a good question. The computational cost to define a straight line is negligible, but the computational cost to define a curve is not. I'm not sure where the breaking point is, honestly.
I wonder if it would be just as efficient (or nearly so) to make the first pass without actually writing the values, merely keeping track of the running average of each sub-space with more than one value in it, and then define a series of straight lines linking those averaged points.
1 hour ago, Terwin said:It looks like you still have a best case of O(n) a worst case of O(n^2) and an average case of O(n*log(n)), just with different constants applied to those calculations.
I think that I may have a worst case of O(n^1.5). Still not as good as a worse-case of O(n*log(n)) but better than O(n^2).
-
7 hours ago, Exoscientist said:
It would be cheaper just to put additional Vulcain(s) on the core and dispense with the SRB’s entirely. An additional Vulcain would add €10 million to the price to bring it to €45 million.
Both the Ariane 5 and the Ariane 6 have a 5.4-meter core. Vulcain's gimbal range doesn't appear to be publicly available, but assuming it's in the range of 8°, a Vulcain 2.1 engine (at 3 meters high and 1.76 meters wide) will need gimbal clearance of 0.42 meters. So a pair of Vulcains have a 3.9-meter footprint that will fit underneath the core just fine; doing three in a line won't work (that would take up 6.12 meters). You can do three if you put them in a triangular cluster, though.
You'll need all three, because Vulcain 2.1 has a sea level thrust of 970 kN. Ariane 6 has a gross liftoff weight of around 190 tonnes sans boosters, which means two Vulcains gets you an unacceptable T/W ratio of 1.04. Factoring in the weight of two additional Vulcain 2s, the trio would get a liftoff T/W ratio of 1.53 which is good enough.
Not necessarily good enough to get to GTO with any meaningful payload, though.
-
Way back in my undergrad comp sci I class, we went through the usual steps of learning to code various sorting algorithms: bubble sort, quicksort, mergesort, and so forth. If you aren't familiar, all these sorting algorithms are comparison sorts, meaning that they sort a list of elements by successive greater-than/less-than comparison of individual elements. Conceptually, they function like a person with a balance scale and a set of unmarked weights, successively comparing individual weights against each other until all values have been sorted. Lots of energy in the computer science and mathematical logic worlds has been expended trying to design efficient sorting algorithms for data.
(Quicksort, left, and Bubble Sort, right)
It is mathematically proven that the best-case guaranteed runtime for any purely comparison-based sorting algorithm is n*log(n), where the number of comparisons required is equal to some constant (usually disregarded) multiplied by the number of list items, multiplied by the logarithm of the number of list items. Some algorithms can have better runtime on certain datasets but worse average performance, while other algorithms have better average performance but terrible performance (up to n2 or worse) on certain datasets. As long as you're sorting by successive comparisons, n*log(n) is the shortest set of comparisons you can be sure will properly sort the set. At the very best-case scenario, the number of comparisons you need is a simple factor of n, the number of items in the list.
During my comp sci class, I came up with a half-baked idea for a sorting algorithm that wouldn't rely on individual comparisons at all, but I was having trouble figuring out how to make it complete recursively and it just stayed in the back of my head for more than a decade. At the time I had the notion of calling it "bucket sort" on the theory that it would "toss" the list items into a series of buckets that were arranged by size (an n-complex operation) and then sort those buckets individually. I had the vague sense that this approach could work well for many real-world datasets, especially ones with a normal distribution or a weighted distribution.
This idea came back to me last night, and I couldn't sleep so I worked it out in my head and I think I figured out how to actually make it work, not necessarily with buckets, but by defining a two-dimensional curve and then placing the list elements along that curve. Both of these are n-complex operations, so it would have a best-case runtime of 2n (which in computer science is taken as simply equal to n) for data with linear, exponential, or normal distributions. You could also conceptualize it as a "histogram sort" because it essentially creates a new histogram of the dataset with each successive pass and uses that histogram to refine the curve being used to sort the data. There are still comparisons, of course, but you never do piecewise comparisons between individual list items.
Linear Case
As an example, I'll start by doing a purely linear-curve version of the algorithm. Consider the following set of ten random list items:
S = {14,39,11,41,30,37,19,18,6,27}
We can depict this set graphically:
Once sorted, we know that these list items (arranged graphically) will form some two-dimensional monotonic curve. Let's pretend for a moment that the curve they form when sorted is defined by your standard y = mx + b slope-intercept equation, where y is the value of each list item and x is its ordinal position in the sorted version of the list. If we knew the values of m and b, the constants in that equation, we wouldn't have to do ANY piecewise comparisons at all; we could just run through the list a single time, plug in the list value for y, and solve for x to figure out where to put it on the list. We can guess at m and b if we know the highest value, the lowest value, and the number of list items, so let's run through the list once (1*n) and get those values. We run through the list and find that the lowest value is 6, the highest value is 41, and the number of list items is 10, so we take b = 6 and m = (41 - 6) / 10 = 3.5. We define a new array and project a curve over that array using our equation y = 3.5x + 6:
We solve for x in our equation (giving us x = 2(y - 6)/7), and then we go back to the unsorted list and run through it a second time (now up to 2*n), using our equation to place the list elements along this curve. For example, the first element is 14, which gives x = 2.29 which rounds to 2, so we move it to the second slot on our new array:
We repeat for each successive list item:
If our list had a perfectly linear distribution, each list item would land perfectly on the line in perfect order, and we'd be done. But it's a random set, and so eventually we will run into a value that lands in a slot we already filled. Here, our sixth list element gives us x(37) = 8.86 ≈ 9, but we already put our second list item in that slot because x(39) = 9.43 ≈ 9, so we simply tack it onto the end of our second list item in a linked list (noting for future reference the length and position of our linked list):
Finally, we continue until we complete our run through the list, still keeping track of where we are creating linked lists due to overflow (here still we are only at 2*n operations):
If the values had been perfectly linear, then they would have dropped perfectly into order and the number of new linked lists would have been zero, and the computer would know that the list was sorted. But of course this was a random list and there were three places where the algorithm dropped multiple values into the same slot. (We can visually see that each of those happen to be out of order, but the computer doesn't know that; it only knows that there was overflow in those spots.) We now essentially have done the following:
The computer knows that the green items are sorted, and it knows that the sequences of red items are unsorted sub-lists that are nevertheless sorted relative to the green items that bound them. Here, the algorithm can simply be called recursively on each unsorted sub-list until the entire list is sorted. (In operation, you would call a simpler comparison algorithm for a two-item unsorted list, but of course you would also have plenty of sub-lists that were longer than just two-items.)
This algorithm (I'll call it "linear curvesort") has some conceptual commonalities with heapsort and smoothsort although it is not a comparison sort and it provides a stable sort (that is, if two items have the same value, they remain in the same order they started in). It is also adaptive, meaning that it will run much faster on a dataset that is almost entirely sorted than it will on a dataset that is more randomized. Determining best-case, worst-case, and average-case performance is beyond my ken.
Beyond Linear
Linear curvesort works great for lists with items that have a basically linear distribution, but what about a weighted or normal distribution? For example, the following set of randomized values, when sorted, is heavily weighted to the larger end:
Because the set is weighted toward larger values, running the linear version of this algorithm would end up having a bunch of successive recursions on the right-hand side of the data:
With this small of a list, that's not so bad, but for larger lists you would end up reshuffling the top end of the list (or any areas where the list values were weighted) many many times (approaching n2) to get it sorted. Conceptually, the linear curvesort predicts a line, then refines sections of that line which don't fit the data, then refines the remaining sections, over and over not unlike a monotonic moving average.
Can we improve on this?
I think so. When we do our initial linear sort, we set the size of the sorting array to some number that is much smaller than the original list. For example, in this version, there are thirty list items but I'm setting my sorting array to a length of just 5. Because of this, all of the list items end up in a linked sub-list, but that is by design. As before, we keep track of the sizes and locations of each linked list, which creates a histogram of the dataset (note that you don't actually have to write the list items into new locations here; you can just keep track of how many would fit into each slot as you go through):
In theory (depending on the size of my sorting array), this histogram will be able to tell me whether the dataset distribution is normal, inverted normal, weighted high, weighted low, or something else entirely, meaning that I can make predictions about the shape of the curve formed by the sorted set. This is clearly a normal distribution that is weighted high, so I can predict the curve and use the corresponding equation to shift my list items accordingly:
As shown, the new curve is generated by drawing through the average value within each sub-list (I did it in MS Paint but of course a computer would do it mathematically). I'm sure that some empirical testing could yield a good measure of how many sub-lists to use based on the size of the dataset to minimize the amount of time it takes to reach a trivially sortable state; using 5 sub-lists for a 30-item list got this particular dataset there in one iteration.
It feels like this could be a very fast sorting algorithm for many real-world datasets. Unfortunately I don't quite have the math skills to figure out how fast it would be. Anybody here have ideas? Is this similar to other sorting algorithms I just don't know about?
-
4 hours ago, zolotiyeruki said:
Holy cow, RIP GSE on liftoff...
RIP county on liftoff
-
4 hours ago, RCgothic said:
I've been messing about with a design I might have chosen in 2011 instead of SLS. It keeps the 5-segment SRBs and 8.4m form factor to keep congress happy, but the first stage uses 3x RD-171Ms (or maybe a 171M and 4 RD180s) and the 2nd stage uses 7x J2s.
It would be capable of throwing 285t payload to LEO.
With an optional 285t 3rd stage (2x J2-X) it could throw around 120t to TLI in a single launch (in this case the 3rd stage ignition would need to begin prior to achieving LEO), and would weigh 4180t on the pad and stand ~95m tall to the 3rd stage payload adaptor.
The 3rd stage can be placed fully fuelled into LEO to meet a payload already there. 200t to TLI or 120t to TMI. Credible Mars missions and lunar surface bases? Yup.
These are all within the transporter crawler and VAB margins, would have though there might be a challenge with the SRBs bridging two stages and RD engines would probably have run into foreign issues by now. Fun exercise
I like the sound of it. Of course anything with kerolox in the first stage is going to do better than SLS simply because it can hold more propellant. One of the biggest problems with SLS is the height limitation: hydrolox is so fluffy that the first stage takes up way more height than a corresponding mass of methalox or kerolox.
What are you figuring for dry mass of the first stage? The SLS core had to have some major strengthening to it compared to the light weight of the Shuttle external tank, and increasing the amount of props you're carrying in the first stage makes that even worse.
If we were back in 2011, one nifty option would have been to do another "Cluster's Last Stand" a la Saturn I, where tooling for existing tank designs was used with upper and lower thrust plates. Three Atlas V common core tanks will fit into the 8.4-meter footprint of the Shuttle external tank. Then maybe a shortened version of the Shuttle external tank could be used as the basis for an 8.4-meter second stage. I don't know if we had any J-2 engines in 2011 though.
A VERY fancy aspirational design would have been to put a pair of RS-25s underneath a Delta IV common core booster hydrogen tank and have it fire through an annular thrust plate. The thrust plate would hold a ring of small kerolox tanks (maybe from Falcon 1 which was available at the time) that wrap around the core tank, with appropriate kerolox engines underneath. Then a shortened version of the Shuttle external tank would sit on top of the common core booster and feed into it. At launch, the side boosters and kerolox engines and RS-25s all fire together. Once the kerolox tanks run dry, the entire ring is jettisoned and falls away, while the RS-25s continue thrusting to orbit.
Artemis Discussion Thread
in Science & Spaceflight
Posted
Any architecture based on SLS is also going to have the issue of limited volume for a co-manifested lander.
8.4x10 meters of volume is definitely a good bit -- probably enough for a flags-and-footprints lander -- but it's not enough to include a dedicated LOI braking stage for a single-launch architecture, and Orion certainly can't do the braking burn. So even if you were able to beef up SLS (SLS Block 2B?) enough to throw an arbitrary amount of payload to TLI, it's still unclear how to make that work.
Then again, maybe I'm wrong and there IS a way to fit a good lander and a braking stage into that volume.
It just makes much more sense to have all of the assets delivered to cislunar space ahead of sending crew.
And yet the fiddling I did yesterday is making me very curious about other possibilities.
I wonder what would happen if SLS used 4-segment boosters and put liquid kerosene tanks on top, and then put RD-180s there on the outer jettisonable engine skirt, fed from the kerosene tanks on the boosters and from the core LOX tank.