CoP simulation comparison, including CFD

[Alan15578]

Also, CFD assumes all turbulent flow. The drag force totals and ratio of pressure drag to friction drag are all over the place between the 3 methods. Very frustrating. That warrants a deep dive, too.

Nuts! I wanted to ask you how well the CFD determines the transition point from laminar to turbulent boundary layers.

 

[Buckeye]

These are really interesting results -- what I'd find even more interesting would be CFD results for individual components, like a fin or a nose cone, calculating things like CNa. That would let us feed the results back into OR and improve our calculations.

Interesting yes, but not for me. I want to investigate the aerodynamics of the rocket in a modern, holistic manner. A nosecone by itself in the CFD airstream will have a wake affecting the forces. I am not sure how that jives with the OR Barrowman component theory.

Jeff's Goony test case will give some insight to your suggestion. The classic "Nose+Body."

If anybody wants to take on the component CFD studies, I can give some advice on CFD, FreeCAD, and the OpenFOAM workbench.

 

[OzHybrid]

Do you have some evidence showing that Rocksim "flattens" the fins to increase CP location? Changing the fin thickness does nothing in RockSim. Try it.

RockSim does something different with fin planform, but nothing with thickness, as far as I can tell:

https://www.apogeerockets.com/downloads/Technical_Publications/Tech_Pub_17.pdf

The Base Drag Hack was all about the airframe base, not fins. This thread busts that bogus theory:

https://www.rocketryforum.com/threads/lets-put-an-end-to-the-base-drag-hack.184792/

You may have misunderstood what i was trying to say. I didn't mention fin thickness. In terms of projected fin area, Rocksim uses more of the fin area as if it were squashed like a flower pressing and flattened out. This effective increase in fin area used moves the Cp back and that amount seems to match more closely what you're getting with the cfd analysis. We've been through all this before. I've no problem with the cfd analysis, and the results have been at least partially validated experimentally.
But currently Rocksim does not need the base drag hack applied as it already has another hack applied which increases the effective amount of fin area. OR does need it applied.
If the Rocksim results DO match closely enough the CP location the full CFD analysis is giving, then the SIMPLE solution is to apply that SAME hack to OR rather than making OR into a full CFD analysis program, or have to use another CFD analysis integration built into another program.
There's also RasAero. Which already works and has already been validated experimentally.
KISS.

 

[Buckeye]

You may have misunderstood what i was trying to say. I didn't mention fin thickness. In terms of projected fin area, Rocksim uses more of the fin area as if it were squashed like a flower pressing and flattened out. This effective increase in fin area used moves the Cp back and that amount seems to match more closely what you're getting with the cfd analysis. We've been through all this before. I've no problem with the cfd analysis, and the results have been at least partially validated experimentally.
But currently Rocksim does not need the base drag hack applied as it already has another hack applied which increases the effective amount of fin area.

I still don't understand what you are saying about pressed flowers and RockSim increasing fin area.

From the technical publication I linked above, the Rocksim method seems to discretize irregular fin shapes into triangles and converts them to an equivalent trapezoid fin suitable for Barrowman equations. No mention of increasing the effective fin area. In fact, preserving the area is emphasized:

"The Barrowman method as published in TIR-33, states that an equivalent trapezoidal fin plan can be substituted for a non standard fin plan. The area of this equivalent fin plan should not exceed the area of the original fin plan."

"This insures (sic) that the fin area is accurately represented."

Other Apogee publications have mentioned that the RockSim method does some other stuff with fin/body interaction, fins on boattails, etc., all which lead to different CP results from original Barrowman.

There's also RasAero. Which already works and has already been validated experimentally.
KISS.

Yep, and the Rogers Modified Barrowman CP method in RASAero falls in between RockSim and OpenRocket 99% of the time. Maybe 100%

Rogers's validation data is heavily geared to supersonic flows. It is hard to find incompressible center of pressure tests, hence these CFD investigations.

 

