CFD with FreeCAD!

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Working on a first "real" simulation. I was surprised at how thin the layers at the rocket surface needed to be to get to a y+on the order of 10. I also wasn't very successful in getting multiple polygon mesh refinements to work like you had done. I could get one box inside the main model, plus a "distance form the rocket surface" one to work. Finally, I just love it when residuals do this kind of thing. It is still working, so we'll see what it comes up with. The domain is 1500x1500 with a 100mm-diameter rocket, so we're looking at ~0.4% obstruction.

This solution is blowing up, most likely from the mesh. Are you running steady state, or attempting transient? Residuals really have no meaning in a true transient flow. They will level out and oscillate without dropping orders of magnitude. Your residuals are not doing that, though. Your simulation is all over the place and diverging. (I tried a transient run, and the CfdOF parameters are pretty sparse. Will need to tune the settings in the OpenFOAM dictionaries to get a good blend of accuracy/efficiency.)

Anyway, a nicely converged steady-state solution is feasible. I changed my convergence from 1.0E-03 to 1.0E-04. No troubles.

1710249789502.png
 
I ended up having to abandon the simulation above and model it with a thicker boundary layer. That model was going weird, like drag forces in the range of 1E110 N. I did get it running, and saw the same asymmetry as above. Arrgh. Then inspiration struck and I went looking for a gravity term. Huzzah! I was applying gravity, in the negative Y direction, which would explain airflow appearing to flow down to the left (+Y is up on those views, airflow from the left). So I deleted gravity from the model and got...

Exactly the same flow asymmetry. Double arrgh. You can see that the wake is about even with the top of the body tube on the top of the rocket, and substantially below it on the bottom.

I should probably try a repeat with modeling the entire domain instead of assuming symmetry about centerline. That will double computation time, but maybe there's something weird about the constraint that's messing me up.

On a sanity check, I did see that my domain looks to be a reasonable size. The incoming velocity is 300 m/s, to match the OpenRocket CP calculation of Mach 0.3. At the edges of the domain, the velocities vary less than +/- 1 m/s from that incoming speed.

Yes, turn off gravity.

Mach 0.3 would be about 100 m/s, not 300 m/s. Not sure if this matters in the incompressible solution.

OK, I see your non-symmetry. Could be bad mesh or the solution hasn't run long enough, and nicely enough, to develop the flow.

This is my 8 degree AoA model. There is still nice wake symmetry across the y-axis. Here are velocity slices through the centerline and through the fins.

1710251129563.png1710251031059.png
 
Last edited:
This solution is blowing up, most likely from the mesh. Are you running steady state, or attempting transient? Residuals really have no meaning in a true transient flow. They will level out and oscillate without dropping orders of magnitude. Your residuals are not doing that, though. Your simulation is all over the place and diverging. (I tried a transient run, and the CfdOF parameters are pretty sparse. Will need to tune the settings in the OpenFOAM dictionaries to get a good blend of accuracy/efficiency.)

Anyway, a nicely converged steady-state solution is feasible. I changed my convergence from 1.0E-03 to 1.0E-04. No troubles.

View attachment 635078
Yeah, that was the set of residuals from the run that I stopped because the forces were getting weird. I changed the thickness of the boundary layer cells and it was much more like yours.
Yes, turn off gravity.
I just hadn't seen that switch in the inputs...
Mach 0.3 would be about 100 m/s, not 300 m/s. Not sure if this matters in the incompressible solution.
Arrgh again. Gotta go check my math. Running it in incompressible flow at M0.9 probably makes for weirdness.
OK, I see your non-symmetry. Could be bad mesh or the solution hasn't run long enough, and nicely enough, to develop the flow.
Since it's been persistent every time I've used the model split on CL with a symmetry constraint and one of the instruction videos said that they'd had trouble with the symmetry constraint, I'm thinking that's what it is. I'll try the bigger model and see what happens. I also likely ned to add some mesh refinement right at the aft end of the rocket. The wake bubble is coming together just as the refinement zone for the rocket itself ends, so there's a lot of airflow features that are likely getting lost in the refinement transition. One problem at a time though.
This is my 8 degree AoA model. There is still nice wake symmetry across the y-axis. Here are velocity slices through the centerline and through the fins.

