How often do you use of CFD (Computational Fluid Dynamics) ?

Excellent to have numbers in this discussion, Wet Feet. What precision is required, in theory, for CFD to correctly capture a boundary layer around a 65' trimaran, together with the water to air interface, and inside a domain of computation of a sufficient size for interaction with the boundary walls to be negligible ? Even with submesh approximations functions -which are, may I recall, only approximations made by the software developpers to be smooth and continuous, but are not guarantee to represent correctly a true boundary layer -, I come with numbers around 150 M, that can be cut to 75 M by symetry if there is no transversal component of the incoming flow velocity in the scene. It must be noted, that, in comparison with the size of a F1 and the 30 M count, this number of 150 M is quite small, and is, in any cases, unsufficient to obtain results with the precision awaited in the F1 case. But, in the small nautical projects I've worked on, I was never able to justify the amount of $$ required to make any 150 M elements simulations. This number is lowered to 5 M to 10 M, in order for the computations to be executed in a "not so long time" : One week is the maximum of time I've ever been able to sell, preferably 24 hours....

What can be achieved, then ? A CFD that can be roughly compared with statistical and analytical formulas, that satisfy the client when the results are almost the same as the ones the NA has calculated in 3 minutes, and when, at random, some unexpected, but explainable phenomena give a little suspense and tension in the design loop, but not too much. One or two extra meetings can be scheduled with the client, one or two opportunities to justify the wise choice that has been made in incorporating CFD in the studies. Am I the only one that has this kind of experience ? Take the paper hereby attached, published by the venerable RINA, and find the number of element that has been used, not only to compute one case, but to perform the whole optimization of a 250m vessel : 1 M elements. What considerations should be given to this study ? Let the authors of this study speak for themselves :

"Both CFD codes are used in the same manner where only the pressure resistance from the computation is used while the frictional resistance is based on the ITTC 78 model to full scale correlation line. Although it may appear as a paradoxical in a context where viscous flow simulations are used, this method which does not use the CFD calculated frictional resistance has been chosen because it is very difficult to compute a frictional resistance at full scale."

If I mostly agree with this remark, why on earth NS simulations @ 1M elements have been performed, if the frictionnal resistance is to be estimated finally by an ITTC formula ? How far a rough panel code with 500 elements will be from the final results of this study ? Isn't it a good example of how to through good money after bad ?

 

Having commissioned a sailboat design myself, that is a THE great question. We did use Dave Vacanti’s services for the foils, which was worth every penny- no spin outs, great tiller feel, always smooth, climbs to weather like an banshee, and never a vibration.

I wonder if the team that came up with the AC Hula has ever spilled the beans about the design tech & time for that?

I had a Tiga Pro - that board was so smooth rail to rail when gybing, but you had to commit in a huge way- when she got in a groove, she just wanted to stay there, going faster and faster. Made your eyes bigger and bigger. Then you had to convince her that getting out of that stable equilibrium to a stable dynamic (like turning) was a good idea, and then more seduction to get her back to going straight. Did close to a 360 a few times before I got the knack. Amusing board. There is something to be said for real size testing.

 

Because it fixes a defect in the code it is not throwing good money after bad. The correct term for some CFD code (mainly in the '80s, and '90s though some persist to today) is "RANS": Reynolds-averaged Navier–Stokes. RANS works well in aerodynamics where initial turbulence can be small compared to a seaway. The need to quantify the turbulence entering the boundary leads to the "self licking Ice Cream cone" problem I described... If you want to go down that rabbit hole, I recommend the following thread.

Skin-Friction Formulas https://www.boatdesign.net/threads/skin-friction-formulas.31280/

 

You're absolutely right, Jehardiman. So, if you throw away the skin friction, what is left in the computations ? I quote : "Both CFD codes are used in the same manner where only the pressure resistance from the computation is used". Only the pressure resistance.... So again, my question : Couldn't a 500 elements panel code obtain similar results, consumming less than 0.0005 times the CPU ressource that was used ?