[drewnickel]

Interesting yes, but not for me. I want to investigate the aerodynamics of the rocket in a modern, holistic manner. A nosecone by itself in the CFD airstream will have a wake affecting the forces. I am not sure how that jives with the OR Barrowman component theory.

A way to potentially deal with this would be integrating surface pressures and normal vectors along the surface mesh. You could have the entire rocket in the study and just obtain forces and moments for the individual components looking at their respective wetted surfaces.

 

[OzHybrid]

I still don't understand what you are saying about pressed flowers and RockSim increasing fin area.

From the technical publication I linked above, the Rocksim method seems to discretize irregular fin shapes into triangles and converts them to an equivalent trapezoid fin suitable for Barrowman equations. No mention of increasing the effective fin area. In fact, preserving the area is emphasized:

"The Barrowman method as published in TIR-33, states that an equivalent trapezoidal fin plan can be substituted for a non standard fin plan. The area of this equivalent fin plan should not exceed the area of the original fin plan."

"This insures (sic) that the fin area is accurately represented."

Other Apogee publications have mentioned that the RockSim method does some other stuff with fin/body interaction, fins on boattails, etc., all which lead to different CP results from original Barrowman.



Yep, and the Rogers Modified Barrowman CP method in RASAero falls in between RockSim and OpenRocket 99% of the time. Maybe 100%

Rogers's validation data is heavily geared to supersonic flows. It is hard to find incompressible center of pressure tests, hence these CFD investigations.

I'm saddened you don't understand what happens to flowers when you press them flat. Sometimes they increase their projected area by 10%......
Page 4 on the tech notes document you supplied. Fin weighting factor. 1.1 ........... Am I missing something? Or has a hack been applied by 10 % in RS to the fin area to make the Cp agree closer to reality? Further back... That tech note is old. So who knows today.

I don't have a problem with the CFD route. But, using your answers agreeing with Rocksim which is using a HACK to get its answers as a method of validating your results is a poor validation method. The CFD method needs independent results validation. AND therefore stop using your CFD analysis as a method of invalidating the OR result and the BASE Drag hack. The base drag hack simply moves the Cp to a more realistic spot in a fat rocket using OR.
Until you get the data and flight comparisons, you have a theory. If implementing that is harder than applying a fudge factor of 1.1 or whatever to the projected fin area , then it has no tangible benefit, so let's use the easiest method to implement.

 

[Buckeye]

A way to potentially deal with this would be integrating surface pressures and normal vectors along the surface mesh. You could have the entire rocket in the study and just obtain forces and moments for the individual components looking at their respective wetted surfaces.

Ah, of course. Good point. It is easy to do a component-by-component breakdown on the forces from the complete rocket CFD result. Pressure + shear forces.

 

[kjhambrick]

I'm saddened you don't understand what happens to flowers when you press them flat. Sometimes they increase their projected area by 10%......
Page 4 on the tech notes document you supplied. Fin weighting factor. 1.1 ........... Am I missing something? Or has a hack been applied by 10 % in RS to the fin area to make the Cp agree closer to reality? Further back... That tech note is old. So who knows today.

I don't have a problem with the CFD route. But, using your answers agreeing with Rocksim which is using a HACK to get its answers as a method of validating your results is a poor validation method. The CFD method needs independent results validation. AND therefore stop using your CFD analysis as a method of invalidating the OR result and the BASE Drag hack. The base drag hack simply moves the Cp to a more realistic spot in a fat rocket using OR.
Until you get the data and flight comparisons, you have a theory. If implementing that is harder than applying a fudge factor of 1.1 or whatever to the projected fin area , then it has no tangible benefit, so let's use the easiest method to implement.

Barrowman assumed one fin is on the plane of the angle of attack.

Then he factored in the dihedral angle for three-finned rockets so he actually projected the 'shadow' of the fins wrt wind direction.

IOW, he did exactly the opposite of flattening the flower petals.