View attachment 635082View attachment 635081
 
Since it's been persistent every time I've used the model split on CL with a symmetry constraint and one of the instruction videos said that they'd had trouble with the symmetry constraint, I'm thinking that's what it is. I'll try the bigger model and see what happens.

I haven't tried symmetry, since I am happy with my 2M cell model and 1-2 hour run times. One less thing to worry about.

Yeah, looks like CfdOF had some issues/changes to the 2D meshing method. Probably affects the symmetry constraint as well.
 
So I did finally get this running with a full model, ignoring the symmetry. I'm still getting a little bit of asymmetry in the wake:
1710883570971.png

It's even worse seen from the positive Y direction:
1710883664972.png

Sorry for rockets pointing different directions--that's just how the default views came up.

Before I abandon this, I would like to get some force and moment information to see how much that asymmetry affects the results. The online videos say to use the Extract Blocks tool to extract the surfaces I want, but I'm not seeing any of my rocket surfaces in the tree. Is that something I need to set in CFDOF before I run the analysis?

Thanks!
 
Not sure what to tell you on the asymmetry. This is a 4-fin rocket, yes? No cracks or leaks in the rocket surface near the fins or base? No mesh inside the rocket? All 4 fins 90 degrees apart? Is it merely perspective vs. orthographic view in Paraview?

If you set up the ReportingFunction in FreeCAd/CfdOF, there should be force and moment files in case/postProcessing/ReportingFunction. Plotting these vs. time/iteration is the best measure of convergence.

In Paraview, you need to activate the desired mesh regions in the OpenFOAMReader1 properties. I just check internalMesh and the rocket patch. Apply.

1710894934035.png

Then, extract block on the internal mesh. Extract block again on the rocket patch. Now, you can work with the fluid mesh and rocket body separately as needed.

One of the YouTube tutorials then did extract surface on the rocket patch block. Not sure why that is needed, but I do it anyway.

Don't know what CleantoGrid1 is. FreeCAD/CfdOF generates that filter when it launches Paraview. Maybe it is useful, but I ignore it.

Paraview is weird.
 
Not sure what to tell you on the asymmetry. This is a 4-fin rocket, yes? No cracks or leaks in the rocket surface near the fins or base? No mesh inside the rocket? All 4 fins 90 degrees apart? Is it merely perspective vs. orthographic view in Paraview?
It's definitely asymmetrical--I can see the differences in x, y, and z velocity gradients. It's 4 fins, and all four are at 90 degrees separation. The mesh should be OK. There are some slightly weird lines of cells, but honestly nothing that I can fix anyway. The mesh tools don't really give you options for cleaning up stuff.
If you set up the ReportingFunction in FreeCAd/CfdOF, there should be force and moment files in case/postProcessing/ReportingFunction. Plotting these vs. time/iteration is the best measure of convergence.

In Paraview, you need to activate the desired mesh regions in the OpenFOAMReader1 properties. I just check internalMesh and the rocket patch. Apply.

View attachment 636254

Then, extract block on the internal mesh. Extract block again on the rocket patch. Now, you can work with the fluid mesh and rocket body separately as needed.

One of the YouTube tutorials then did extract surface on the rocket patch block. Not sure why that is needed, but I do it anyway.

Don't know what CleantoGrid1 is. FreeCAD/CfdOF generates that filter when it launches Paraview. Maybe it is useful, but I ignore it.

Paraview is weird.
I'll try extracting the data. Thanks for the quick tutorial.
 
