Changing Cd in OpenRocket

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
All I am saying is that the user only has to provide Cd vs. Mach. No time dependence or sequencing needed like you mention in post #24.

The user can provide 2 curves (power on/off) or 1 curve, depending on his data

IF curves=2 AND Thrust > 0, THEN use power on Cd curve
IF curves=2 AND Thrust = 0, THEN use power off Cd curve
IF curves=1, THEN use it all the time
 
All I am saying is that the user only has to provide Cd vs. Mach. No time dependence or sequencing needed like you mention in post #24.

The user can provide 2 curves (power on/off) or 1 curve, depending on his data

IF curves=2 AND Thrust > 0, THEN use power on Cd curve
IF curves=2 AND Thrust = 0, THEN use power off Cd curve
IF curves=1, THEN use it all the time

Ok, how do you want to indicate which curve is power on and which is off?
Should it just be a case of if the Mach speed goes low again the this is the start of the second curve (power off)?
Add a 3rd column?
Some sort of header entry at the start of each curve?
 
As requested you can now upload a single curve and it will use it for both Thrusting and Coasting phases. This is the normal behaviour

I'll work on expanding this so you can enter key words in the file to indicate if a curve is for the Thrust or Coast phase before the dataset.
The file would look something like:
Curve Thrust
Mach CD
0.01 0.542
0.012 0.477
...
...
...
Curve Coast
Mach CD
0.01 0.511
0.012 0.451
...
...
...


If required there is the option that allows you to upload data from a simulation file. This expects the Mach number to increase to max velocity and then decrease as per the simulator's data extract.

Also fixed some issues I had with the GUI.

Let me know what you think.
 
Last edited:
I am looking at releasing another version.

The updates I have made are:
1. Allow a thrust and coast curve for a normal file
2. Added functionality to extrapolate the CD past the min and max Mach numbers. Although I still recommend that you do this yourself.
3. Added a Help screen

Before I released it just wanted to find out if anyone wanted any additional features or had feedback, otherwise I'll effectively end development for now.

One thing I wanted to point out. The file is used to update the Total CD, however to keep things consistent the Friction, Pressure and Base CDs are varied so that they add up to the total CD. One of the side effect of doing this is the Base CD splits and is all over the place at slow speeds. Not sure if that bothers anyone but thought Id put it out there. One possibility may be to assume that the difference is completely in the friction, obviously don't want to get complicated as I don't believe it has any impact other than looking a bit weird.
CD Base Split.jpg
 
Thanks for creating this. I've tried out the % override and it's the only way I can get my Ram Jet sim to at least ballpark altitudes. Aside from using a file to override CD, just being able to tweak the overall % will help dial things in when compared to actual flights.

Thanks again!
 
Please find attached latest version.

View attachment 318887

Hi SpaceManMat, I'm brand new to this forum and have just came across your CD Override plugin! I run a University rocketry team and we were looking for a way of using CFD to enhance our OR sims when I stumbled across your plugin and at first glance it seems to allow us to do everything we need: calculate our rocket's Cd at a range of Mach numbers and then use that data to override OR's CD calculations. I'd love to learn some more about how the plugin works if you still remember haha!
 
Hi SpaceManMat, I'm brand new to this forum and have just came across your CD Override plugin! I run a University rocketry team and we were looking for a way of using CFD to enhance our OR sims when I stumbled across your plugin and at first glance it seems to allow us to do everything we need: calculate our rocket's Cd at a range of Mach numbers and then use that data to override OR's CD calculations. I'd love to learn some more about how the plugin works if you still remember haha!
Hi Theo, glad that the plugin can be useful to you. OR utilises listeners for its plugins. At various points as the program steps through the simulation the plugin can be called and will have access to various fields within the simulation which it can read and update. In the case of the CD plugin it primarily uses postAerodynamicCalculation to get access to the CD values. Depending on what options you select it will either read and then recalculate the CD values or it will substitute values based on the file data. These updated values are then used by the simulator as it continues on with the calculations for the step.
 
Yes, RA and OR will create two curves, power on and power off.