Maybe RockSim modified Barrowman does not factor in dihedral angle of the fins ?

But that would only matter for fin counts where the shadow of the fins attached to the rocket is smaller than the sum of the areas of two fins.

IOW, rockets with an odd fin count would be so affected, but rockets with an even number of fins would not be affected.

-- kjh

EDIT: I just went and looked and the model in @Buckeye's latest study has four fins so the dihedral factor would not apply, but neither would the flattened flower petals ?

 

[Buckeye]

I'm saddened you don't understand what happens to flowers when you press them flat. Sometimes they increase their projected area by 10%......
Page 4 on the tech notes document you supplied. Fin weighting factor. 1.1 ........... Am I missing something? Or has a hack been applied by 10 % in RS to the fin area to make the Cp agree closer to reality? Further back... That tech note is old. So who knows today.

OK, I now see that 1.1 weighting factor on the fins related to CD of a flat plate. A factor of 0.41 is also applied to nose cones and transitions due to CD of a cylinder. That all sounds weird and irrelevant to me. So, yeah, who knows.

I don't have a problem with the CFD route. But, using your answers agreeing with Rocksim which is using a HACK to get its answers as a method of validating your results is a poor validation method.

I don't know how you ended up concluding that I am using Rocksim as the most correct result. Quite the opposite. I consider CFD to be the best simulation and I am using it to validate all the Barrowman methods!

AND therefore stop using your CFD analysis as a method of invalidating the OR result and the BASE Drag hack. The base drag hack simply moves the Cp to a more realistic spot in a fat rocket using OR.

Wrong. I am saddened that you don't see the poor reasoning and lack of data in the Base Drag Hack. I am not going to rehash all the evidence (CFD and other), here. You can read that for yourself in the other thread.

 

[OzHybrid]

OK, I now see that 1.1 weighting factor on the fins related to CD of a flat plate. A factor of 0.41 is also applied to nose cones and transitions due to CD of a cylinder. That all sounds weird and irrelevant to me. So, yeah, who knows.



I don't know how you ended up concluding that I am using Rocksim as the most correct result. Quite the opposite. I consider CFD to be the best simulation and I am using it to validate all the Barrowman methods!



Wrong. I am saddened that you don't see the poor reasoning and lack of data in the Base Drag Hack. I am not going to rehash all the evidence (CFD and other), here. You can read that for yourself in the other thread.

The Base drag hack should probably be renamed as "The Cp hack to equivalence the Cp to a similar position on a short rocket as Rocksim" or not. As it's a hack, call it what you want. It's a fudge factor. Like the weighting factors in RS.

 

[Buckeye]

I added RASAero II with Rogers Modified Barrowman method to the CP image at zero angle of attack:

These are really interesting results -- what I'd find even more interesting would be CFD results for individual components, like a fin or a nose cone, calculating things like CNa. That would let us feed the results back into OR and improve our calculations.

OK, I gave this a whirl for the tailcone case at 4 deg AoA. I had to create 4 Reporting Functions in the CfdOF workbench, one for each component, and rerun the CFD simulation. Then, compile the numbers manually. A bit tedious, but it can be scripted.

I added RAII total values to the table as well. In previous versions of RockSim, you could view stability plots and CNa without setting up a simulation. That functionality seems to be gone, now.



The only component CNa that is somewhat close between CFD and OR is the nose cone. Big differences for the fins and tailcone. All the differences are directionally correct to put the CFD CP well aft of OR's estimate as shown previously.

I might think about building this one and flying it.

 

[boatgeek]

I added RASAero II with Rogers Modified Barrowman method to the CP image at zero angle of attack:

View attachment 667238



OK, I gave this a whirl for the tailcone case at 4 deg AoA. I had to create 4 Reporting Functions in the CfdOF workbench, one for each component, and rerun the CFD simulation. Then, compile the numbers manually. A bit tedious, but it can be scripted.

