SpudFiles

It seems likely I'll have about a month of free time between jobs. I figure there's no better way to use my time than to write a new open source spud gun simulation.

The overall goal is to start where GGDT left off. GGDT can't handle transonic guns very well as guns in that speed range require a fundamentally different approach. GGDT could use more recent and accurate valve models. GGDT doesn't lend itself to optimizing energy efficiency very well. GGDT also runs only in Windows and I'd like a cross-platform program. GGDT has not been validated against much experimental data. These shortcomings are the five main things I'd like to address in my new simulation. (There are many other things I could do, but I think these are the most important.)

I can't do all of this alone, though. I'm good with the actual simulation part, but I know nothing about making a GUI, and I'd like to have some good experimental data to validate the model with.

Does anyone here have experience with GUI programming? If I were making this for just me, it'd be a terminal only program, which few people will find useful.

Does anyone with a high speed camera, chronograph, and precision scale at the very least have some time they'd be willing to kill to do a bunch of tests and data analysis? High speed pressure transducers (whether homemade or not) would be very helpful too, but they're not necessary. I consider validating the model to be very important, and we need better data to do it.

Those are the main aspects I do not have the time or patience for. Still, please let me know if you think you could help out with any aspect of this (including the simulation part). I'd like to make this a community project that anyone (if they want to and are capable) can contribute to.