I would just use one curve anyway. The power on curve probably has some wild ass guesses based on motor nozzle diameter and exhaust pressure.

For RASAero II, the power-on CD curve is not a "wild ass guess". :)

The simplest power-on Delta CD model is to take the calculated power-off base drag/base pressure, and just subtract out the area of the nozzle exit area, and assume that the base pressure only applies to the base area minus the nozzle exit area. RASAero II adds more sophistication to this, especially at supersonic and hypersonic Mach numbers, but if you are accurately predicting the power-off base drag/base pressure (which RASAero II is) then simply subtracting out the nozzle exit area from the base area is a good simple model, and can be used to do a general check of the RASAero II base drag model. Proving that it is not a "wild ass guess".

There are more sophisticated models that require the nozzle exit pressure and exit geometry, but they are not used in RASAero II, because that would be very detailed data for most users. All that is needed is the nozzle exit area, entered by entering the nozzle exit diameter. Most users are not going to know their nozzle exit pressure.

(Nozzle exit pressure will of course vary with time based on chamber pressure. Once a nozzle model is created it's really not a big issue to vary exit pressure with time based on chamber pressure, but one has to create the nozzle model first, which requires detailed geometry information on the nozzle.)


Charles E. (Chuck) Rogers
Rogers Aeroscience
 
For RASAero II, the power-on CD curve is not a "wild ass guess". :)

The simplest power-on Delta CD model is to take the calculated power-off base drag/base pressure, and just subtract out the area of the nozzle exit area, and assume that the base pressure only applies to the base area minus the nozzle exit area. RASAero II adds more sophistication to this, especially at supersonic and hypersonic Mach numbers, but if you are accurately predicting the power-off base drag/base pressure (which RASAero II is) then simply subtracting out the nozzle exit area from the base area is a good simple model, and can be used to do a general check of the RASAero II base drag model. Proving that it is not a "wild ass guess".

There are more sophisticated models that require the nozzle exit pressure and exit geometry, but they are not used in RASAero II, because that would be very detailed data for most users. All that is needed is the nozzle exit area, entered by entering the nozzle exit diameter. Most users are not going to know their nozzle exit pressure.