I added RAII total values to the table as well. In previous versions of RockSim, you could view stability plots and CNa without setting up a simulation. That functionality seems to be gone, now.

View attachment 667241

The only component CNa that is somewhat close between CFD and OR is the nose cone. Big differences for the fins and tailcone. All the differences are directionally correct to put the CFD CP well aft of OR's estimate as shown previously.

I might think about building this one and flying it.

I'd always felt that the OR tailcone had far too much impact on the CP. It's nice to see confirmation on that.

 

[rocketguy101]

I wonder how a V-2 would turn out? I ran comparison sims between RS and the newer version of OR when it was able to model fins on a transition.

 

[drewnickel]

I added RASAero II with Rogers Modified Barrowman method to the CP image at zero angle of attack:

View attachment 667238



OK, I gave this a whirl for the tailcone case at 4 deg AoA. I had to create 4 Reporting Functions in the CfdOF workbench, one for each component, and rerun the CFD simulation. Then, compile the numbers manually. A bit tedious, but it can be scripted.

I added RAII total values to the table as well. In previous versions of RockSim, you could view stability plots and CNa without setting up a simulation. That functionality seems to be gone, now.

View attachment 667241

The only component CNa that is somewhat close between CFD and OR is the nose cone. Big differences for the fins and tailcone. All the differences are directionally correct to put the CFD CP well aft of OR's estimate as shown previously.

I might think about building this one and flying it.

Just curious, but in any of these cases have you run convergence studies tweaking computational domain dimensions and mesh refinement? Wondering how the data is affected by that.

 

[Buckeye]

Just curious, but in any of these cases have you run convergence studies tweaking computational domain dimensions and mesh refinement? Wondering how the data is affected by that.

Nothing systematic, but I do spot checks here and there.

Domain size is sufficiently large so there is minimum blockage effect. About 0.4% impact on drag force in this case:

https://www.rocketryforum.com/threads/cfd-with-freecad.184708/post-2558682

About 2% impact on CP location with "coarse" and "fine" mesh on this one:

https://www.rocketryforum.com/threads/cop-simulation-comparison-including-cfd.184722/post-2633201

As for a validation with wind tunnel or free flight, Barrowman used a simplified Aerobee 350 and noted that the CP was measured at 394 in (10.008 m). CFD agreement is 1%.

https://www.nar.org/wp-content/uploads/2016/01/barrowman_cp_extended_edition.pdf

https://www.rocketryforum.com/threads/cop-simulation-comparison-including-cfd.184722/post-2632357

I'll probably do another comparison with one of the models in the RASAero documentation.

I think I have a pretty good methodology nailed down for hobby accuracy vs. efficiency on a home computer.

 

[Buckeye]

That is enough simulation for a while. Now I am going to attempt some flight tests.

I built the tailcone model with parts from BMS. For the tailcone, I used the BNC60C conical nose cone and chopped off the tip to 50mm length. I carefully bored out a hole with a 3/4 " forstner bit for an 18mm motor mount. The taper of this cone is a little different than the OR design, resulting in an aft diameter of 23 mm vs. 18.7 mm in the original. This was a good opportunity for a design change delta, so I updated all the simulations:

Change in CP location by changing tailcone aft diameter from 18.7mm to 23mm:

• OpenRocket +10 mm​
• RockSim +5 mm​
• CFD +2 mm​

OR is the most sensitive to the tailcone size.



I scrounged up 4 big washers for about 60 g of ballast. The tailcone is removeable, so the washers can be used as tail weight or nose weight to move the CG around. In all cases, all four washers are used, so the total rocket mass remains constant, while making the CG variable.



I want a nice straight boost with adequate rail speed. Microbuttons are used on a Makerbeam 10mm rail with 48" of effective guide length. Thrustcurve sims show 56 ft/s rail exit speed on a Qjet C18, and 49 ft/s on an Estes C5.

 

[Buckeye]

Flight tests of the tailcone model

