Hi Columbia42 (and everybody),
Please allow me a few extra comments and then I will try to shut up if we both find out that my feedback is not useful for your addon objectives, ok? I would please ask for a little of patience though: this resulted in a kind of long post but believe it might be essential to explain / understand some things.
I. Cymrych’s "Analysis of Documented 09 Ares V"
Cymrych’s "Analysis of Documented 09 Ares V” is an interesting reading, at least from the good perspective of presentation of the logic method and the goal of trying to search for parameters that lead to a better AresV LV.51.00.48 implementation in Orbiter.
For what is worth, I partially agree with something that is written there: the way NASA presents information is not very clear sometimes but, on the other hand, from a first reading, I get the impression that Cymrych’s document is also based on personal interpretations of scattered data (please someone or Cymrych’s himself feel free to correct if that is not the case)…
… With that in mind, I do not quite agree with the tone of the document (although that is only an informal document): there are several points raised on that document where answers for some of those valid questions are publicly available online and, beyond that, there are also other places with more complete starting assumptions and data sets (would need to check)…
Please note that I’m not saying that even with extra data I do not have any doubts interpreting such information (far from that!): only saying that there is more stuff out there regarding not only AresV LV51.00.48 conceptual configuration data but also regarding several other key Constellation elements and mission design assumptions and ground rules… Some of such information is prepared and displayed in a less technical way for easier generic reading, other documents are prepared with more detail (it depends of context!)…
… All available Constellation information is (was) a work in progress and is (supposedly was) interlinked just like addon components need to be interlinked to work as a coherent whole. An addon developer probably needs to search for, study and keep in the back of his/her mind most of that information if wanting to implement coherent ‘by the book’ missions based on official data (even if such implementation is just first order and / or has implementation constraints, again, depending also of the context and objectives surrounding the addon implementation vs things so down to Earth as free time to develop the addon or level of ‘playability’ / ‘creative liberty’ vs intended final orbinaut profile). This to say that some of that information, if used, would most probably make Cymrych to consider a fresh look at the AresV analysis.
On a side note, it would be nice if we could all be in the same geographic area and gather all weekends to discuss Orbiter addon development and astronautics related topics. Unfortunately that is not quite possible and I do not wish to refute or provide alternative opinions, point by point, about Cymrych’s document as well do not wish to do so also because, in the end, this has to do with addon implementation strategies and goals: there are several key differences regarding how I – knowing what know today / my current ‘skills’ - would eventually implement something like AresV LV51.00.48 vs some of this addon’s thread choices and strategies.
My intended role here is then more aimed to provide useful help / feedback (if there is the wish for it!) to, in my opinion, improve the current state of AresV implementation (what each addon author makes with the same starting data in terms of addon implementation, documentation and packaging is what makes each addon special and, obviously, I do not really wish to interfere on that creation process beyond providing the generic feedback!).
Nevertheless, will still share here a little part of what I was using on my more than one year old development files regarding AresV LV51.00.48. In particular, will leave here the motor and engine specs from official single source (non-scattered) conceptual data regarding one LV51.00.48 iteration (nevermind about the four decimal places):
5.5 seg. SRB:
16654141.7275 N, 275.7s ISP (vac.)
(operational burn time: ~116.4s)
RS-68B (108%):
3122896.2261 N, 364.9s ISP (sl)
3545232.6274 N, 414.2s ISP (vac.)
(core operational burn time: 303s)
J-2X:
1307777.1549 N, 448s ISP (vac)
(dual thrust mode: 81%, 449s for TLI)
What to do with this data?
Well, it now depends how the data is implemented: on my development files powered by Vinka’s multistage2.dll I usually use the vacuum maximum thrust / ISP levels and the totality of the propellant load to calculate the burn duration requested by the generic dll (do not confuse this with operational burn time: the burn time that multistage2.dll asks might or not be equal to the operational burn time, depending of how things are implemented!).
To simulate sea level to vacuum transitions with multistage2.dll I roughly assume a +/- linear transition from 0km to at least ~30km altitude or so by using thrust commands in the guidance file (this for liquid stages, edit: or else for something like AresI first stage). Also try to keep at least 1% for FPR (Flight Performance Reserves) / Residuals on liquid stages (such as the AresV core) by shaping trajectory and commanding engines cut-off MET. Other addon authors might prefer to make such FPR/Residuals mass to be part of ‘dry’ masses and recalculate all based on mission propellant, etc. For the last active stage / service module sometimes might even simulate the FPR / Residuals at 0.5% (assuming the context of an operational design, depending how badly the extra performance need is) up to ~2.3% (if wanting to really protect for performance reserves while being farther away from Earth)
For the boosters case, it depends of the nature of the booster… In these large solid side boosters cases I use multistage2.dll thrust curve function to model the thrust variation together with a jettison command on the guidance file. Only as side note, the generic shapes of the thrust curve for 4 segment SRB and 5 segment SRB variants can be found online (I even shared a rough demonstration / preliminary graphic from simcosmos development archives in one past post in these forums, it should not be hard to find the related thread/post/context by using my forum profile or the search function).
The 5.5 segment SRB specific case seems to be a bit different though… the conceptual design assumptions for these more 'recent' AresV iterations were a bit more ‘aggressive’ and, just by looking at available solid prop. plus expected separation moment, etc, the thrust curve seems to not have as much variations as in the STS or as the variations displayed in the thrust curves of several 5 seg. SRB design iterations!!! This is what it takes to lift such huge core and all above it (LV51.00.48 monster core length seems to be practically equal or greater than SaturnV first and second stages total length).
Having shared all this, in one of my AresV LV51.00.48 INI development files, the Thrust to Weight values at lift-of is ~1.36 (with guidance commanding the 6 RS-68B to ~88% and the booster thrust curve starting at ~92% at lift-off). I have provided the numbers and implementation method above mostly to share an alternative perspective to what is written on Cymrych’s "Analysis of Documented 09 Ares V".
II. Regarding the trajectory or the overall mission simulation: will reiterate that the simple fact of being able to replicate a conceptual or historical trajectory in Orbiter simulator or of being able to fully simulate global mission objectives (such as, in this case, do TLI and landing on the Moon and return, etc) is not, by itself, a guarantee that the data is well implemented (or as well implemented as could perhaps be). On another hand, it is also true that there are several methods (with each method also having more or less limitations that can sometimes be worked around) that could end up by giving similar results… But we would then enter again on a discussion about implementation objectives / methods.
III. Implementation objectives / methods
Columbia42, I'm aware that this might be a boring reading but sincerely hope you more clearly understand the nature of my posts and why tried to ask about what your addon objectives were. If the objective is to have a launcher 3D model that resembles an AresV conceptual iteration and if the objective is to be able to deliver Constellation spacecraft to LEO, make all docks and undockings of a lunar mission (for the crewed missions) and then return home then that is a good and valid objective as any!
However, if the objective is to also go slightly beyond that and do all those steps in a more realistic way (even despite some constraints of the cool Vinka generic dlls) - and by realistic I mean with the stages having expected ‘dry’ masses (in multistage.dll / spacecraft ‘language’ these would not really be the dry masses sometimes) - and if the objective is to (try to) have mission components containing propellant amounts, engine parameters, etc very similar to the expected numbers from specific official design iterations and related conceptual data for a given mission elapsed time then my preliminary opinion is that some numbers – as were implemented on beta20100403 - might not be in accordance with the specific designs that seem to be the goal of the simulation (again, part of any addon development is also the result of research work and learning about related topics). In addition, and globally writing, nowadays there is a lot more detailed information about Constellation Requirements (CARD), Hardware Development, Conceptual Brainstorms and Mission Modes than existed a few years ago.
IV. Further Feedback Notes:
Because this is already a long post, I will not do an exhaustive list of things that could eventually be corrected or improved but will try to provide some generic feedback regarding areas that might need better study IF the goal is to then implement more realistic designs and do Constellation Missions by the book (unless there is the desire to departure from official data or not bother with some of those details vs a given impact on realism for a first addon version vs 'playability' --> I made the same on some of my first public works, which hope to one day delete / update as needed).
Moving on, there is lot of Altair lander information available online (think that some info / link was already shared in this thread? so will not repost that): please have a look at the Altair.INI of beta20100403. Very low dry mass for descent stage (only 2510 kg for a total propellant load of 34535 kg!… ~465s ISP for the engines… that would be something like an RL-10-B2!, etc): these parameters are incorrect.
Please look also at the Altair_Ascent.ini (Just 666 kg empty mass!, FUEL_MASS=7289…. , ~465s ISP for the ascent stage engine… which was baselined as *hypergolic* = would need to have a much lower ISP, etc…).
About Altair_LunarCargVariant INI: for example, only focusing in the masses inside that INI (EMPTY_MASS=19378.75, FUEL_MASS=61276.25) it is obvious that this is not Constellation Cargo Altair as it is also obvious that no baselined conceptual NASA AresV version (even the bigger LV51.00.4X variation) could send that amount of total mass to TLI in a single launch...
… Please remember that some of the (many) reasons for conceptual vehicles such as those bigger AresV LV51.00.48/47 iterations (LV51.00.47 had even more aggressive design assumptions than LV51.00.48!!!) was the desire to protect for, at very least, 4 days LEO loiter (only 4 days!, this depends also of stage design), ~3175m/s TLI of ~75t payload in ‘1.5’ AresI+V mission mode (0.86 t adapter + 45t Altair + 20.2 Orion at TLI moment + 5t Level1 Margin + 4t Level2 Margin or so)… Would have to check but even AresV LV51.00.48 only seems to protect for ~71.1t TLI payload (payload = adapter + lander + CEV + some margin, depending of boil-off reduction results, spacecraft mass growth, etc)
Continuing, not saying that what will write next is or not happening in current beta files but I would also recommend some care and extra attention with book-keeping the masses on multistage.dll or spacecraft.dll INI payload definitions vs the masses defined in each payload ini file vs dV budgets or else it is very easy to create what I call of ‘portable virtual black holes’ where, for example, a small sounding rocket could make TLI of a First Lunar Outpost crewed payload (not sure if was able to explain myself?).
Talking about the EDS, the numbers for the ‘dry’ masses on beta20100403 do not seem to correspond to official data. To be fair, this is one point that might raise more interpretation doubts about the official data mainly because of keeping track of some EDS related components and some Earth Departure configuration changes that happen during ascent up to pre-TLI moment (such as, for example, loiter time vs boil-off simulation protection vs margins vs jettison of boil-off reduction kit, etc).
V. Final comments
I was seriously considering to share here some more of my own development notes about the topic (AresV LV51.00.48, Altair, Considerations about AresV ascent and mission constraints, required performance targets for the several mission modes, etc)… In fact already wrote some rough first order / first impressions stuff (which might be outdated) about the topic in an older thread at these forums (which can be found by using the search function), beyond some glimpses in my interventions on this thread.
But... all that would probably end up by resulting in an extensive document or other probably boring posts and not sure if this would be the correct thread for that (despite this thread being about the development of an AresV addon).
After thinking about it a bit more, decided, at least for the moment, to provide the current feedback (which really hope might be useful!) and decided to then put on-hold something more elaborated because would have to do intensive copy + paste from those personal development notes / files (‘loosing’ time when most information is available online anyway, if searching for it) and because this addon interpretation, goals and implementation method constraints appear to be different – in several ways – than what have used on those files (and do not really wish to have an amount of work if the objectives or implementation philosophies are kind of different, which is also fine, more addon variety).
In any case, if wishing a little more of such further feedback or research directions about specific topics feel free to say so and, if having time and not being in ‘away mode’ will try to help within the possibilities.
To conclude - and continuing to wish good luck to this development effort - I guess that might end here my participation in this thread, at least for the moment.
Best wishes,
António
(and thanks for the patience reading all this blablablabla)
PS: quickly answering to submariner: yes, still in the plans to update my AresI, (provide integrations with external addons, include extra ‘stuff’ such as an AresV heavy lifter – probably not LV51.00.48 variant - and also delete / replace / update other really outdated addons; in fact did some updated research on AresI stuff this past weekend…which is not a easy thing to do because from some time now that there is not a single source detailed data document about AresI with Thrust Oscillation Mitigations and updated Orion assumptions already included on mass breakouts, performance / trajectory)… although from some time now that things are not what used to be regarding continuous availability for active addon development (I gave up about announcing release dates).