(Nozzle exit pressure will of course vary with time based on chamber pressure. Once a nozzle model is created it's really not a big issue to vary exit pressure with time based on chamber pressure, but one has to create the nozzle model first, which requires detailed geometry information on the nozzle.)


Charles E. (Chuck) Rogers
Rogers Aeroscience

Thanks for the details Chuck, I appreciate that a lot of work goes into building programs such as RASAero. I have in the past brought up the idea of enhancing the motor files to include nozzle exit size. So I’m curious as to if you think other details could be useful? Of course the practicality of providing those details is also a consideration, but perhaps defining an enhanced file speciation will at least provide the option for that to be considered in the future.
 
Thanks for the details Chuck, I appreciate that a lot of work goes into building programs such as RASAero. I have in the past brought up the idea of enhancing the motor files to include nozzle exit size. So I’m curious as to if you think other details could be useful?

RASAero II also uses the nozzle exit area to vary thrust with altitude, something not included in the other programs. The two most useful pieces of information would be the nozzle exit diameter (used to calculate the nozzle exit area) and the atmospheric pressure at which the motor was fired. Even if the atmospheric pressure wasn't measured when the motor was fired, just knowing the elevation of the motor test site, or whether the test site was close to sea level would be useful information. Actually just having an input for sea level or vacuum for the thrust curve would be useful. For space launch applications many thrust curves are vacuum thrust curves.

We considered doing all of the above, but the inherently simple approach of just using the rasp motor database as-is won out. In RASAero II it is assumed that the thrust curve data from the rasp.eng file is a sea level thrust curve. The nozzle exit diameter (used to calculate nozzle exit area) is already entered for the power-on base drag, so it can also be used to vary thrust with altitude. When RASAero II is used to model a space launch vehicle, and the thrust curves for the stages are vacuum thrust curves, the thrust curves have to be converted to sea level thrust curves.

Nozzle exit angle and nozzle exit pressure would also be useful, but just having the atmospheric pressure at which the motor was fired would be most useful.

Of course now this would be a non-standard motor database, like the Rocksim .rse files, or (for old-timers) the Rogers Aeroscience ALT4 .edx files. The disadvantages of creating a non-standard motor database is why we decided not to pursue this at this time.


Charles E. (Chuck) Rogers
Rogers Aeroscience
 
With the new Open Rocket version 22.02 having been released, some modifications were required for the CD Override plugin to work. Please find attached version 3 of the pluging that is compatable with the new version. As usual I am keen to hear any feedback.
 

Attachments

  • CDoverride3.zip
    32.7 KB · Views: 5
SpaceManMatt --

Thanks for the PlugIn.

I've got actual CD -vs- MachNumber data for my Scratch LOC Vulcanite which I calculated from AltAcc Acceleration.

I'll take your PlugIn for a spin and compare results to actual flight Data and let you know what I see.

Below are sim summaries for available motors at the time from an old off-vertical simulator I wrote in the 1990s which compare very well to actual flight data.

Thanks again for sharing !

-- kjh

vul-dr.gif



Code:
         Spock's Johnson with AltAcc at Ocotillo on a Summer Day

                     DMass          42.61    oz
                     DDiam           2.23    in
                     EDiam           2.55    in
                     CD              0.56 
                     Rail            5.00    ft

                     SiteAlt       460.00    ft
                     SiteTemp       95.00    F
                     SiteBaro       29.43    inHg
                     SiteMach     1154.7     ft/sec
                     SiteRho         1.1271  Kg/m^3

Motor     Total I  Max (Min) Gs  V-Rod   VMax    Alt  TBurn   TAlt  Delay
========= =======  ============  =====  =====  =====  =====  =====  =====
AT-F50T      78.0   5.2 ( 1.1)    40.0    150    470   1.62    5.9    4.3
AT-G40W     114.1   3.9 ( 1.2)    34.3    188    844   3.03    8.3    5.3
AT-G80T     116.1   9.6 ( 1.4)    53.8    242    980   1.42    8.1    6.7
AT-G64WR    120.0   6.1 ( 1.3)    38.5    230    938   1.88    8.3    6.5
AT-G125     120.8   9.6 ( 1.5)    51.5    269   1066   1.00    8.3    7.3
AT-G75JR    147.7   4.7 ( 1.4)    36.8    271   1245   2.18    9.5    7.3
AT-H238TR   163.3  18.5 ( 1.8)    71.6    357   1631   0.80    9.9    9.1
AT-H128WR   178.7  12.8 ( 1.9)    58.1    382   1850   1.15   10.6    9.5
AT-H97JR    184.7   5.9 ( 1.7)    39.6    334   1761   2.35   11.0    8.6
AT-H73JR    186.4   3.6 ( 1.5)    32.5    284   1633   3.68   11.3    7.6
AT-H220TR   210.0  21.1 ( 2.2)    76.0    450   2303   0.95   11.5   10.6
AT-H123WR   211.2   6.1 ( 1.8)    42.1    373   2131   2.60   12.0    9.4
AT-H180WR   212.2  11.7 ( 2.1)    54.0    433   2266   1.41   11.7   10.3
AT-H242TR   234.6  11.3 ( 2.2)    55.6    463   2554   1.61   12.4   10.8
AT-H112JR   280.0   6.4 ( 2.1)    42.1    455   3004   3.40   14.1   10.7
AT-I161JR   333.6  12.0 ( 3.0)    59.4    609   3843   2.11   14.8   12.7
AT-I357TR   341.3  25.5 ( 3.7)    74.6    685   3963   1.11   14.5   13.4
AT-I154JR   385.5  11.2 ( 2.9)    54.9    601   4369   3.46   16.1   12.6
AT-I300TR   440.0  26.6 ( 4.5)    87.3    818   5116   1.60   16.1   14.5
AT-I195JR   480.0  15.8 ( 4.1)    68.1    781   5396   2.46   16.9   14.4
AT-I211WR   483.1  15.4 ( 4.8)    66.0    840   5599   2.28   17.0   14.7
KO-I400F    514.1  34.2 ( 5.2)    88.4    918   5702   1.15   16.8   15.6
AT-I284WR   554.4  20.6 ( 5.7)    76.8    951   6228   1.91   17.5   15.6
AT-I435TR   600.1  48.2 ( 6.9)   120.8   1070   6701   1.38   17.6   16.2
KO-I410DH   605.0  16.9 ( 5.0)    62.2    939   6520   2.42   18.3   15.9
KO-I500F    670.0  29.2 ( 7.6)    87.8   1113   7166   1.45   18.4   17.0
KO-I310S    673.0  18.2 ( 6.0)    71.4   1042   7314   2.40   19.0   16.6
AT-J350WR   700.0  37.2 ( 6.8)   104.7   1124   7439   2.00   18.5   16.5
KO-J1000F   900.0  47.5 (13.7)   109.0   1340   8244   1.10   19.4   18.3
KO-J900S    992.9  29.2 (12.1)    88.2   1275   8830   1.85   20.4   18.6
AT-J570WR  1060.0  54.6 (12.3)   121.4   1386   9197   2.50   20.0   17.5
 
Art --

Yes, I tried that option but when I 'flew' a J510 in my Vulcanite OR set CD = 0.56 for all Mach Numbers and it grossly overestimated the performance on Transonic Flights.

When I investigated, I found that the CD was a constant 0.56 at all Velocities.

IOW, there are no Transonic CD effects when one selects a CD Override for all Subcomponents.

I saw the issue when I plotted CD -vs- Mach Number via the Flight Simulations Dialog:

Screenshot_20230610_130011.png

Instead of the classic CD -vs- Mach Number profile, like this:

sj-cd-vs-mach.png

There were two horizontal lines representing the constant CD = 0.56 at all velocities when the CD Override was set.

What might be nice to have is a constant multiplier that could be applied to the existing CD shape curves at all velocities ?

-- kjh
 
Yes interesting and the high speed changes vs flat.

But was I was looking for was the classic use I do with sub-Transonic rockets. Weight all my finished subassemblies and override weight., Fly the Rocket one or twice with flight computer in it that includes accelerometer. On a day without bad winds of course.

Then using the CD override, adjust it till the sims match what the computer plotted. Then it gets closer to being accurate for me. Back in the day I called that Back-Simming
 
Art --

Yes, your sim process sounds very familiar :)