I configured the ballast to come up with three different CG test locations with motor loaded. The physical model was weighed and balanced on a string. The configurations are shown here with the 3 simulations of CP in the pre-flight design mode.







Winds were a little stronger and more gusty than I hoped for. I measured 4-10 MPH throughout the day on my anemometer. The records at the nearby airport showed the same.

I tried the C18 on Test1.0. The first motor would not light. The second motor quickly burned and sent the rocket into the ground, broke a fin, and bent the BT a little bit. Nice. Repairs were made.

Changed to the C5 for the tests. Test 1.1 was a nice, smooth, boost and a stable flight.


View attachment test1.1.mp4

Test 2.0 was the interesting one. The boost/coast was initially stable for a while, then went end over end.


View attachment test2.0.mp4


Test 3.0 quickly cartwheeled into the flight


View attachment test3.0.mp4

Analysis to follow in next post

 

[Buckeye]

I revisited the sims to compute CG and CP during flight, especially at rail exit when stability margin is most critical. I assumed an average wind speed of 7 mph, which gave an angle of attack of 11 degrees with a speed of 16 m/s (M 0.047), which is quite a bit different than the pre-flight assumptions.

From the graphs in OR and RS, I picked off the CP and CG locations at rail exit. The CG shifted forward a few mm with propellant burn. The physical model synced up nicely with the simulated dry and wet masses, so I applied this same CG shift to the CFD model.

I re-ran the CFD model at 11 degrees and M 0.047 for the updated CP location. The airflow is separated off the fins at this condition.



Here are the in-flight stability results at rail exit:





Conclusions:

I won't be using QJet motors again! I tried B, C, and D motors in LPR over the past few years, and I am not impressed with the performance nor shelf life.

OpenRocket is way too conservative and predicted Test 1.1 to be unstable, which it wasn't. If you demanded a 1 caliber margin, you would be adding a ton of useless nose weight in this model.

Something is not right with OR's transition/tailcone model, which was the original hypothesis. OR stability increased as angle of attack increased. You can see this in the Component Analysis tab as well. No other sim - RockSim, CFD, RASAero II - shows this behavior.

CFD has the most rearward CP location initially, but it moves forward a lot with AoA, much more than the Barrowman sims. CFD Test 2 initially predicted a positive stability margin pre-flight, but the rail exit condition was more neutral to negative stability, which kinda agrees with the flight observation. I am still confident that CFD gives the best answer, but larger stability margins are needed to confirm.

Test 3 was predicted to be unstable by large margins by all sims, which agrees with the flight.

 

[Alan15578]

I revisited the sims to compute CG and CP during flight, especially at rail exit when stability margin is most critical. I assumed an average wind speed of 7 mph, which gave an angle of attack of 11 degrees with a speed of 16 m/s (M 0.047), which is quite a bit different than the pre-flight assumptions.

From the graphs in OR and RS, I picked off the CP and CG locations at rail exit. The CG shifted forward a few mm with propellant burn. The physical model synced up nicely with the simulated dry and wet masses, so I applied this same CG shift to the CFD model.

I re-ran the CFD model at 11 degrees and M 0.047 for the updated CP location. The airflow is separated off the fins at this condition.

View attachment 673391View attachment 673392

Here are the in-flight stability results at rail exit:

View attachment 673394

View attachment 673401

Conclusions:

I won't be using QJet motors again! I tried B, C, and D motors in LPR over the past few years, and I am not impressed with the performance nor shelf life.

OpenRocket is way too conservative and predicted Test 1.1 to be unstable, which it wasn't. If you demanded a 1 caliber margin, you would be adding a ton of useless nose weight in this model.

Something is not right with OR's transition/tailcone model, which was the original hypothesis. OR stability increased as angle of attack increased. You can see this in the Component Analysis tab as well. No other sim - RockSim, CFD, RASAero II - shows this behavior.