Just stumbled across this thread. I'm the guy who gave the talk at vNARCON, but I'm far from a CfD expert. My goal was to make people aware that it was there so that they could play with it. I'd say that was a success!

I do want to make this process easier in terms of workflow. CfDOF is a great add on for the generic case, but I want a workflow that will allow a beginner user to do some meaningful analysis of their rockets, from mesh generation to analysis. In particular, no one should have to learn paraview to see some basic results. But I know enough to be dangerous and not enough to know if I'm doing it right. So I'm looking for some help.

What I need is a "consultant" who can help with the CfD part. I can do the coding although you're welcome to help with that if you have the expertise. If you're interested in helping send me a note!

Great thread @Buckeye! Glad to see this discussion!
 
Just stumbled across this thread. I'm the guy who gave the talk at vNARCON, but I'm far from a CfD expert. My goal was to make people aware that it was there so that they could play with it. I'd say that was a success!

I do want to make this process easier in terms of workflow. CfDOF is a great add on for the generic case, but I want a workflow that will allow a beginner user to do some meaningful analysis of their rockets, from mesh generation to analysis. In particular, no one should have to learn paraview to see some basic results. But I know enough to be dangerous and not enough to know if I'm doing it right. So I'm looking for some help.

What I need is a "consultant" who can help with the CfD part. I can do the coding although you're welcome to help with that if you have the expertise. If you're interested in helping send me a note!

Great thread @Buckeye! Glad to see this discussion!
Maybe you could get open foam to work with open rocket, take the model from open rocket and do the analysis atomically in open foam?
 
Maybe you could get open foam to work with open rocket, take the model from open rocket and do the analysis atomically in open foam?
You can already import most OpenRocket files using the Rocket Workbench. Not all features are currently supported (like pods) but most will import fine. This is a work in progress
 
Just stumbled across this thread. I'm the guy who gave the talk at vNARCON, but I'm far from a CfD expert. My goal was to make people aware that it was there so that they could play with it. I'd say that was a success!

I do want to make this process easier in terms of workflow. CfDOF is a great add on for the generic case, but I want a workflow that will allow a beginner user to do some meaningful analysis of their rockets, from mesh generation to analysis. In particular, no one should have to learn paraview to see some basic results. But I know enough to be dangerous and not enough to know if I'm doing it right. So I'm looking for some help.

What I need is a "consultant" who can help with the CfD part. I can do the coding although you're welcome to help with that if you have the expertise. If you're interested in helping send me a note!

Great thread @Buckeye! Glad to see this discussion!

Success for sure, Dave. Your NARCON presentations caught my eye!

Your goal is ambitious. Having run a number of cases now, and seeing comments from others, I will temper my enthusiasm from the beginning of this thread and add a caveat. CfdOF is great for rocket hobbyists with some experience in CFD. CfdOF is a nice front-end to OpenFOAM, but you still need to know what the inputs mean, how to look at results, and how to determine if the results make any sense. That takes some expertise (typically Masters degree engineers). Building an automated workflow for non-experts has always been the holy grail for CFD. Some industries can achieve this if their geometries are simple and the analysis is routine with little to no deviation from the standard case. Rocket aerodynamics will be a challenge unless you really, really clamp down on the scope.

The Rocket Workbench is excellent, and that is how I built all my rockets for CFD analysis. Starting with original CAD is always best. People want to dump obj files from OpenRocket into FreeCAD and start simulating. It is not that easy. I tried. Mesh files are a pain to edit and manipulate. FreeCAD and CfdOF want everything to be a "solid." I found a method, requiring about 7 steps, to manipulate an obj file into something useable for CfdOF. Still, there are inherent problems, such as OR fins just touching a body tube on a tangent line. That will not mesh nicely in CFD. The fins need to be buried into the body tube, like your fincans in the Rocket Workbench.

All that said, I can consult with you on CFD stuff. I can't help on the coding, though. It will be an interesting project!
 