I was going to try inserting old AltAcc Accelerometer Data into SpaceManMat's PlugIn for that particular rocket and see what's what.

The graph I posted above is from a number of flights, and several were transonic.

I do have to say that OR matched the calculated AltAcc Subsonic CD pretty dang well !

The AltAcc said 0.56 and OR without any fooling around with CD says 0.58, so this is simply an academic exercise anyway :)

And now that I have a Blue Raven to play with I am looking forward to messing with that data too !

Thanks

-- kjh
 
Just a few tangential remarks. Not advocating anything. Just mentioning three things that happen to come to mind, and happen to be more or lsee related to the discussion.

1) The effect of thrust on base drag will depend on the size of the nozzle exit, and also on the difference between exit pressure and ambient pressure. So that depends on the motor, the altitude, and... the weather. (Actually, thrust and drag get mushed together, here. It's pressure thrust when there is under-expansion and base drag when there is over-expansion.)

2) When thrust-to-weight ratio is very high, the effect of extra base drag won't make a lot of difference. Base drag is limited by speed, which is limited by the Rocket Equation. Even model rockets get near that speed at high TWR's. The whole of drag is a small fraction of (-presumed high) thrust. Base drag is less than that. You could see a difference if you went for max altitude and stayed near terminal velocity during boost.

3) From experience, I'm skeptical of the accuracy of computed Cd curves. (Oddly, I'm a little less skeptical of supersonic Cd values...)

Luckily, this is a rocket forum, so I have a standard-issue flameproof suit - which I am now donning.
 
