Project Multistage2015 - Development Thread

[rcraig42]

Are you talking about Atlas V?

IIRC, they actually throttle back for max Q, thus they hit later than you would expect from full thrust curve alone.

Plus, they may use a different gravity turn, etc.

Well, according to the user guide, the 401 maintains full throttle until 100 seconds, which is after both mach 1 and max Q, then it throttles back to 95% for the rest of the burn until the g limits throttle it back more. It's the one's with SRB's that throttle back through that period.

Interestingly, I was wrong about the Max Q. it's close to dead on time wise. though a bit lower in altitude and higher in pressure difference.

The other factor I failed to consider until just now though is payload, The one I'm using is on the light side, I need to play with that as well as possibly the timing of the gravity turn to see if I can't match up with their "generic" GTO launch profile.

 

[Face]

And the dll with the changes works, except that it broke the multistage2015 MFD for some reason (even when I accidentally compiled the original files), maybe I need to recompile it too, or just wait for the official release.

Since the MFD includes the common header file, and because you changed that common header file, of course you'd need to recompile it, too. I have done that and it works like a charm.

 

[rcraig42]

Since the MFD includes the common header file, and because you changed that common header file, of course you'd need to recompile it, too. I have done that and it works like a charm.

Okay, thanks. I'll have to set that up and recompile it too. At least it's fresh in my "getting too old to retain for long" mind how to do that set up .

@Boogabooga

Turns out that neither the payload, nor the pitch has any noticeable effect on acceleration that early in the flight, it still hit Mach 1 at 77 seconds even with the max payload for the higher DV remaining GTO, and going practically straight up the whole time. The User Guide doesn't specify the time for Mach 1, just Max Q, however, the information for the Cygnus Launch says it should be at 82.6 seconds.

I guess it's down to drag or atmosphere, I guess I can try to adjust the drag with the diameter and length in the ini.

---------- Post added at 07:10 PM ---------- Previous post was at 04:22 PM ----------

Oops, there are effectively no aerodynamic properties defined in the Multistage Vessel. According to the API Guide, you have to use createairfoil to have any lift OR drag. So not only is there no way to adjust drag, there is apparently no drag at all.

---------- Post added at 07:44 PM ---------- Previous post was at 07:10 PM ----------

Aahhh it uses the legacy cross section and cw method. but adjusting the cross section isn't having much effect. I'll try adjusting the setCW in the multistage code.

 

[fred18]

Hello there, a couple of day of absence and suddenly there's a lot of activity here :lol:

let me know how to get them to you and I'll send them, I've bracketed and used my user name in the comment brackets to make the changes and additions easy to find.

That's a good question. Fred18, do we have your permission to post large parts of your code here for the same addon (Multistage2015) for the sake of discussion or contribution? And what about binaries? Would it be OK to post a Multistage2015.dll here e.g. to give rcraig something to test his extensions with? Your release policy is a bit vague on that.

To me what Face suggests is totally fine.

Point is: I am still developing other parts of the code (the developer mode dialogs and some other stuff) therefore I think that the best approach is to discuss the code variations here, sharing also compiled binaries for testing purposes a when a modification is fine I can add it to the final code giving all the relevant credits.

Oops, there are effectively no aerodynamic properties defined in the Multistage Vessel. According to the API Guide, you have to use createairfoil to have any lift OR drag. So not only is there no way to adjust drag, there is apparently no drag at all.

That is wrong: it simply uses the legacy atmospheric model, which for a rocket with no lift and usually a round section is quite reasonable. If you turn on the forces vector option you'll see the Drag vector there.

---------- Post added at 20:53 ---------- Previous post was at 20:46 ----------

Aahhh it uses the legacy cross section and cw method. but adjusting the cross section isn't having much effect. I'll try adjusting the setCW in the multistage code.

Exactly, but be careful: MS2015 is intended to be reversely compatible with Multistage2 by Vinka, and those parameters for CW are the Vinka ones. Recently Vinka sent me the original Multistage2 source code since he is happy with MS2015, I'm going to recheck with his version the atmospheric parameters. Also be aware that adjusting all the parameters to have the Atlas working exactly as the real one could mess up all the other rockets, MS2015 is still a general module that has to fit the needings of every possible launcher.
Last but not least Orbiter is a great simulator but having exactly the same behaviour of reality is something nearly impossible to achieve, Mach speed for example depends on air pressure, then there is the temperature and so on with many variables that could not be exactly identical in simulation and in reality and therefore with a slight difference in behaviour, but I think we have to live with that.

 

[Face]

Point is: I am still developing other parts of the code (the developer mode dialogs and some other stuff) therefore I think that the best approach is to discuss the code variations here, sharing also compiled binaries for testing purposes a when a modification is fine I can add it to the final code giving all the relevant credits.

Are you going to address the rather dangerous uninitialized heap-structures issue? I noticed that your code doesn't run in (standard) debug mode, because things like character arrays are not initialized to zero values, but expected to be so when e.g. using string::copy.

In release mode, this is mostly no problem, because having the structure allocated on the heap via a call to the constructor, values are automatically made zero. Unfortunately this is compiler dependent, and changed quite a bit through versions.

