Having failed on my other forum, I turn to the vast and deep font of knowledge that is Dopers! I aplogize for not asking you first. I just thought they would know.
They didn’t.
What I seek is probably over my head, but I’m looking for gas/fluid modeling software.
More specifically, something that can show turbulence over or through a given surface or boundary. I’d like something that may show/predict pressure in a given vessel.
Basically, I’m looking at gas flow through a silencer/suppressor.
You might look into something called Gensym. It’s quite powerful software although setting up a model or process can entail quite a learning curve. I used it for setting up and modifying business processes, i.e. simply enforcing the correct sequences and preconditions for jobs to be run. But I was interested to note that some of the examples used in the tutorial involved actual material processing, like petroleum products moving through a refinery. I know nothing of fluid dynamics, but I would think if it involves modeling the behavior of fluids in a system based on their quantities, you could make it work.
Fluent is a major player, with lots of academic and industrial users. But my experience with it about 5 years ago was pretty bad. It had lots of bugs and numerically inaccurate formulae, and its scripting language is a study in perverse frustration. It truly left me baffled what other people were using it for, and left me thinking that most of its users were probably getting nutty results without knowing it.
SolidWorks is a popular 3D design and modeling software used by many mechanical engineers, and it contains a CFD module for simulating flow through the open spaces between the solid bodies you create in it. We did a few comparisons between this and empirical Nusselt correlations that appear throughout the literature, and found it was typically quite close (Fluent was many times further away from the literature values). If you’re into the details, it uses a kappa epsilon turbulence model.
Yeah, I’m serious. Since you asked - no, make that “In spite of the fact that you didn’t ask”, a kappa epsilon model exploits the Bousinesque hypothesis that momentum transport in turbulent regions can be modeled as viscous momentum transport with an artificially inflated value for the viscosity, so that the macroscopic effects mimic turbulent effects but on the scale of the finite elements or volumes in the analysis there is no turbulence. This makes the problem practically calculable. Kappa is a representation of the turbulent energy, and the viscosity is some steep function of this (a power law maybe but I forget). Epsilon is a representation of how quickly the turbulent energy dissipates or how long it lasts (I forget which, but there is also a kappa omega model in which it’s the opposite).
I don’t mean to be flip or patronizing when I say that if you don’t know the answer to this you’re not going to be able to use the software effectively, or assess the results. Setting up and running computational fluid models and getting reliable results even when you are assuming frozen, subsonic, non-turbulent flows. When dealing with the highly turbulent combusting fluid like burning propellant there are a whole host of interior ballistics considerations to bring into play. (Once you understand these conditions you can make some simplifying assumptions, but the software won’t do that for you.)
To answer your question, I believe that SureFire used Metacomp CFD++ to design their 5.56mm and 6.8mm silencers which are noted for their performance and compact size. This is far from cheap, nor easy to use, and requires a preprocessor do create the mesh and boundary conditions, and a visualize for postprocessing. I agree with Napier that, in my limited experience with it, is a crap code. FlowWorks isn’t much better for the regime the o.p. is working in.
Oh, I know I’m stepping into the deep end here, but I’m a whole lot smarter than I look, so I’m not afraid! I am reading what I can, but frankly the biggest changes since Maxim’s days are the materials.
I think I have some sound ideas (HA!) on making supressors much more efficient, but as with many endeavors, money is the key.
Turbulence and phase-cancellation are my 2 biggest goals.
I just need to see if my shapes do what I think/want them to.
Not really. The materials haven’t changed much; steel is still used as the housing, albeit using high temperature alloys to permit extended firing. What has changed is the elimination of consumable components like wool or glass damping, leather wipes, and so forth that can distort the flow field as they wear and have to be replaced after a limited number of shots. What has changed, as you allude to, is the use of testing and analysis to make silencers more efficient and accurate, including using cancellation of shock waves to slow the expanding gases to subsonic exhaust speeds.
I don’t doubt that you are a smart guy, but understanding how to apply CFD and turbulent flow models is more than just cracking a couple of textbooks and grinding calculations through the software. When I say that this is something of a black art, I mean precisely that; even people with Ph.D.s and decades of experience in the field of aeroelastic modeling put uncertainty factors of 30-50% on uncorrelated CFD results. You can’t just dump CAD geometry into a preprocessor, mesh it up, send the input deck to your solver, and get meaningful results.
RealFlow is a discrete particle physics modeler and rendering package; it basically assumes a large number of solid particles that make up a liquid phase viscous fluid. (I see that their “Hybrido” engine uses a combination of discrete and continuum mesh methods, but not at a level of fidelity even approaching the ability to model small scale stresses and behavior.) What the o.p. is looking for is something that uses a variable continuum mechanics approach using some variation of the Reynolds-averaged Navier–Stokes (RANS) solutions. Basically, you look at the fluid as being made of a matrix of rubber bands that are all attached to one another and whose modulus and momentum properties vary in orientation, and across very small discrete timesteps. It is similar in concept to finite element analysis of solid structures, except with solid materials we don’t have the mesh flying around with wild abandon; even “large displacements” are relatively small deformations of the mesh, and the mechanical properties of the elements vary in a predictable fashion even in rate-dependent hyperelastic materials and high strains. CFD is many orders of magnitude more difficult. There are methods that use discrete particle interation, so-called direct simulation Monte Carlo methods, but they’re used only in regimes where the particle density is very low and the continuum mechanics methods used in CFD no longer provide accurate interactions.
Hey, Stranger, you sound like my kind of guy. Tell me something - is there a CFD package you can recommend for me?
My interest is air flow and forced and free convective heat transfer. I’m interested in dimensions from a few millimeters to a meter or so, velocities to maybe 20 m/s, temps from room temp to maybe 500 C, and atmospheric pressure. I suspect that practically I care about incompressible subsonic flow and am looking for turbulence models implemented in code.
My taste in software is for text in and text out. I want to do parametric studies. I don’t mind having to use a separate mesher. The furthest I have gone in the past is to combine Fluent and Gambit with other code I wrote to automate an iterative fluid structure interaction problem similar to a flapping flag; I wrote both the code to deform the structure according to the CFD output pressure profile, and the code to repeatedly call sessions of Gambit and Fluent to calculate the new flow field with the iterated structure geometry. I did make all this work, but gave up because the bugs and errors in Fluent so inhibited progress that it wasn’t worth the effort. Fluent invited me to write a paper about the project for their magazine but wouldn’t promise to publish it unedited.
I use FLUENT. It’s better than (it sounds like) it was five years ago, but it’s not something that I’d say is great. It’s pretty expensive, and there’s a fairly steep learning curve attached to modeling anything more complex than a 2D rectangle. At least one of Napier’s concerns has been alleviated - all the scripting can be done in C++ now rather than a proprietary Ansys syntax. Still, it’s not something I’d recommend for a one-off application - I think you’d spend a whole lot more time learning the software than modeling your ideas.
In fact, I think that’s true of pretty much any CFD package. Is there a research university near you where a faculty member in mechanical engineering (or civil engineering, or math - it’s not always easy to guess who would be doing this kind of work) might be interested in doing it as a consulting gig on the side?
Napier, a colleague of mine has been working on a collaborative open-source finite element software for the last couple of years. You can get general information about the project here, and the 3D details (such as they are) are here. It uses an adaptive mesh and an adaptive time step, but also varies the degree of the approximation to improve the efficiency of the calculations. Text in and text out are available, and you can set up the mesh using either their own mesh editor or by text. I don’t know a way to efficiently deform the mesh between timesteps, but it sounds like you’re pretty comfortable writing code - it’s all based on a C++ platform.
I’m not sure how much is available right now on the 3D side, but it might be worth checking out.
Just to be clear, I’m not a CFD/aerothermal expert by any stretch of the imagination; I’m a structures guy who knows a little about interior ballistics and some basic thermochemistry. Aside from some fairly simple fluid structural interaction using ADINA, my exposure to CFD and aerothermal analysis comes from taking the results from the CFD wizards and converting it to something the average intelligent person can comprehend. We use Metacomp CFD++ with good success, but that is for highly turbulent transonic and supersonic multiphase flows; probably overkill for what you are looking at. I see Fluidyn being used quite a bit by other groups we interact with. I see COMSOL on a lot of resumes, but I don’t know anyone who has used it extensively. The problem with making comparisons between solvers is that most analysts have only used one or two codes and haven’t done a lot of benchmarking and comparison, so it is hard to gauge how much of their preferences are based upon real deficiencies or advantages of various codes and how much is just knowing what they’ve been exposed to. However, I have one fluids guy who used Fluent in grad school and had a similar experience to yours. There are a large number of open source CFD codes out there, and if all you have as time you can try some of the more promising ones out, but as with Fluent they all have fairly steep learning curves. If they’re anything like structural/thermal FEA then most of them are incomplete or severely buggy, but I’ve heard good things about OpenFOAM. I would look for one that uses C++ or Python (or whatever coding language you’re used to) for scripting rather than a proprietary format.
I, too, like to go in and be able to hand edit input decks (finite element in my case) as well, but the improvement and proliferation of meshing and preprocessing tools available today really makes this almost unnecessary (though I do think there is value in understanding the format that the code is reading as preprocessors can still be buggy and screw up a deck in a way only someone knowledgable about the formatting can debug). We use Gridgen for CFD meshing and preprocessing, and Tecplot and Matlab for visualization and postprocessing, though I’ve been trying to get users to try using Gnuplot and Scipy, so far without success.
Doing parametric studies with a text input deck should just be a matter of either using some kind of app like HyperStudy or ASCEND, or just writing some scripts to generate and batch submit a bunch of decks, which sounds like you’re already doing. I tend to prefer the latter using Python just because it is easy to understand what the script is doing, there is a good collection of support libraries to do statistical variance and ANOVA studies, and frankly my scripts are more robust than the encapsulated tools that all seem to be a little buggy. (I see that someone is porting or rewriting ASCEND into Python and PyGTK, so maybe that’ll make it a little more transparent.)
I’ll check in with my CFD guys after Christmas and see if they have any further recommendations, but as I said, analysts are typically familiar with the couple of codes they’ve used and know only semi-informed scuttlebutt about other codes.
I’m not too worried about fluid structure interaction - I have one problem that calls for it but most of my needs don’t. I also suspect that FSI simulation is difficult enough that physical experiments would in my case be more practically efficient. I’m also not too worried about a learning curve, if I have good reason to trust one system and learn it.
For me, the big issue is bugs. Malfunctions inside someone else’s executables can be pretty impossible to work around. The second priority issue is the ability to script things, because I’m too error prone to pull off a parametric study with point-and-click software.