Last edited:
Can you summarize the problems with it, also can you recommend a way to learn those skills? A online course or something?

Compressible, incompressible, shock waves, separated flow, vortex shedding, laminar, turbulent, turbulence models, steady-state, transient, open or fixed BCs, boundary layers - first height, total height, number of layers, initial conditions, wall functions, y+, pressure-velocity coupling, Courant number, time step, run time, prism/tet/hex/poly elements, surface mesh resolution, volume mesh resolution, mesh quality, adaptive mesh, domain size, residuals, order, convergence...

I don't know of any shortcuts. 4 years as an engineering undergrad, plus a couple years grad school with emphasis in fluid mechanics and numerical methods, plus several years on the job training in CAE is typically what it takes for most engineers to be proficient in CFD.
 
Compressible, incompressible, shock waves, separated flow, vortex shedding, laminar, turbulent, turbulence models, steady-state, transient, open or fixed BCs, boundary layers - first height, total height, number of layers, initial conditions, wall functions, y+, pressure-velocity coupling, Courant number, time step, run time, prism/tet/hex/poly elements, surface mesh resolution, volume mesh resolution, mesh quality, adaptive mesh, domain size, residuals, order, convergence...
You lost me at turbulent, I guess it’s good that unlike everyone else on this forum, I can still attend college!

Ps but I’ll probably not go into CFD, I’ll probably go for propulsion although it’s probably a bit to early to decide on a sub specialty of aerospace.
 
Compressible, incompressible, shock waves, separated flow, vortex shedding, laminar, turbulent, turbulence models, steady-state, transient, open or fixed BCs, boundary layers - first height, total height, number of layers, initial conditions, wall functions, y+, pressure-velocity coupling, Courant number, time step, run time, prism/tet/hex/poly elements, surface mesh resolution, volume mesh resolution, mesh quality, adaptive mesh, domain size, residuals, order, convergence...

I don't know of any shortcuts. 4 years as an engineering undergrad, plus a couple years grad school with emphasis in fluid mechanics and numerical methods, plus several years on the job training in CAE is typically what it takes for most engineers to be proficient in CFD.
Good answer, if somewhat depressing from a software development point of view. Let's start simple by narrowing down the problem we wish to solve with an eye to restricting our conditions. I'm thinking Cd and CP over a range of velocities? We can start with specific ranges (low subsonic, trans-sonic, sonic, etc) and expand them later through either manual or automated means. You're looking and up to 300 m/s here. Perhaps that's a good starting point.

Once that's settled we can look at the follow on problems. Mesh generation options, virtual wind tunnel size, position within the tunnel, turbulence models, results analysis, etc.

We may not be able to eliminate the expertise requirement, but there may be ways to simplify selecting the options.
 
You lost me at turbulent, I guess it’s good that unlike everyone else on this forum, I can still attend college!

I went back to school at 50 to get my engineering degree, and there are plenty of older people that have done it.

I would say that a sufficiently motivated person could teach themself this stuff, in a shorter period of time, with a good mentor. Tough to find that out of employment, however. And employment implies degree.....

That's why forums like this are valuable IMO, to make contacts with like-minded people.

Rocket aerodynamics will be a challenge unless you really, really clamp down on the scope.
I would say that a rocket is actually a great place to start compared to something like an airplane, where you are looking for things like control moments, stability margins, airfoil performance, Etc.

Learning a clunky interface seems like the standard for any interesting software :eek:
 
Learning a clunky interface seems like the standard for any interesting software :eek:
It's easier to create a good interface when looking at a single specific workflow. Generality leads to clunkiness. Which of course means you're right :p

In our case, for example, presenting a number for Cd or CP is a simple interface whereas ParaView with all its options makes that a steep learning curve. Even just being able to do that would greatly simplify the UI IMHO.
 