Do you not have problems in debug mode?

 

[fred18]

Yes, in the version I'm working on for the developer mode this is mostly solved: all the structures are now initialized, so almost everything is fixed.

 

[rcraig42]

Exactly, but be careful: MS2015 is intended to be reversely compatible with Multistage2 by Vinka, and those parameters for CW are the Vinka ones. Recently Vinka sent me the original Multistage2 source code since he is happy with MS2015, I'm going to recheck with his version the atmospheric parameters. Also be aware that adjusting all the parameters to have the Atlas working exactly as the real one could mess up all the other rockets, MS2015 is still a general module that has to fit the needings of every possible launcher.
Last but not least Orbiter is a great simulator but having exactly the same behaviour of reality is something nearly impossible to achieve, Mach speed for example depends on air pressure, then there is the temperature and so on with many variables that could not be exactly identical in simulation and in reality and therefore with a slight difference in behaviour, but I think we have to live with that.

I get that, maybe another optional parameter for drag factor in the [Misc] section, which defaults to 1, that gets multiplied by the default value for z_pos in the setCW command? I'll write it in and comment it the same way I did the isp_sl if you'd like. I had reservations about adjusting the diameter anyway since it affects the pmi as well.

btw that last set of files I attached works just as intended, and it should not effect the guidance much if at all.... by the time the PEG takes over the existing DV remaining calculation should be reasonably accurate. But the calculated default initial pitch might be way off for the orbit() command.

On the other, other hand, anyone that would use the isp_sl parameter will most likely also customize the initial pitch as well. I know I do

 

[fred18]

I get that, maybe another optional parameter for drag factor in the [Misc] section, which defaults to 1, that gets multiplied by the default value for z_pos in the setCW command? I'll write it in and comment it the same way I did the isp_sl if you'd like. I had reservations about adjusting the diameter anyway since it affects the pmi as well.

btw that last set of files I attached works just as intended, and it should not effect the guidance much if at all.... by the time the PEG takes over the existing DV remaining calculation should be reasonably accurate. But the calculated default initial pitch might be way off for the orbit() command.

On the other, other hand, anyone that would use the isp_sl parameter will most likely also customize the initial pitch as well. I know I do

I totally agree. I didn't completely understand the moltiplication of SetCW by z_pos.

 

[rcraig42]

I totally agree. I didn't completely understand the moltiplication of SetCW by z_pos.

