# Build thread: rocket aerodynamics program

#### Jeff Lassahn

##### Well-Known Member
TRF Supporter
I think it's cute to do a build thread for a computer program, rather than a rocket. I can fantasize about taking the code out into the driveway and spraying on a primer coat or something.

Anyway, I'm working on a program that does aerodynamics calculations for rocketry, and this thread is where I'll document my progress. I've posted bits and pieces in other places and now I'm trying to get organized.

The story so far...
I wrote a fairly simple Panel Method solver about a month ago for computing airflow around a 3D object in Go, to see whether I could make it work.
It kind of worked.
I've been gradually improving it ever since, trying to make it good enough to be useful for things like CP estimates for rocket designs.
Now I'm trying to get more systematic about working on it.

The current User Interface (if it can be dignified with such a name) goes something like this:
1. You type a text file which describes the rocket geometry. There's an example attached to this post.

2. You run the program from a command line, and it thinks a while and spits out some text which might have hidden in it some actual aerodynamics results, like this:
Code:
``````solving 1044 panels
solving done
lift = 0.004 drag = 0.001
force = {-0.004019384 0.00015826232 8.0558493e-10}
torque = {-1.2718715e-10 -5.919676e-11 -0.00040920314}
par = {-9.413501e-05 -0.00053386565 0}
perp = {-0.003925249 0.000692128 8.0558493e-10}
strength = 2.2407057e-05
map[Body:{-5.735272e-05 0 -8.7538865e-12} Fins:{-0.0037655758 0.00023054832 6.5324457e-10} Nose:{-0.00025628772 2.772361e-05 -3.657874e-10} Tail:{-9.520942e-05 -4.4910586e-05 3.1081981e-10} TipBody:{0.00010766924 0 2.564775e-10} TipNose:{-0.00015274544 2.4437386e-05 -4.570211e-11} TipTail:{0.00020011759 -7.953635e-05 -4.3564796e-10}]
residual force = {0 0 -4.2081183e-10}
Force Perp = {-0.004019384 0.00015826232 1.2263968e-09}
Cp offset = {-0.0040024393 -0.10164984 1.5949047e-08}
Cp = {-0.0040024393 -0.10164984 1.5949047e-08}
Cd = 0.002760902``````

3. You also get out a folder full of files that are a webpage displaying the results as a 3D rendering, which looks like this can be rotated around live to get a better look at things:

And then you stare at that until you attain enlightenment.

I'm keeping the code on GitHub: https://jlassahn.github.io/aerodynamics/

Next steps include putting the useful parts of the output into the webpage in readable form with correct units so I don't have to drive myself nuts finding results and converting them with a calculator.

#### Attachments

• zeerust.txt
774 bytes · Views: 6

#### Alan15578

##### Well-Known Member
I think it's cute to do a build thread for a computer program, rather than a rocket. I can fantasize about taking the code out into the driveway and spraying on a primer coat or something.
OK, What you want to do is find an old 110 baud TTY teletype with a paper tape punch. That's the easy part. Then find the paper tape and figure out how to get your code punched out on it. Pick a large but simple rocket, such as the Big Bertha. Build it and paint the body white, you can hold off on the fins and nose cone for a bit. Paint one side of the punched paper tape with a dark color. I used metal flake blue. Glue the paper tape in a spiral around the body. Trim the edges and cutaway the paper tape where the fins will be glued. Paint the nose cone and fins to suit you taste. I used the same metal flake blue on the nose cone and three fins. One fin was white with a large NAR emblem on it. The result was quite pleasing with random white dots showing through the darker color. And of course you know it is your computer program.

What is the Go programming language and why is it suitable for your project? Did you actually develop and code the "compute engine", or did you just use the code from some other program? What computer specs do you run it on, what is your CPU speed, number of cores, RAM, do you use or need a GPU with Cuda cores. etc.? What computer requirements do you recommend for users, and how long does it really take? Realistic problems will be more complex and larger that your test case. The user interface and I/O is a massive challenge as well.

I'd like a manageable tool that works for things like a key chain camera taped to the side of a rocket, to find the trim angle of attack, etc. I'd like to analyze the effect of misaligned fins and other asymetric parts, and of course odd rocs like the Marvin The Martian Rocket.

FWIW, in 1990 I wrote a program for a higher order surface-source method on a body or revolution. It ran just fine on a Commodore 64. I worked a lot of numerical analysis into that thing, and I did not even need to use external storage. However, I actually wanted to do a NLF inverse design problem and the C64 just was not fast enough for that. I still have all my Commodore computer equipment, but I suspect all the disks are useless.

#### Jeff Lassahn

##### Well-Known Member
TRF Supporter
I'm thinking of going with more of a green and white striped tractor-feed paper look...

Go is a relatively new language that's come out of Google. It generates relatively efficient code, so it's reasonable for doing mathematical heavy lifting. It has some nice conveniences like automatic memory management with garbage collection. It's biggest claim to fame is that it's very good for writing code that runs across multiple CPU cores (although I'm not doing that yet with this project).

I coded everything from scratch. The "engine" is a panel method solver that does linearized inviscid flow calculations. The expensive part of the calculation is solving a system of linear equations, one per panel. On my Mac laptop (probably about 2.4GHz using a single core) it solves 1000 panels in about a second. But that goes up as the cube of the panel count, so 4000 panels would be about a minute, and it slows down rapidly above that. This is without any fancy optimizations, no GPU optimization, etc.

#### TonyL

##### Well-Known Member
TRF Supporter
Hi Jeff,
An interesting project. Have you looked at open foam? I would be interested in how you think that compares. Also what velocity regimes do your constitutive equations cover?

br/

Tony

#### Jeff Lassahn

##### Well-Known Member
TRF Supporter
Hi Jeff,
An interesting project. Have you looked at open foam? I would be interested in how you think that compares. Also what velocity regimes do your constitutive equations cover?

br/

Tony
I don't have any experience with Open FOAM.
My solver is a linearized inviscid model, which means it assumes no compressability and doesn't model flow separation and turbulence effects. So it works in the region of high Reynolds numbers and low Mach numbers. Probably just about the right range for low power rocketry.

My guess from a web search is that general purpose CFD solvers like OpenFOAM can be made to be much more accurate than what I'm doing, but they're also much more fiddly. That is, they aren't likely to work well without some guidance by the user about algorithm parameters, mesh generation, etc. so you need some specialized expertise to get them to run at all.
I don't have that expertise, this is a "learn by doing" project where I came in pretty naive about CFD. If you've got practical experience with a more mature CFD toolkit I'd be interested in how it went.

#### TonyL

##### Well-Known Member
TRF Supporter
I'm afraid that my rocket 'to do' list is much too long to pick up a CFD tool any time soon, but that one seemed the most financially accessible.
br/

Tony