|
[Sponsors] |
November 30, 1999, 18:39 |
Can we quantify the fruits of CFD?
|
#1 |
Guest
Posts: n/a
|
Once again, I find myself writing a research proposal asking (begging) for $$ to do CFD development and analysis for those not familiar with CFD. As I begin the paragraph in the introduction that trumpets the general benefits of CFD design tools, I find myself (once again) limited in both general knowledge and specific examples of CFD payoffs. So I thought I would post an inquiry to the group to see what insights and success stories exist.
Here is my take: Two benefits are generally highlighted: (1) Reduced design cost and (2) design improvement. In regards to the former, I have heard that CFD analysis is generally one-tenth the cost of experimental analysis. I think I have heard this figure in context with aerospace/auto applications. Does this sound right? What is the general cost ratio for your field? In regards to the latter, quantifying the improvement in design is even more application dependent. Are there enough examples in certain applications to make a statement like "I expect CFD analysis will improve the design by X percent over baseline technology"? Does anyone have any CFD Hall of Fame success stories that they were involved with or that they recall hearing about that quantifies either of these two benefits? Much thanks, Brady |
|
November 30, 1999, 20:03 |
Re: Can we quantify the fruits of CFD?
|
#2 |
Guest
Posts: n/a
|
An interesting paper may be related to your topic.
Antony Jameson, Re-Engineering the Design Process through Computation. AIAA-97-0641. Zhong |
|
November 30, 1999, 20:47 |
Re: Can we quantify the fruits of CFD?
|
#3 |
Guest
Posts: n/a
|
(1). You are apparently looking in the wrong direction. (2). The CFD was born in the name of "national security". (3). The cost reduction, and product improvement can't be used to justify the existence of CFD. (4). In the market place, the cost reduction can't survive. It is like creating an automatic assembly line to lower the cost. The cheap labor cost is available world wide. The cost reduction means no jobs here. (5). The product improvement means higher cost of the product. Remember, the PC gets more powerful every year, and at the same it costs less and less. Why? Becaue everybody pitches in, to buy the computer, to learn how to use the computer, to promote the use of the computer. This in turn helps to lower the cost and the improved quality. When people stop using the computer, the cost of PC will become higher and higher. (6). The CFD field requires the super-computer class power. So, it is not cheap. It also requires the best trained scientists and engineers, and this is not cheap either. (7). I think, over 90% of CFD population does not even appear on the CFD forum at all. They are always behind the government laboratories, research laboratories, research department of large companies, etc. (8). From my opinion, the need to do CFD is the same as the need to keep a group of highly trained scientists and engineers, for the survival of the country. It is the invaluable brain working in CFD problems which can not be measured by the cost reduction and the product improvement. (9). For the achievement and the importance of CFD, look behind the doors of the government laboratories.
|
|
December 1, 1999, 07:12 |
Re: Can we quantify the fruits of CFD?
|
#4 |
Guest
Posts: n/a
|
You could take a look at the U.S. Department of Defense High Performance Computing "Success Stories" at:
http://www.hpcmo.hpc.mil/Htdocs/SUCCESS/index.html. (The report is an Adobe Acrobat document) The projects listed under the two topics of Computational Mechanics and CFD have a short "Significance" summary, which may help you in terms of specific payoffs of CFD. Only a few of the projects cite hard numbers, but you might get some ideas to include in your research proposal introduction. |
|
December 1, 1999, 10:19 |
Re: Can we quantify the fruits of CFD?
|
#5 |
Guest
Posts: n/a
|
your post highlights a continuining deficiency in engineering education which most of us (myself included) suffer from. the deficiency is the inability to analyse the economic costs/benefits of our activities. by perusing your companies homepage i see that you have developed some advanced CFD tools for relatively difficult problems. a good way to quantify the economic benefit of using cfd would be to total the cost to your business of doing cfd analyses last year (or over any past time period) including money spent acquiring hardware, software (including cost of in house development), be comprehensive include employee cost (i assume you bill hourly) etc and compare this to an estimate of how much it would have cost to perform those analyses using experiment including all the above categories. you can also compare the time taken to perform the analyses (include pre and post processing of course) to the time it'd have taken to perform similar experiments. i think you'll find that cfd is very cost effective. moreover there is the point that CFD can be used to obtain results/data that would be very difficult/impossible to measure.
|
|
December 1, 1999, 11:32 |
Re: Can we quantify the fruits of CFD?
|
#6 |
Guest
Posts: n/a
|
In my experience the use of CFD often results in a reduced design cost that is hard to quantify, but does not always result in lower manufacturing costs. I have used CFD in three broad catagories of jobs: 1. To test concepts early in their development, 2. To refine concepts that will eventually be scale model tested, and 3. To fix something that slipped through the first time.
I (unfortunately) can't be very specific, but, I'll try to give some examples: 1. I spent 6 months working on some very conceptual pump-jet designs. 15 years ago the development program would have built 1 or 2 proto-types of promising looking designs and tested them. In those 6 months I was able to analyze a dozen possible configurations. The new design didn't look very promising, and was tabled pending further innovation (the concept sucked, but that was just my opinion). The use of CFD save money on hardware that didn't need to be built. 2. The industry I was working in routinely relied on scale model testing to give the customer the ultimate warm, fuzzy feeling about the finished product. Previous designs would often require several series of tests to refine the shape of the body to insure clean flow under a variety of conditions. Our goal was to use CFD to the point where the first set of tests would be satisfactory, and eliminate additional testing. We succeeded and one set of tests was sufficient. There was some cost savings because the engineering/computer time was less expensive than 2 additional sets of tests. 3. On occation, a system would be deployed that would result in flow problems that hadn't been expected. Because a test takes a while to perform (between fabricating models, and arranging the use of a test facility), CFD was use because of the possibility of fast turn-around time. I can't say that CFD was less expensive in this case, but it went from start to answers in about a month. Alton |
|
December 1, 1999, 16:23 |
Re: Can we quantify the fruits of CFD?
|
#7 |
Guest
Posts: n/a
|
To quantify the benefits of CFD is often difficult, but not impossible. When you talk about "fruits of CFD", you have to have something to compare with. Most of the time, we are probably comparing CFD with experimentaion, interms of cost and time savings. In terms of product development, my experience is that CFD could potentially achieve three things, 1) to reduce the number of prototypes built 2) to reduce time to market, and 3) to gain knowledge otherwise not attainable. I have had some experience in simulating turbulent flows in complex geometry under high pressure. The geometry was 3D and enternal, pressure as high as a couple of thousand psi and with major parts rotating. This is where the experimental approach would be hugely expensive. But with CFD I obtained very useful results and the company benefited greatly.
|
|
December 2, 1999, 09:43 |
Re: Can we quantify the fruits of CFD?
|
#8 |
Guest
Posts: n/a
|
(1). It was very unfortunate that computer was not invented a couple of hundred years ago, otherwise, many new inventions would probably have invented through the use of CFD. (2). For example, the airplane was invented by experimental approach, thus it set the tradition of the wind tunnel testing. (3). This strong tradition is like four thousand years of Chinese culture, is going to take the equal length of time to change. ( why?, people read history books. ) And I don't think it will change at all. Why?, because the development of human history and the technology is initial value problem. What has happened is now distributed in space and time. It is too late to change. (4). To preserve the culture and the accomplishment is to write the history book and to read the history as well. The new trend will begin only when the old trend dies. And no one would like that to happen to his skill, his company, or his country. (and in many cases, people even try to save the endangered species) (5). I think, the technology is just like the culture, it is something one would like to keep. And the only way to keep it, is to use it and to promote it. (6). Like the culture, the religion, the promotion will find itself in conflict with its environment one is living in. And likewise, the promotion of CFD will have direct conflict with the experimental approach. But, I think, this is not necessary. (7). If one can increase the sale of a product by a factor of two, the development cost will be shared and thus reduced automatically. So, it is the sale which is more important in business. If the sale is zero, you don't have the cost, you have chapter-11. (8). If the sale is not zero, a Swiss watch company producing only one watch per month can manage to survive. (9). It is the sale of a product which determines the fate of the technology, the company, and the country. The cost and the quality is all very relative (to the sale), the promotion of the cost and the quality concept can only create more conflict within the object itself, unless there is a clear indication of the sale increase. And it is likely that the sale is more or less related to how the product is advertised.
|
|
December 2, 1999, 10:34 |
Re: Can we quantify the fruits of CFD?
|
#9 |
Guest
Posts: n/a
|
I'm going to have to disagree with John on this one. The use of CFD is going to become an integral part of the design process, and probably within the next 20 years.
Sure the Romans built aqueducts from stone that included arched bridges, and they've been around for over 1500 years. Sure the pyrimids have been around even longer. However, there are 2 points I'd like to make: 1. We don't see the Roman bridges that collapsed, and the pyrimids that came out lop-sided and fell over. 2. It took a great deal of trial and error to get it right. I like to compare CFD to FEA. In the 1960's only a small handful of people who had access to large quantities of the government's money and really powerful computers (at the time) were using FEA. Who's using FEA now? The majority of engineers that are designing a product are taking advantage of FEA, and those who aren't, want to. When I got first got involved with CFD in the early 1990's, the scope of usage was much like the use of FEA in the 60's. Government contractors, and some large companies were the primary industrial users. The use and acceptance of CFD analysis is growing and spreading into new industries. It will continue to grow for the same reasons the use of FEA grew. CFD analysis that is performed up front leads to a better, and potentially less expensive, product. It may not save design cost (although it might if it is used as an alternative to testing), but it can lead to increased sales. With a consumer product, that increase in sales can more than make up for design cost increases. |
|
December 2, 1999, 12:00 |
Re: Can we quantify the fruits of CFD?
|
#10 |
Guest
Posts: n/a
|
(1). It is very interesting. At the place where I am working, they have just eliminate the design function and department. (2). I don't think in 20 years, CFD will be the integral part of the design process. (because the place I am working now has no design function at all) (3). In terms of trial and error approach, I have in the last month alone tried several hundred mesh configurations just to find out whether I can create fine mesh near the walls. It is still not working yet. So much for the trial-and-error approach. Even outside the main loop of CFD. (4). There is no relationship between FEA (structure analysis) and CFD (fluid analysis). If there was a relationship, then the vendors of structure FEA codes would be the leading vendors of CFD codes already. At least they have 20 more years of experience ahead of everybody. Just ask a structure engineer to write a CFD code, then you will find the answer quickly. (5). I don't think that more people are using CFD approach. But I do believe that more people had attempted to use CFD approach, but were unable to get the right answers. (6). Are you sure that the CFD solutions you are getting were correct?, while I am still trying to find a way to create a fine mesh. "seemingly correct answers from CFD codes are likely to be the wrong answers, if one is not very very careful in the validation of CFD solutions". Why do I need a fine mesh? Because we could not find the needed features in the coarse mesh solutions. (7). Without expert help, I think, many companies are getting wrong CFD solutions. And when the design gets into production, sooner or later, they will know that something is wrong. (8). Most people are using 32bit workstations using single precision math, which has been proved to be inadequate for scientific calculations long time ago. That's why super-computer was developed to handle 64bit or 70bit math. So, if you are using single precision math in CFD codes, it is not going to last very long, I guess. If you are getting funny solutions, try the double precision first. But, that will easily double the memory requirement right away.(9). In the name of cost reduction, it is easier to write your own code. In this way, one can save the license fee of over ten thousand dollars a year? Then at that point, there is no commercial CFD vendors, no commercial CFD codes, and very little CFD left, I think. (10). By the way, it is still very difficult to integrate the CFD in the design process. The CAD geometry and files are not CFD geometry and mesh friendly yet. The problem is still outside the CFD solver. It has not touch the CFD yet.
|
|
December 2, 1999, 13:17 |
Re: Can we quantify the fruits of CFD?
|
#11 |
Guest
Posts: n/a
|
By the numbers:
1 & 2: Granted, it's difficult to integrate CFD into design when there is no design, however, in most cases the ultimate goal (whether you do it, or someone else does down stream in the process) is to design something. 3: But once you get a technique that works, it will work for many different part designs. Sometimes the first mesh is a (for lack of a better term) pain in the tush, but the next is much easier. If you want to get me a soap box, I'll complain at long length that the thing that currently keeps CFD out of the main stream of design is the mesh. To paraphrase: Find me a code that generates the mesh I want, quickly, easily and consistently, and I'll analyze the world. 4: I never meant to imply that the physics or techniques are the same. I do, however, think that looking at the history of the development of FEA, and how it has gone from the fringe of the design process to being an integral part, is like looking at a map of CFD's future. Use and acceptance will come as tools and techniques improve. It has happened to FEA and will happen to CFD. 5: I agree that the problem with getting good answers in CFD analysis often lies with the "nut behind the wheel." The analysist needs to know what he's doing. In that sense it is a bit like FEA. Anyone can get the wrong answer. You've got to know what to do to get the correct answer, and you have to know enough about fliud mechanics to tell if things look right. 6: Many people don't know who wrote the code they are using, and don't know what questions to ask. The first (in my mind) is 'What is the maximum y+ I should have at the wall?' I've generated meshes with y+ at the wall on the order of 2 and gotten some absolutely beautiful results. They took a while to run, though. 7: See #5. Most problems in both CFD and FEA are caused by the 'nut behind the wheel.' FEA (to some extent) has had 2 decades to build artificial intelligence into mesh generators and solvers to take out some of the opportunity for human error. Given time, CFD codes will probably get there as well. 8: As the hardware improves (which it will) the solvers and answers will also improve. 9: I agree and disagree. It takes a different kind of person to write the code and run it (in general). I think that big companies can afford a couple of developers to write and maintain a code, and different people to use it. For a small company, 1 developer can't match the innovation and improvement of an independent supplier that has a development team. If you end up with a couple of entrenched developers, their salaries can easily exceed license fees. 10: On this we agree completely. I need a very robust way to transfer CAD geometry to a CFD package, identify the "wetted" surfaces of the CAD model, add other surfaces that the analysis needs (inlet and outled boundary surfaces for example), assign BCs and ICs, and mesh the thing with an adequate mesh. I have seen prototypes of this Holy Grail, but I don't think anyone is there yet. (I once said that I wished for an interface in the back of my skull so that I could think really hard about the mesh and have it appear on my computer screen. We're certainly not there yet.) CAD interfacing and grid generation are the keys to integration of CFD into the design process. If it takes 2 months to generate an acceptable mesh on a complex part, no one will use CFD. If that time could be reduced to 1 week, then the technology becomes useful. |
|
December 2, 1999, 13:45 |
Re: Can we quantify the fruits of CFD?
|
#12 |
Guest
Posts: n/a
|
(1). I think, the purpose of the discussions or the forum is not in the disagreement in thinking or presentation, but in trying to bring out first hand experience in the troubled areas. (2). If you say " I'd like to have a mesh which can handle a 3-D problem at Re=10,000,000, and the first mesh point must be located at Y+=1.0 from the wall.", then, it would be very interesting to know how many codes can pass this test today.
|
|
December 2, 1999, 14:16 |
Re: Can we quantify the fruits of CFD?
|
#13 |
Guest
Posts: n/a
|
On that particular point, I have used GridGen, and a lot of patience. The Reynolds Number was lower (on the order of 3.5 million as I recall). The problem is, of course, the amount of time and effort such a grid requires to set up, and a grid that fine will run for a while on a Cray.
We haven't reached Nirvana yet, but we will. (I'm an optimist. The glass is slightly more than half full.) |
|
December 2, 1999, 15:12 |
Re: Can we quantify the fruits of CFD?
|
#14 |
Guest
Posts: n/a
|
(1). What I was trying to say was: for a Reynolds number of 10,000,000 based on one inch length, the estimated dy at Y+=1 is about dy=0.0000028 inches. (2). And if the wall is located at a radius of 20.0 inches, the first point away from the wall will be located at 20.0000028 inches. (3). This number can not be represented accurately by the single precision math which has around seven places of decimal point accuracy in the scientific notation. And even if one makes it like 1.0000028 inches, the single precision math is still not accurate enough. (4). It might not cause obvious problems (because the computer will grab some arbitrary numbers and attach to it), but if you check carefully, you will see the difference. (5). Now if you drop the Reynolds number to Re=100,000 (which may be very common for some applications), then the first dy will be equal to dy=0.0002 inches. The first wall point will now be located at 20.0002 inches, or 1.0002 inches. In either case, the single precision math will be all right. (6). This simple problem may not be obvious to many CFD code users, because they normally don't care about the code's precision. The problem will show up, only when the code starts producing negative cell volumes or something like that. (7). The math is very simple here, anyone can easily double check the results. (if your problem has only one wall, then it is possible to set the wall location at y=0.0. In this case, 0.0000028 will not cause problem for the single precision math. But, in general 3-D problem with more than one walls, the wall location will be more like 1.0000028 inches.)
|
|
December 15, 1999, 09:42 |
Re: Can we quantify the fruits of CFD?
|
#15 |
Guest
Posts: n/a
|
Hi Brady,
One place you might want to start looking is on the web pages of the commercial CFD vendors. We have several examples of cost savings listed on our web site as I'm sure do other CFD vendors. You may also want to check back issues of Mechanical Engineering magazine. In the past two years there have been several articles about CFD applications and savings in the design process. Good luck- Greg Fallon Fluent |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
STAR-Works : Mainstream CAD with CFD | CD adapco Group Marketing | Siemens | 0 | February 13, 2002 12:23 |
ASME CFD Symposium, Atlanta, July 2001 | Chris R. Kleijn | Main CFD Forum | 0 | September 13, 2000 04:48 |
ASME CFD Symposium, Atlanta, 22-26 July 2001 | Chris R. Kleijn | Main CFD Forum | 0 | August 1, 2000 10:07 |
Which is better to develop in-house CFD code or to buy a available CFD package. | Tareq Al-shaalan | Main CFD Forum | 10 | June 12, 1999 23:27 |
public CFD Code development | Heinz Wilkening | Main CFD Forum | 38 | March 5, 1999 11:44 |