My remark about "the simple keel bulb drag calculations" was not so innocent. Especially because of the shape, it is extremely hard to predict its skin friction coefficent, and so, monumental errors are made using traditionnal RANS CFD. You have to use boundary layer codes, with specially taylored asymptotic functions. These codes are not available in the Naval Industry, but are, generally, confidential "Aerospace Defense codes", that only people with special clearance have access.

That's why the authors of these articles, very honestly, wrote that "it is extremely difficult to determine the friction drag accurately". Using 1M elements with a RANS code, just to remove the frictionnal contribution in the end, does not sound to you like, having paid for a Lambo, removing its V12 engine, and replacing it by a 4 cylinders 1.6 DCI ? What would be the difference, in the end, with a regular car, fitted with the same engine ?

 

Depends on the shape and speed...fully submerged body of revolution?; yes, as I have accomplished pretty much that in some code I've written....fully appended winged keel sailing vessel with leeway?...you are going to need more. In some cases skin friction predominates, in other cases it does not. As has been stated before: there are lots of tools in the toolbox, select the correct one.

 

Since all calculations by necessity are simplifications of a complex reality, why should we not use "benchmark inputs", fi empirical values (or starting values) for a variable like friction to "tune the iteration process" if possible? Because the strictly theoretically inclined mullahs regard it as cheating? It is my professional duty to use all relevant information to produce the right quality required for the purpose. Neither higher, nor lower, but right! And I judge the relevance from the difficult-to-define capacites of mine; competence and experience, which is what I get paid for.

Just as we check our navigation progress at sea against known positions and markers, even when navigating by "dead counting", it is often possible to find realistic check points during the execution of a flow simulation.

 

Oh yeah.

Edit: I particularly enjoy @jehardiman 's turn of phrase, because he has employed that same tool to help me past a difficult point. Generous teacher that guy. Understands different students have different learning styles.

 

They both would run, at least, but one would look very sexy….

 

And 'sexy' sells. I have seen a few multi-million dollar projects sold on a "sexy" powerpoint presentation. One contractor <nameless> actually had a graphics department just for this.



EDIT to remove hyperbole...bad engineer, no cookie!

 

I picture Oscar Peterson, standing on a Bösendorfer, like Chuck Berry assaulted by the police forces during its mythical concert !