Good answer, if somewhat depressing from a software development point of view. Let's start simple by narrowing down the problem we wish to solve with an eye to restricting our conditions. I'm thinking Cd and CP over a range of velocities? We can start with specific ranges (low subsonic, trans-sonic, sonic, etc) and expand them later through either manual or automated means. You're looking and up to 300 m/s here. Perhaps that's a good starting point.

Once that's settled we can look at the follow on problems. Mesh generation options, virtual wind tunnel size, position within the tunnel, turbulence models, results analysis, etc.

We may not be able to eliminate the expertise requirement, but there may be ways to simplify selecting the options.

Good thinking! I would reduce even further. For the initial project, I think success would look like this:
  1. User loads his rocket model (FreeCAD, iges, step, other?)
  2. Software builds the virtual wind tunnel, assigns BCs, and mesh refinements (much of this can be parametrized based on the size of the model)
  3. Software assigns simulation type and settings
  4. Mesh is successful
  5. Solver is successful in a couple hours, maximum.
  6. Output includes drag, lift, CP (CP becomes tricky and abstract with oddrocs)
  7. Output includes some flow pictures
Most beginners can't get past step 2. That's where your software would be most helpful.

I would limit the simulation to one speed (M=0.3), incompressible, steady-state. As you go supersonic, then the mesh, BCs, and solver need to change to different algorithms. Maybe include a range of angle of attack instead, to get better understanding of stability.

This approach has an eye to comparing one design vs. another, rather than absolute accuracy.
 
Buckeye:

To the point of replacing Rocksim or OR, I would suggest horses for courses. I think that the two most used functions of these sim programs are to determine optimal delay/deploy speed, and to determine Cg and Cp. To this end, current software does that pretty well doesn't it?

I agree that something like CFD of the flow around the rocket would do better with Cp calcs than Barrowman. To me, the most interesting use for this would be in determining optimal airfoil and nose/transition/boat tail shape. You'd need something that could handle sub- and super-sonic flows and the transition between them.

Is there an analogous app added to FreeCAD that could analyze the airframe using to solid finite elements? This would allow a more accurate Cg, for sure, but might also be used to determine optimal printed shapes or to identify the location of highest structural stress.

As far as easy adoption, well... I've been doing simulation work (ODEs, not usually PDEs) for over 30 years, and my experience is that what is elementary to experts may be seen as impossible to understand by those not in the field, even highly intelligent ones. I once created a "modeling 101" slide deck for pharmaceutical scientists (all PhDs). My boss worked with me to improve the presentation. To the point where I only had one equation! (Co = D/V. Initial drug concentration = dose/effective blood volume). Slide 10 of a 20 slide deck. After the talk I received universal approbation and thanks, but one guy said "Great presentation - I followed it really well until that equation....". So my experience is that stuff that is really easy and useful for me must be explained very patiently to others, even if they are geniuses in their field.

To this point, do you plan to put the source files out there on git or sourceforge some such? Without such a tutorial, I suspect that I would not be able to figure out how to do even a simple example. Something like that, with some tutorial narrative added, would really advance the use.

Thanks for sharing this. Super interesting.
come in another post where I use this CFD model for center of pressure analysis.
 
Last edited:
I would say that a rocket is actually a great place to start compared to something like an airplane, where you are looking for things like control moments, stability margins, airfoil performance, Etc. :eek:

True. An automobile is even more difficult in that the geometry is more complicated (underhood and underbody details) and with rotating tires on a moving ground plane.
 
You lost me at turbulent, I guess it’s good that unlike everyone else on this forum, I can still attend college!
Werner von Heisenberg was reported to have said

“I am an old man now, and when I die and go to heaven, there are two matters on which I hope for enlightenment. One is quantum electrodynamics and the other is the turbulent motion of fluids. About the former, I am really rather optimistic.”

So I'm not sure that even a college degree (or several) will allow you to understand turbulence. My model of thinking about turbulence is that when inertial forces are greater than viscous ones, all hell breaks loose. That's as far as I got.
 