I did get some feed back privately and I thought I should share what I have observed. This relates to using a new CD curve.

The Step setting in the simulation options seems to cause inaccuracies, try make this at least 10 times smaller. Similarly, the CD data curve needs to be as fine as possible. Typically our rockets accelerate very quickly this results in jumps in the values used by the simulation. If you plot the output of the simulation it can sort of make the CD skip various points of inflection in the curve which may look unusual.

It should be noted that there was a considerable shuffling of code in the new version, so if you do get results you don’t expect then please do let me know. It would help if you could supply your files plus some details as to what you are seeing / expecting.
 
SpaceManMat --

I am finalizing my presentation for a conference that my company is hosting this week.

I leave for Tucson, AZ next Sat and I'll be gone for a week so it will be a couple weeks before I can return to my 'little' project of porting a suite of very old AltAcc Programs for the Blue Raven data files.

Not to mention relearning a bunch of things that I've forgotten :)

Yes, I did notice that OR produces slightly different sims when the integration calculation frequency is increased.

But thats the way numerical integration works ( and sometimes does not work ) but I am with you on the frequency of the Calcs.

One issue I may have to solve is that AltAcc Data points from above were gathered as 8-bit unsigned char at 16 HZ -- it is very primitive compared to what we have today.

OTOH, I've got one Blue Raven Flight which records accelerometer and gyro data as 16-bit signed int at 500 Hz ( ! )

I'll definitely come back to this project after the conference so don't worry if I appear to disappear for a couple weeks :)

Just for fun, this is what I called the Raw Acceleration -vs- Velocity 'bun' for a J570 flight from Turkey Shoot1999 in Bolder City NV.

j570-b.gif

And it is is where the Rho-Normalized CD curves from post #44 came from for the different flights ( this is the ts991127 / j570 curve ).

It is a cycle from liftoff, over the top thru the thrust phase and back to v=0 for the coast phase along the lower curve.

Note the Transonic effects on acceleration out at high v .

The raw data for the flight, including site and rocket parameters and notes are attached below as a .txt file.

Maybe other people with Accelerometer Data would like to play too :)

-- kjh

p.s. Larry Curcio recently pointed out that I need to adjust Pressure Altitude for Temperature which I never bothered to do for the AltAcc Files becauseI am an Accelerometer Bigot :)

The Raw Pressure Altitude in the attached file is a little lower than the Inertial Altitude in the attached AltAcc Data File.

Adjusting the Pressure Altitude at Apogee ( 8868 ft ) for Site Temperature ( 62 F ) gives a Density Altitude of 9442 ft which is scary-close to the Inertial Altitude at v=0 of 9553 ft.

Thanks Larry !
 

Attachments

  • j570-flt.txt
    226.4 KB · Views: 0
Last edited:
:)

Yes, I did notice that OR produces slightly different sims when the integration calculation frequency is increased.

But thats the way numerical integration works ( and sometimes does not work ) but I am with you on the frequency of the Calcs.

-- kjh

Well, sort of. I have not examined the source code for OR or Rocsim, so I do not know if numerical integration is is being done properly, except to say that it works well enough most of the time. I do think RK4 is suitable for these simulations, but you have to use a good step size to get stable reliable results. Fortunately, this is easy to do since RK4 is very robust. Just keep decreasing the step size, or increasing the integration frequency, until you get sufficient stability and accuracy. From the posts above it seems that the OR default integration step size should be decreased. Personally, I have always preferred RK4/5 with automatic step size control, but that may be too sophisticated for most sport rocketeers.

I wrote my first 6DOF simulation program for a general configuration rocket in 1978. Of course it lacked the sophisticated screen plotting, graphics, and GUI. I remember that when I modeled one fin misaligned by 0.5 degrees it was easier to just hard code it and recompile, rather than constantly adding more program inputs. While there are many things that I would like so see added to OR, I think we may have already passed the point of diminishing returns, making the learning curve too steep for most users. I also remember receiving an early version of Rocsim, on a floppy disk for evaluation. I could not get it to do the evaluation tests that I wanted, and I have not used it since. However, I did give some ease of use suggestions. One was to easily produce results with +/- 10 or 20 percent Cd to cover the estimation accuracy. The other was some presets so the rocketeer could say that they simmed their rocket at Poker Flats, White Sands, etc.. just for fun. Sadly, they did not want suggestions, they just wanted experts to talk up the product on the forums.