The first parameter of the setCW function is called z_pos in the API Reference. you have a number in there (I think it is .2, I'll check the original file to be sure), I propose using a variable that defaults to that number. Unless the drag_factor is specified in the ini file, in which case that number gets multiplied by the value of drag_factor.

 

[fred18]

Ah yes, now I remember! The first is the coefficient in z positive direction, second in z negative. So I agree with setting this but defaulting this to 0.2 to have the default behaviour. Good point! :thumbup:

 

[rcraig42]

Not having as good luck with this one, my best guess is the setCW is happening before the Misc section of the ini gets parsed, but I don't know how to determine that from looking at the code. or how to force the parse before the setCW; the syntax for calling functions is one of the things that mystifies me in C++

---------- Post added at 02:11 AM ---------- Previous post was at 12:32 AM ----------

okay I got around it by leaving the original setCW where it was, but adding another setCW with the modification to set the values in a section I could tell was executed after parsing but before launch.

and it works fine, no drag_factor in the ini, it behaves as it did before, drag_factor in the ini multiplies the default coefficient (only with the vessel moving in the positive z direction) by the value entered.

FYI: for the Atlas V 401 I needed a factor of 15.

I want the added realism because I was tired of exceeding the published capabilities of the launch vehicles by sooooo much. I was able to deliver a 3400 kg satellite from Canaveral to a GTO with only 15 degrees inclination and an agp of 180 degrees with the configuration ini provided by boogabooga in his OA4 Cygnus Launch add on.

I should not have been able to do better than 20 degrees inclination. I'm still working on optimizing the first stage launch profile with the reduced performance before I can check on what I can do with the DV remaining in the Centaur.

 

[rcraig42]

Here's the source files with both the ISP SL and the Drag factor implemented

I believe these are the source files before the patch he posted here, so the Particle Streams don't work as well.

 

[fred18]

okay I got around it by leaving the original setCW where it was, but adding another setCW with the modification to set the values in a section I could tell was executed after parsing but before launch.

The reason is that the original SetCW is in the setClassCaps call which happens before the scenario loadScenario call. Of course in Multistage vessel the ini file is read after the scenario is loaded (otherwise orbiter will not have any chance to know which ini file it has to read) so I created a new function which is called after that which is VehicleSetup. I will put just one SetCW call in the VehicleSetup routine so there won't be any duplicate.

 

[rcraig42]

The reason is that the original SetCW is in the setClassCaps call which happens before the scenario loadScenario call. Of course in Multistage vessel the ini file is read after the scenario is loaded (otherwise orbiter will not have any chance to know which ini file it has to read) so I created a new function which is called after that which is VehicleSetup. I will put just one SetCW call in the VehicleSetup routine so there won't be any duplicate.

That works .

And this does make it more challenging to match the published capabilities for sure. The best I've been able to do consistently is a 3 second longer Centaur burn to get to the published parking orbit. I think I can fix that with a slightly lower drag factor, it's "ballparked" anyway so it isn't really cheating.

---------- Post added 01-26-16 at 08:03 AM ---------- Previous post was 01-25-16 at 05:14 PM ----------

Fred, Is the guidance routine capable of targeting an intermediate descending abside? where the periapsis is somewhere ahead of the ship at cutoff (for my purposes, 30 or 40 degrees).

And if it is capable, could you possibly implement it by, for instance, the user entering a negaitive number in the abside parameter of the orbit() command?

 

[fred18]

Fred, Is the guidance routine capable of targeting an intermediate descending abside? where the periapsis is somewhere ahead of the ship at cutoff (for my purposes, 30 or 40 degrees).

And if it is capable, could you possibly implement it by, for instance, the user entering a negaitive number in the abside parameter of the orbit() command?

mmm it is capable of targeting an intermediate point between absides (even though it becomes less precise) but usually is ascending (it was thought to simulate the cutoff of the space shuttle). I don't think it can target a descending point. It can target a negative periapsis, you just put a negative number and it will drive you there, but the intermediate point is usually ascending.

 

[rcraig42]

mmm it is capable of targeting an intermediate point between absides (even though it becomes less precise) but usually is ascending (it was thought to simulate the cutoff of the space shuttle). I don't think it can target a descending point. It can target a negative periapsis, you just put a negative number and it will drive you there, but the intermediate point is usually ascending.

okay, I'll have to do it by hand. I just managed it myself with pretty much the same fuel budget, but a bit high in both pe and ap.

This is part of the challenge of GeoStationary insertions. So many aspects of the procedures used, and too much needed information, are just not accommodated or provided in Orbiter. The descending cutoff is just one of those things.

 

[rcraig42]

fred,

I finally got to the point of adding the boosters and trying to build the Atlas V 551, and discovered that with my build, for some reason, I get a CTD on startup if I try to add more than 2 booster groups. And I need a new group for each booster because of the irregular arrangement of SRB's on the Atlas V.

I put the patched release dll back in my modules folder and it built the 551 with all 5 booster groups with no CTD.

Not sure if it's my changes somehow causing the problem, or something in the unpatched code base I'm building on. But it's something to check out if/when you add my changes


On another note, the isp_sl should also be added to the boosters, for HLV's like the Atlas V Heavy and the Delta IV Heavy.

 

[fred18]

There was some indexes out of range with the old version, but I think that the published code already fixed that, can't remember now. Write me you email address in a PM and I'll send you the WIP code so you can use it to progress with your atlas!

 

[rcraig42]

okay, now that I'm further along with the Atlas V 521 at least. I've discovered another problem.

The 5XX series has a g limit of 2 G's for 20 seconds for Fairing Jettison, then it goes up to 4.6 G's for the rest of the 1st stage burn.

Unfortunately the existing Glimit command in the guidance file stays active for 250 seconds no matter what. There should be a way to add an optional time to it, or be able to override it with a higher Glimit (I tried that, with a throttle up engine command, but it didn't work, went right back to 2 G's)

Strangely I COULD over ride a higher G-Limit with a lower G-Limit, I did that with the 401, where it goes from 5 G's to 4.6 shortly before the end of the burn. It worked fine.

 

[fred18]

okay, now that I'm further along with the Atlas V 521 at least. I've discovered another problem.

The 5XX series has a g limit of 2 G's for 20 seconds for Fairing Jettison, then it goes up to 4.6 G's for the rest of the 1st stage burn.

Unfortunately the existing Glimit command in the guidance file stays active for 250 seconds no matter what. There should be a way to add an optional time to it, or be able to override it with a higher Glimit (I tried that, with a throttle up engine command, but it didn't work, went right back to 2 G's)

Well the command was thought for the most common use: keeping the G forces at a set value at the end of first stage when G forces can reach the maximum. After first stage is jettisoned the acceleration gets much lower so even if the check i performed, it is not seen by the user.

I never inserted a time parameter in order not to complicate things too much. Please consider that a large number of parameters I created were not even present in the original multistage, I think you are really pushing the limit of all the options available, of course I like it :thumbup:

Before changing this I have one question: how does it work in reality? do they have a check on acceleration and throttle down to keep the desired value or do they have a pre programmed throttle-down and throttle up program? If the latter then the command "engine" alone would be more correct.

A way to avoid the issue is to have an "engine" call first and a g-limit call later. That should work.

Strangely I COULD over ride a higher G-Limit with a lower G-Limit, I did that with the 401, where it goes from 5 G's to 4.6 shortly before the end of the burn. It worked fine.

It's not strange: the second check is more restrictive, the G-limit command only throttles down (this is also stated in the documentation IIRC), so the guidance computer makes two checks, and satisfying the second condition automatically satisfies also the first and therefore it works.
To be more clear: the G-limit does not set the throttle at the proper level in order to have the desired acceleration, it simply checks the acceleration value and keeps throttling down a bit until the acceleration is below the set value.