CFD has the most rearward CP location initially, but it moves forward a lot with AoA, much more than the Barrowman sims. CFD Test 2 initially predicted a positive stability margin pre-flight, but the rail exit condition was more neutral to negative stability, which kinda agrees with the flight observation. I am still confident that CFD gives the best answer, but larger stability margins are needed to confirm.

Test 3 was predicted to be unstable by large margins by all sims, which agrees with the flight.

It appears that you are launching in the cruciform configuration to the cross wind. You should rotate (roll) 45 degrees to launch in the X configuration to the cross wind.

 

[Buckeye]

It appears that you are launching in the cruciform configuration to the cross wind. You should rotate (roll) 45 degrees to launch in the X configuration to the cross wind.

I have seen this before. Easy enough to do in CFD as well. 45 degrees into the wind should move the CP forward a little bit more. Is that what you are referring to?

 

[Alan15578]

I have seen this before. Easy enough to do in CFD as well. 45 degrees into the wind should move the CP forward a little bit more. Is that what you are referring to?

View attachment 673530

No. Let's just call it a pro tip. I was referring to your fin stall at 11 degrees. They may not have stalled if the X orientation had been used.

 

[kjhambrick]

@Buckeye --

Sorry if you've already posted a Rocksim.rkt or OpenRocket.ork file somewhere here in this thread ...

I looked and did not find them ...

I might have 'found' something wrt OR -vs- classic Barrowman ( ? maybe aka RS-Barrowman ? ) ...

Can you share your fatboy.rkt or fatboy.ork file please ?

It would also be nice to get-aholt of your NominalBoy and SkinnyBoy too

Thanks !

-- kjh

 

[Buckeye]

@Buckeye --

Sorry if you've already posted a Rocksim.rkt or OpenRocket.ork file somewhere here in this thread ...

I looked and did not find them ...

I might have 'found' something wrt OR -vs- classic Barrowman ( ? maybe aka RS-Barrowman ? ) ...

Can you share your fatboy.rkt or fatboy.ork file please ?

It would also be nice to get-aholt of your NominalBoy and SkinnyBoy too

Thanks !

-- kjh

Here is the FatBoy file. NominalBoy and SkinnyBoy were made by simply extending the body tube to achieve L/D of 10 and 15, respectively.

Also, ignore the CFD CP results for NominalBoy and SkinnyBoy in post #3. That was before I started using a proper moment balance.

 

[kjhambrick]

Here is the FatBoy file. NominalBoy and SkinnyBoy were made by simply extending the body tube to achieve L/D of 10 and 15, respectively.

Also, ignore the CFD CP results for NominalBoy and SkinnyBoy in post #3. That was before I started using a proper moment balance.

Thanks @Buckeye !

I'll run some numbers thru my old program PROFILER which implements the BEq's without any modifications and then compare to OR.

-- kjh

 

[kjhambrick]

Thanks @Buckeye !

These were your CP data for the FatBoy from your first post:


The OR CP -vs- the RS-B CP are a little different across the board and the OR CP seems to always fall after the RS-B CP on the airframe

I ran into something similar for a new rocket I am working on where I used OR to design the rocket but then I ran the rocket thru program PROFILER.

PROFILER is an old linux/bash/gawk script that implements the Barrowman Equations as described in Barrowman's Thesis.

PROFILER also generates data so that a 'profile' of the rocket can be drawn via gnuplot.

This is your FatBoy.ork:


This is the image from PROFILER and gnuplot where I copied the dimensions of your FatBoy into a fatboy.pro file ( see below ):


The Centroid is the 'cardboard cutout' CP or more importantly where the wind will push on the rocket when it is sitting on the rail.

Anyhow ... OR says the CP is at 8.21 inch ( 209 mm ) and PROFILER says the CP is at 8.187 in ( 208 mm ) as you listed in your table.

I wonder what OR is doing with the CP calcs ?

I wonder what the OR note '"at Mach 0.300" means ?