Buckeye:

To the point of replacing Rocksim or OR, I would suggest horses for courses. I think that the two most used functions of these sim programs are to determine optimal delay/deploy speed, and to determine Cg and Cp. To this end, current software does that pretty well doesn't it?

I agree that something like CFD of the flow around the rocket would do better with Cp calcs than Barrowman. To me, the most interesting use for this would be in determining optimal airfoil and nose/transition/boat tail shape. You'd need something that could handle sub- and super-sonic flows and the transition between them.

Is there an analogous app added to FreeCAD that could analyze the airframe using to solid finite elements? This would allow a more accurate Cg, for sure, but might also be used to determine optimal printed shapes or to identify the location of highest structural stress.

As far as easy adoption, well... I've been doing simulation work (ODEs, not usually PDEs) for over 30 years, and my experience is that what is elementary to experts may be seen as impossible to understand by those not in the field, even highly intelligent ones. I once created a "modeling 101" slide deck for pharmaceutical scientists (all PhDs). My boss worked with me to improve the presentation. To the point where I only had one equation! (Co = D/V. Initial drug concentration = dose/effective blood volume). Slide 10 of a 20 slide deck. After the talk I received universal approbation and thanks, but one guy said "Great presentation - I followed it really well until that equation....". So my experience is that stuff that is really easy and useful for me must be explained very patiently to others, even if they are geniuses in their field.

To this point, do you plan to put the source files out there on git or sourceforge some such? Without such a tutorial, I suspect that I would not be able to figure out how to do even a simple example. Something like that, with some tutorial narrative added, would really advance the use.

Thanks for sharing this. Super interesting.
come in another post where I use this CFD model for center of pressure analysis.
To the point of replacing Rocksim or OR, my question is why would we? I was faced with this decision early in the development of the Rocket WB and my decision was not to do so. My goal became to solve problems they can't or don't do well, and leave them to do what they do best. CfD and FEA are capabilities they are unlikely to ever support and can answer questions they can't. That needs to be the focus, and that is my development goal. If we can exchange data with them I feel that is a better use of limited resources.

We could easily implement OR in FreeCAD. It's just a question of time and effort. They have a team of developers. So far it's just me. I'm not taking that on.
 
Good thinking! I would reduce even further. For the initial project, I think success would look like this:
  1. User loads his rocket model (FreeCAD, iges, step, other?)
  2. Software builds the virtual wind tunnel, assigns BCs, and mesh refinements (much of this can be parametrized based on the size of the model)
  3. Software assigns simulation type and settings
  4. Mesh is successful
  5. Solver is successful in a couple hours, maximum.
  6. Output includes drag, lift, CP (CP becomes tricky and abstract with oddrocs)
  7. Output includes some flow pictures
Most beginners can't get past step 2. That's where your software would be most helpful.

I would limit the simulation to one speed (M=0.3), incompressible, steady-state. As you go supersonic, then the mesh, BCs, and solver need to change to different algorithms. Maybe include a range of angle of attack instead, to get better understanding of stability.

This approach has an eye to comparing one design vs. another, rather than absolute accuracy.
Kidding above aside, I think this is the best way forward. I don't think that CFD will replace OR or RockSim simply because of processing time. I'm not going to use a tool that takes 4-8 hours to find a limited answer when I can use one that finds a more useful answer in seconds. I see CFD having value in "weird" situations like oddrocs and unusual fin geometries that are hard to simulate in the legacy simulations. Of course, gathering data for things like tube and ring fins would be a nice side project too.

I would add to the above:
8. Calculation of CD to back-enter into OR or RS
9. Setup and run of a suite of ~3-7 angles of attack so that you can measure CP with flow at an angle rather than just zero angle of attack. That's more useful for stability.
 