I do think simulation programs should have the ability to use actual measured mass, CG, thrust, and CD data when such data are available to supplant any built in estimation. However, using or expecting the program to be able to integrate flight measurement data and produce Cd curves leads to insanity, of a fun sort.
p.s. Larry Curcio recently pointed out that I need to adjust Pressure Altitude for Temperature which I never bothered to do for the AltAcc Files becauseI am an Accelerometer Bigot :)

The Raw Pressure Altitude in the attached file is a little lower than the Inertial Altitude in the attached AltAcc Data File.

Adjusting the Pressure Altitude at Apogee ( 8868 ft ) for Site Temperature ( 62 F ) gives a Density Altitude of 9442 ft which is scary-close to the Inertial Altitude at v=0 of 9553 ft.

Thanks Larry !
Thanks, I have seen a post from LC in many years, nor head mention of him. Aside from being the person who ruined television, he is a technically sharp model rocketeer.

Alan
 
Last edited:
Yes, I did notice that OR produces slightly different sims when the integration calculation frequency is increased.
Different by how much? I don't have OR, but I get nearly identical results in Rocksim with order of magnitude changes in dt. The difference between dt =1.0 E-02 s and dt = 1.0E-04 s is fractions of a percent in max altitude and max velocity.


Well, sort of. I have not examined the source code for OR or Rocsim, so I do not know if numerical integration is is being done properly
I know Rocksim does, because I supplied the RK4 subroutine!

Despite being explicit, RK4 is very stable and accurate on the rocket equations, even with seemingly large time steps. Good results are had in Rocksim with as little as 100 samples per second. I also saw this in my own code. At about 5000 samples, you are at the limits of machine precision.

I do think simulation programs should have the ability to use actual measured mass, CG, thrust, and CD data when such data are available to supplant any built in estimation.

Every program allows you to enter the measured mass and CG.

.eng and .rse files are easy to make yourself with any thrust vs. time data.

CD is the hard one. Where is the hobbyist supposed to get measured CD data? Supersonic wind tunnels and good CFD are not readily available. Personally, I would export the Cd curve out of RasAero and put it in RockSim/OR if possible.
 
Different by how much? I don't have OR, but I get nearly identical results in Rocksim with order of magnitude changes in dt. The difference between dt =1.0 E-02 s and dt = 1.0E-04 s is fractions of a percent in max altitude and max velocity.
Buckeye --

I apologize if I lead anyone down a rabbithole but I can't reproduce what I thought I saw when I changed the calculation frequency in Open Rocket.

I was messing with a number of Rocket Parameters as well as the Calc Frequency and I did see different Apogee Altitudes but when I went back and only changed Calc Frequency, the difference is only a couple feet.

I know Rocksim does, because I supplied the RK4 subroutine!

Despite being explicit, RK4 is very stable and accurate on the rocket equations, even with seemingly large time steps. Good results are had in Rocksim with as little as 100 samples per second. I also saw this in my own code. At about 5000 samples, you are at the limits of machine precision.

Yes, I see that now !

Every program allows you to enter the measured mass and CG.

.eng and .rse files are easy to make yourself with any thrust vs. time data.

CD is the hard one. Where is the hobbyist supposed to get measured CD data? Supersonic wind tunnels and good CFD are not readily available. Personally, I would export the Cd curve out of RasAero and put it in RockSim/OR if possible.

Yes, CD is a tough one but I am hoping to back-calculate the CD -vs- Mach Number Curves from Live Accelerometer Data for my test rockets and reintroduce that into OR via SpaceManMat's PlugIn

Sorry about my mistake and thanks for the gentle application of the Clue Stick !

-- kjh
 
Last edited:
Back
Top