One thing I noticed is that Wind Velocity in the sim setup affects the OR Stability -vs- Time plots.

This is a plot with my 'standard' 12 mph wind speed:


Note the wiggles -n- squiggles as the rocket oscillates in the wind.

OTOH, this is the same motor && rocket where the wind speed was zeroed-out:


It looks like maybe OR is factoring the wind speed into the stability calcs somehow ???

I dunno ...

As for PROFILER ...

Several of us on on RMR and at TRASD used PROFILER to calculate CP way back in the mid-1990s and it still works.

I would need to clean it up a tad so it will run on a modern Linux Box but I'll gladly share it with anyone that wants it.

-- kjh

This is what a .pro file looks like:

[root@kjhlt7 tmp]# cat fatboy.pro.txt
#
#  Comments can be entered as #'d lines.
#
Name    FatBoy Plan Area

TNose   Elliptic                 Nose Types:  Ogive, Elliptic, Conic, Parabolic
Ln      4.00                  Length of Nose
Dn      2.60                  Diameter of Nose
Zn      0.00                  Offset: end-o-rocket to tip-o-nose ( usually 0 )
#
#  This is the 'real' trapezoidal fin, excluding the rake
#
#  Notes:  Lf is the length of the body tube under the fins.  I included
#  it here so that the program can 'hide' rotated fins behind the tube
#  ( try a rocket with 3 fins ).  Zf need not be the same as the (Z,R)
#  value of the (Leading,Root) edge of the fin and Lf need not be the
#  same as the root chord of the fin (Zn,Yn) --> (Z0,Y0)
#
Begin Fin
      TFin   Polgon           Type of Fins:  Polygon, Elliptic, Parabolic
      NFin   3                Number of Fins on Fin Can
      Zf     4.00             Distance of Fin Can From Tip of Nose
      Lf     7.992            Length of Fin Canister Body Tube
      D1f    2.600            Diameter of Bt at Front of Fin Can
      D2f    2.600            Diameter of Bt at Rear of Fin Can
      Xf     0.125            Thickness of Fin

      Edges  4                Number of Sides on Fins ( Counting Root )
      Edge Data               Tell Prog to Read <Edges> Ordered Pairs
            4.742    0.00     (Z,R) Z - along Bt, R - Radial  (Leading, Root)
            6.742    2.625    Next (Z,R), Clockwise
            8.617    2.625    Next (Z,R)
            7.992    0.00     Back to Root Edge
      end Data
End Fin

done                          Optional:  everything after done command ignored

 

[kjhambrick]

So I see the same pattern for the NominalBoy and SkinnyBoy ...

Your CP Table from Post #3:


And this is the PROFILER image and CP Data for the NominalBoy:


And for the SkinnyBoy:


Note that I simply added a PROFILER 'body tube' to the FatBoy Model to make NominalBoy and SkinnyBoy.

This works because a cylindrical section does not affect the classic BEq calcs.

Also Note that PROFILER produced the same BEq CP as RockSim-Barrowman ( NominalBoy = 468mm, SkinnyBoy = 720mm )

Another Note ...

OR seems to add the length of the trailing fins to the length of the rocket.

Q: How long is a FatBoy Body Tube ?

Thanks @Buckeye !

-- kjh

EDIT: appended fatboy-nominal.pro as fatboy-nominal.pro.txt and fatboy-skinny.pro as fatboy-skinny.pro.txt

 

[Buckeye]

So I see the same pattern for the NominalBoy and SkinnyBoy ...

What is the pattern/concern, exactly? Rocksim Barrowman, OpenRocket, and PROFILER all give the same CP within a couple millimeters. Could be round off?

The wind is causing some angle of attack changes that moves the CP around and the flight path adjusts to it.

I always assume the length is the maximum length, including fin overhang, so I use whatever value is reported by OR/RS.

 

[kjhambrick]

Thanks @Buckeye.

No worries ... just observations.

-- kjh