Good thinking! I would reduce even further. For the initial project, I think success would look like this:
  1. User loads his rocket model (FreeCAD, iges, step, other?)
  2. Software builds the virtual wind tunnel, assigns BCs, and mesh refinements (much of this can be parametrized based on the size of the model)
  3. Software assigns simulation type and settings
  4. Mesh is successful
  5. Solver is successful in a couple hours, maximum.
  6. Output includes drag, lift, CP (CP becomes tricky and abstract with oddrocs)
  7. Output includes some flow pictures
Most beginners can't get past step 2. That's where your software would be most helpful.

I would limit the simulation to one speed (M=0.3), incompressible, steady-state. As you go supersonic, then the mesh, BCs, and solver need to change to different algorithms. Maybe include a range of angle of attack instead, to get better understanding of stability.

This approach has an eye to comparing one design vs. another, rather than absolute accuracy.
So let's take this as a working list to start. Let's assume 1 is done (outside the scope of this discussion... a straight forward coding problem). Let's look at step 2.

What are the rules of thumb here? e.g. Tunnel width = 3x rocket size, length = 5x, position = 2x, etc

Parameters for meshing? Would they be different when exploiting symmetry?

Just a warning... this is a multi-month project. I'm currently doing materials for FreeCAD 1.0 so there are competing priorities. But it will help to nail some of this down before starting.
 
True. An automobile is even more difficult in that the geometry is more complicated (underhood and underbody details) and with rotating tires on a moving ground plane.
Analysis of bicycle dynamics may be worse. Very difficult.

On edit: I found one of my graduate study advisors, Karl Åstrom, made a presentation on bicycle dynamics. Åstrom is a rather famous control theory/dynamic systems guy. This may be interesting to some:

https://archive.control.lth.se/media/Staff/KarlJohanAstrom/Lectures/BikeTalkKTH2006.pdf
 
Last edited:
So let's take this as a working list to start. Let's assume 1 is done (outside the scope of this discussion... a straight forward coding problem). Let's look at step 2.

What are the rules of thumb here? e.g. Tunnel width = 3x rocket size, length = 5x, position = 2x, etc

Parameters for meshing? Would they be different when exploiting symmetry?

Just a warning... this is a multi-month project. I'm currently doing materials for FreeCAD 1.0 so there are competing priorities. But it will help to nail some of this down before starting.

I'll send you a PM with some suggestions and a FCstd file as an example.

Yes, #1 is out of scope, but still important to the workflow. The model has to be a "solid", maybe also a "compound" if it contains multiple parts, watertight, no zero-thickness baffles, etc.

OR's obj output is good for rendering and maybe some 3D printing. It is not great for CFD models. This is how OR attaches a fin to the body tube. This is inviting mesh problems.

1716925627062.png
 
Buckeye:

To the point of replacing Rocksim or OR, I would suggest horses for courses. I think that the two most used functions of these sim programs are to determine optimal delay/deploy speed, and to determine Cg and Cp. To this end, current software does that pretty well doesn't it?

I was referring to replacing the aero modeling of OR and RS, like CD and CP, especially for shapes not handled by Barrowman and DATCOM. CFD is not trajectory analysis, which the current hobby software does pretty well.

Is there an analogous app added to FreeCAD that could analyze the airframe using to solid finite elements? This would allow a more accurate Cg, for sure, but might also be used to determine optimal printed shapes or to identify the location of highest structural stress.

Yes, there is an FEA Workbench.

To this point, do you plan to put the source files out there on git or sourceforge some such? Without such a tutorial, I suspect that I would not be able to figure out how to do even a simple example. Something like that, with some tutorial narrative added, would really advance the use.

Thanks for sharing this. Super interesting.

See post #13 and Dave Carter's NARCON presentations. FreeCAD and CfdOF are open source and available.

https://github.com/jaheyns/CfdOF

come in another post where I use this CFD model for center of pressure analysis.

https://www.rocketryforum.com/threads/cop-simulation-comparison-including-cfd.184722/
 
Back
Top