My elder son is found of "electrical" music, , numerical or analogical. I play sometimes on one synth that he has, with a "Grand Piano" register, together with a very incredible "touch" management (dynamic sensors, after touch effects + extra signatures in relation with the touch, but no "heavy" touch feeling, more like an organ touch, it's just a master keyboard). This grand piano sounds lke a Steinway D-274 , in my small room, when adjusting reverb. Add a little compression, and you've got the very nice and strange feeling of a high quality sound coming out of 5kg of plastic, silicium and metal. But everytime I hear some piano music, walking on the street, I can tell if this music comes from a true instrument or is synthetized. I'm do not really understand this. It may not only be the sound itself, maybe the interaction of the sound will the walls, with windows, with the air, that is different.

I really like this image.

This would be the Holy Grail ! To truly achieve that, my guess is that efforts should be put in the "D" of CFD. Perhaps has Baekmo, with his work on rotative machines something to say about this ?

 

Cannot resist in publishing these exchanges, seen on Breizhskiff.com. Here is a guy, -let's call him Bob, doing some CFD calculations in order to built an hydrofoil for his skiff. ( By respect, True pseudos and Brand names have been modified).



... I hope he has not paid a cent for the software suite...

 

About the self licking ice cone problem (SLIC), I came accross this picture on Google Eartg, when preparing a travel to a distant country. May be an AIRBUS A320 from Air India. In this view, we can see how the section area is diminished in way of the wings and at the tail. An optimisation has been performed to reduce the parasitic drag, and the SLIC issue has been avoided, introducing external parameters in the fitness function. Like a minimal area for the seats and the equipements to fit into.

In other words, optimizing any shape by CFD with only aerodynamics parameters, potentially leads to SLIC. If you want to minimize the drag of an apparatus, the trivial answer will always be : skip the apparatus. No apparatus. No drag. Computers are very handy, but not very clever I guess.

 

Hey Alan,
I'm wondering if this plane is thinner at the wings (as you mentioned if I understood you correct) or if it's just an illusion. I guess the latter. The plane is heavily overexposed in the picture for example.

Why I really came to this thread:
You seem to be well know to (computational) fluiddynamics, you cannot only produce nice images but also read something from the achieved data (re your ac75 thread). Which software do you use for the simulations? I am still a student but would like to dig into CFD. Maybe you can provide some information on where and how to start?
Greets

 

Not the best picture, I agree...

Fluid dynamics is a great subject, although seen as difficult to grasp since it covers a very wide range of phenomenon. Those occuring at high enthalpy, like in astrophysics, are the most complex of all. Mathematics in fluid dynamics are quite heavy in general, and experiments are very complicated, but both are fundamentals to understand in order to go to the "C" of CFD. As in every field of knowledge, the context and the assumptions of any model or theory have a great influence on the interpretation of any calculations. So, to me, the very start in getting into CFD is a solid background in mathematics, a patient study of the main theories and related experiments. Regarding your particular interest, some people on this forum and I would certainly be pleased to suggest some references.

Which software do I use ? In the past, I used a lot of different software. Some were research codes, other commercial codes. For now, here are the code I use the most :
- DualSPhysics : Multiphase newtonian code. Very versatile, it's a GPU accelerated code that I use to simulate hydrodynamic resistance of boats. It's a free research code that has many bugs and flaws, but I have used this code for more than 10 years by now, and compared its outputs with on the water test campaigns. It's a meshless code, which gives an excellent robustness, but requires a tremendous computing power, and I'm currently limited to the simulation of 24 meters boats. As a side note, I'm developping also a methodology to use this code for stability calculations, especially focusing on the inverted stability of multihulls and on damaged-stability.
- Fluent : Multipurpose eulerian software than I use since I was a student, mainly for aerodynamic calculations, but it also comes with VOF models. I use an old version of this software, and I'm looking to replace it by OpenFoam, in order to get a more straightfoward integration with my operating environnement, that is more and more Python based. Since I've got a relatively good confidence on my knowledge of the limit of Fluent, for my applications, I use it mainly in double check of simpler and quicker methods.
- XFoil : Should I introduce it ? I use it alone, to test and optimize some profiles, but also embedded in in-house lifting line codes, so called "2D 1/2 codes". Very fast, very versatile, full of usefull tools to work on 2d profiles, its stability is also very problematic. Nevertheless, because of its wide use, validation and batch mode, it's an un-avoidable tool.
- AVL : Developped by the MIT for aerodynamic and flight-dynamic analysis of rigid aircraft of arbitrary configuration, it is developped originaly from a NASA code by many scientists, including M. Drela, the author of XFoil. It has the same versatility as Xfoil, and is able to output the dynamic system matrices that can be fed into any 6DOF integrator to simulate complex maneuvers of airborn foilers and assess flight stability. Very precious for the design of foilers.
- In house codes : Lifting line, Doublet lattice, developped from scratch and validated using APAME-ACS, for which are available their Fortran and Matlab code. Since I'm moving from these environnement to Python, Jupyter and JSON, i've started re-coding these in-house codes.

I choosed these codes because of their intensive validation, and because there are, as such, a lot of publications available. I stick to them for a long time, to gain experience and confidence on what I can do and what I cannot do. I shall also evolve with mainstream, and I've started investigated OpenFoam. Although it's an eulerian code, ie very subject to mesh burden and sensitivity, this code is also widely used today, a lot of validation is available, and very complex methods can be used, like Adjoint Based optimization methods, all packed under the same distribution. Quite handy. The AC75 calculations have been made using OpenFoam, for me to get my hands on this code. I think that it's a very complete and affordable tool, that could be very interesting for you.

For what application do you intend to use CFD ? With which programming environnement are you used to ? I would be interested in sharing some codes if you could also share some developments made out of these codes.