Edit: This will run on Windows, Linux, and Mac OS. I won't use a language that restricts me. Also, it will be completely free. I'm toying with the idea of releasing it as a public domain project even (but I haven't made that decision yet).

Sounds like a valid project

btrettel wrote:Does anyone with a high speed camera

In consumer terms

chronograph

x 2

precision scale

Down to 0.00001 grams

at the very least have some time they'd be willing to kill to do a bunch of tests and data analysis?

Ah, time... some could always be found in the name of science

Perfect.

I'll explain in a little more detail what tests I want to do. Other ideas are great too.

I'd like to measure the muzzle velocity of a bunch of different configurations. Basically, we have to test a range of pressures, barrel lengths, projectile masses, etc., 15+ times and record the results. The tests will be fairly tedious, but once the data is in a spreadsheet, we're done. I have made some progress towards this goal but only for small low speed pneumatics. I'd like more comprehensive and detailed data, especially for the transonic range.

Testing will be fairly tedious, but I figure we all do this without writing the results down anyway.

The high speed camera is for the other tests. With a clear barrel and a high speed camera, we can see what's going on inside the gun. That's the aspect we don't know too much about. We can manually analyze each frame to go from the video to a plot of projectile location vs. time. These tests will probably reveal a lot of problems with the model because a video tells us a lot more than a number.

It'll be fairly tedious to analyze the video so we probably can't do more than 25 or so high speed camera tests without going insane. Still, I think someone else here might know a thing or two about machine vision and could probably write a tool to automatically do it. That'd allow us to just take a billion shots and let the computer handle the rest.

I have some home made chronograph data of in barrel projectile position vs time that you may find useful. With a sensor every foot of the barrel length, you can see the time traveled in each foot. It is with a high CV valve. Sample graph is below. The zero crossing points in the s curve is the magnet in the center of the pick up coil as the magnet is neither approaching nor departing the sensor at that moment.

btrettel wrote:I'd like to measure the muzzle velocity of a bunch of different configurations. Basically, we have to test a range of pressures, barrel lengths, projectile masses, etc., 15+ times and record the results. The tests will be fairly tedious, but once the data is in a spreadsheet, we're done. I have made some progress towards this goal but only for small low speed pneumatics. I'd like more comprehensive and detailed data, especially for the transonic range.

Testing will be fairly tedious, but I figure we all do this without writing the results down anyway.

Some of us do write everything down, I think it comes natural to those who are studying science or doing a technical job for a living.

The high speed camera is for the other tests. With a clear barrel and a high speed camera, we can see what's going on inside the gun. That's the aspect we don't know too much about. We can manually analyze each frame to go from the video to a plot of projectile location vs. time. These tests will probably reveal a lot of problems with the model because a video tells us a lot more than a number.

I don't know how feasible this will be with a 1000 frame per second high speed camera, unless you're limited to very low velocities. With a suspersonic or transsonic projectile it would be useless.

Relatively low velocities like what I did here however could be interesting.

Strobostrobic photography might be more interesting.

Very science-y! Me likey. I can't help too much with the GUI or experimental data, but I'd love to have a look at the simulation code. I'm decent in C/C++. What are planning on writing in?
Tech: clever use of the 'scope!

Tech, I was thinking about that, but I discounted it because a high speed camera does provide more information (barrel vibrations, some of the gas flow, etc.). You and JSR have me thinking, though.

The advantage in spatial resolution is not very significant for high speed cameras as opposed to the coil setup. We can expect perhaps 5 to 25 frames at 1000 fps for a "low speed" gun. If we use 10 coils, we're basically getting about the same amount of data without the restriction on speed and with far lower costs. I also think the coil setup would provide data that is far easier to process. The conclusion is that the coil setup would be better here, especially for high speed tests.

Also, one thing I want to make clear is that the valve flow coefficient must be accurately determined through some means other than futzing with the simulation to find that works best. That's treating the flow coefficient as a fudge factor. I want to model the physical processes accurately such that a flow coefficient found through standard test procedures can be plugged in and we can get a good idea of what performance to expect before doing any gun testing. Right now the "standard test procedure" is to make a gun and test that, but if the flow coefficient is also capturing characteristics of the gun, then this coefficient isn't very useful for other guns with the same valve.

Skywalker, my plan is to use Python as I know it's cross platform and it's fairly simple to work with. I'm open to other suggestions, but as I know Python reasonably well and it will do what I want, it's my choice. If you're good with C or C++ then you won't have any issues with Python.

The flow of the valve was based on GGDT and matching my measured performance against the model in GGDT. Due to the limitations in GGDT this may be off somewhat. As a second test the air velocity of the discharge was observed in a 1,000 frame per second video. The beginning of the flow and the end of the flow from the fixed chamber volume provides a time constant of the air chamber, valve projectile and barrel. Again a fairly high CV is needed to match my discharge time. If you would like to view the frames in the HS video. It can be seen on the engineering challenge site where I posted the results and frame grabs from the HS video.

I'll dig up a link later. The video shows the initial air movement as a label on a bottle starts to peel off, followed by the emergence of the projectile all the way to the cessation of the low temperature fog. This gave me a finite time from beginning of flow to the depletion of the air chamber. A highly restrictive valve would have taken much longer to complete the discharge of the chamber.

Edit; Found the link to the photo sequence. The first composite photo on the page contains the frames cropped to expand the area of interest and cropped to save space. The first frame is prior to flow. The second frame shows a pressure wave exiting the barrel. It is difficult to see in the compressed photo. In the 3rd frame the compression wave has passed the bottle and pulled the label loose. Yes the valve is that quick. The frames are 1ms apart. This cannon is a 2 inch valve with a 3 gallon chamber. The barrel is 2.5 inch PVC. You can see the recoil of the barrel during the shot.
http://inteltrailblazerschallenge.wikispaces.com/Photos

Another backup I have of the valve performance is the sound of the tank and valve with no barrel being discharged. The pressure wave of the discharge and the high frequency of the chaos of the discharge (roar) is not difficult to measure the duration giving a somewhat accurate TC of the tank and valve combination.

Feel free to examine other pages on that Wiki.

I think the best way to go about validating the model is to compile a list of cannons accessible to members with a chronograph, and simulate these cannons at various pressures with various projectiles. Then compare the calculated results to the actual results. This way, no additional construction is needed.

As far as the GUI goes, I have limited experience with like the 2000 edition of Borland. The easiest way by far to make it work is to have almost everything global. I think Java would be the best language to use due to its portability. You can pretty much compile straight C/C++ in java and run it in a virtual machine on anything. Java also supports GUIs (and I should really start my java homework).

I too would like to see the actual simulation code. I tried a langrangian scheme for a valveless, unchambered gun a while ago, but it was a disaster.

Some nifty features I could see adding are a piloted pilot valve (piloting a large valve with a sprinkler valve, or...), and combustion modeling

I'd be happy to help in any way I can (not that I can be that helpful)

Technician, I hadn't seen the first batch of images. Thanks. Are you suggesting a few ways to find the flow coefficient? Or are you showing that the flow coefficient is high?

Let me explain again if I've been unclear. We need to directly find the flow coefficient of the valve. Why? Because working backwards in GGDT or whatever is dependent on the simulation. If the simulation is wrong, your flow coefficient is wrong!

Finding the flow coefficient independent of the gun might be hard to do in most cannons. Many if not most do not have removable valves. So I'm thinking testing a few valves in a reasonably simple way (like venting a large chamber with a pressure transducer) would be best. If the simulation is right for removable valves then it should be right for built-in valves.

ramses has a good point about using existing cannons. Just make sure that everything we need can be measured. The main problem, of course, is getting people to provide useful data. I've asked before for high speed data without much succcess, so I'm not optimistic. But we only need one person to step forward if they do a good job, thankfully.

ramses, Java is highly portable, but it doesn't have anywhere near as good scientific/mathematical libraries as Python, MATLAB, C/C++, FORTRAN, etc. best I can tell. Python has some excellent ones. This is very important to me. I can write any algorithm I need, but it saves a LOT of time and headaches if we don't reinvent the wheel. A basic explicit code (probably what you tried) shouldn't need anything fancy, but if I use an implicit method (which I am considering) then a good linear algebra library would help a lot.

It sounds like you know a lot more about Java than I do, though, so let me know if I'm wrong about this.

I was thinking about making a drag-and-drop window where you can lay out the gun and any connections. Piloted pilot valves would fit on this, as would the DCV and QEV combo. In fact, you could do basically anything with this. This is a feature to add down the road.

Combustion modeling is something to add down the line. It'd definitely on the to-do list, but I don't know much about it at the moment.

There'll be a lot of work to do, so I'm sure you can be directly helpful too. Ideas, discussion, etc. help, and if you can understand the documentation I'll be writing then I'm sure you can suggest code changes. If you can understand what the Lagrangian scheme I mentioned does (i.e. move gas blobs around) then you get most of it. Actually making it work is hard and I have difficulty with that. It's way too easy to make typos.

I'm going to plan the architecture of the code tomorrow and see where I can go. I will be using the Lagrangian method I mentioned before. This paper describes the basics of what I hope to do: http://www.mech.uq.edu.au/cfcfd/code/doc/l1d_98.ps.gz

(This paper, unfortunately, is in a rare format that I only know how to handle on Linux. Thankfully I use Linux primarily.)

Nice to see this getting started, btrettel. I essentially finished my 1D code (using a rather time-consuming but highly physically accurate model of my own design based on the conservation equations for a moving fluid element), but got bogged down in the aforementioned typos and haven't yet got around to devoting a few days to finding them all. Mine was just a 1D valveless test code though - you're presumably writing a 2D code to deal with all the different configurations users input, which should be an interesting project to say the least. Not having the time at the moment to try to open that paper, will you be trying to realistically account for varying disturbance propagation rates throughout the model with an adaptive mesh (essentially what I was doing), or taking the "**** it, close enough" approach?

Regrettably, my interests have drifted away from conventional CFD to DSMC and related methods, which tend to be more appropriate for the things I build nowadays.

I have a 1000 fps high speed camera and a golf ball cannon, would be more than willing to contribute if it is worth it to you. Very excited to hear about this, btrettel!

DYI, I'm sticking with the 1D Lagrangian method I mentioned. This should be accurate enough for most potato guns, but we'll see. That's why I need data. If this is accurate then there's no good reason to going to 2D axisymmetric, for example.

I'd be interested in seeing your approach for some ideas.

I've uploaded a PDF version of the paper I mentioned here: http://btrettel.nerfers.com/sources/l1d_98.pdf

This is basically the same approach I mentioned earlier.

At the moment the plan is to check the accuracy of the code against some exact solutions to see if an adaptive mesh would be helpful. If it won't help, I won't bother. It's worth noting that the 1D Lagrangian method actually is somewhat adaptive in the sense that it naturally concentrates the cells in shocks, but it has many other issues as well.

I'm trying to do this one step at a time. I'm not going to assume I will have a problem until I run into it. As everyone can imagine, this is not an easy task. Writing the code is one thing. Debugging it is another. I've learned this summer as I've written some incompressible CFD codes that I need to simplify things as much as possible and see how well this works before trying to add anything else.

I am not very familiar with the Boltzmann equation approaches but I suppose that's one way to avoid the annoying problem of the boundary moving. Though, DSMC is really for the extremely high speed end of things, so I guess there's no other good way to do it if that's what you're set on. I'd be interested in seeing your code sometime!

Gun Freak, I'll send you a PM later if you think you might be able to get started soon. I'd rather do that before I forget! I've been so busy that it's easy for me to be distracted.

Edit:

Some technical details about the first version:

- most of the basic GGDT features
- 1D Lagrangian scheme in gas chamber, inside of the barrel, and the atmospheric side of the barrel
- ideal gas
- improved ISO valve model
- basic optimizer
- compared against a few exact solutions (at the very least the Sod shock tube case and the very low speed case)

Beta versions will have less features. The optimizer has a fairly low priority for me right now, but I intend to write it.

Later codes will potentially add the following and more:

- gravity's effect on the projectile
- heat transfer to and from the gas to the barrel, etc.
- non-ideal gases
- phase changes (at least recognize that one occurs in a cell)
- leaks
- ability to model pneumatic circuits
- more detailed optimizer
- 6DOF external ballistic model

These additional features will only be added provided I (or whoever can program them) has the time.

You might be able to use c++ libraries in Java. What differentiates Java from c/c++ (besides the VM) is its focus on classes. I should clarify that I haven't written a single Java program to date (I was going to start my homework tonight, but...)

My explicit code was a disaster; I had gas blobs moving through each other and through the projectile. .

One other thing account for would be changes in gas properties over pressures and temperatures. It is worth noting that 2d axisymetric will not be directly compatible with any bends.

Well, if you haven't written anything in Java then I guess I'll start in Python as I know it can handle what we need, I know it reasonably well, and it's not too hard to pick up if you know other languages. (This is "you" in a general sense.)

It sounds like you might have used a time step that was too large. I had some similar problems, but I blamed them on a typo or multiple typos I didn't find in the few hours I spent on the code.

Variation of the properties with temperature is on the list for future releases. I don't think variations with pressure are very significant for our purposes, but I'll take a look at that again. The first version will use a "calorically perfect gas". This basically means that the specific heats are constants. I do intend to eventually add other gas property models, but things are already rather complicated right now and I'd rather get the basics down first.

This week I am going to try to finish a document listing all the equations I'll need with some pseudocode to help me get the ball rolling. I'll post the document here for feedback. I'm sure someone will have some good ideas or corrections.

Also, does anyone have any good ideas for the program's name? I'm going to go with LGGS for Lagrangian Gas Gun Simulator as that's what I called my older Lagrangian code, but I'm open to suggestions.