Time Spent

This is a general question that I would like to ask you all (those who use commercial codes and those who use their own codes):

Of all the activities involved in a CFD simulation (CAD and grid, Solution, Postprocessing, and possibly validation), where do you HAVE to spend most time.

I believe there are many challanges in CFD. I am trying to ascertain if there is ONE overwhelming problem that every one would agree on as the most challanging issue. It may be that different people have differnt "most time consuming" part, or it may be that "most" would report the same part.

I think that the answer to the question will depend to some extent on who is answering. I think (or would like to think) that code developers spend quite a bit of time on activities relating to validation.

As an end user, I spend most of my time on grid generation. The key to obtaining good solution is to start with a good grid. If I can shorten the time that it takes to generate a high-quality grid that is appropriate for the analysis that I am trying to perform, then I can begin solving the problem that much sooner.

(1). Aerodynamics problems (or thermo-fluid problems) can be solved in three approaches: a) Analytical solutions, b) Experimental solutions, and c) CFD solutions. (2). The CFD solution procedures follow very closely the experimental solution procedures. (3). So, the answer to your question is: the most time consuming step can happen at any stage. It depends strongly on the complexity of the problem to be solved.

I can only speak of my own experience. We use the software train: Pro-engineer, ICEM, STAR-CD, ANSYS evry package has its own specialist working with it in close cooperation. It used to be that grid generation took a lot of time. However with ICEM (unstructured tetra mesh) it is quite fast. Setting up the poblem with STAR (the lates version) also doesn't take a lot of time. What really takes a lot of time is making the nice color pictures for your boss. You will never be 100% satisfied with the result. You will try any colormap, try every image format and spend a lot of time near the color printer waiting for your last picture to come out. I'm not sure whether this helps you. It helps me ;-)

Alton, Thank you for your response. I agree with you (both parts). However as you see others have posted differnt responses.

Coming to your response, you say, and I agree, that key to obtaining a good solution is to start with a good grid. The question is: Is there a global definition of a good grid that people can agree on. To some extent you answer it yourself when you say "high-quality grid that is appropriate for the analysis that I am trying to perform". But there can be some common attributes to a good grid. Would you agree if one says a good grid means

Joern, thanks for your response. Is your nearly automatic mesh generation an all tet mesh? Does not automatic mesh generation generate unnessarily large number of cells (most of the automatic mesh generation techniques result in fairly equilateral cells, which means far too many cells than needed to resolve directional characterstics such as flow near the walls in turbulent flows)?

For CAD clean up, are you talking about IGES or some other form of CAD data?

Do your solutions converge nicely most of the time, or do you have tweek the relaxation parameters. I guess it depends on the experience of the user and familiarity with the problem. What problems you typically look at?

Thank you for your response. Yours is a nice general statement. But can you tell me, in your vast experience, was there anything specific that TYPICALLY consumed more time. It possibly can be dealing with customer support too if one is using a commercial code.

thank you for your reponse. It's very interesting and kind of surprising. Does the boss not care what the pictures actually show (conclusions about validity of the study) or does he believe the color pictures blindly?

Is tet meshing good for ALL your needs? Do you not deal with turbulent flows. Are you then not using too many cells. Probably it does not matter if you have a big enough machine.

A related question: When using structural dynamics code, such as ANSYS, how do you get the boundary conditions from the CFD code to ANSYS? Both Fluent (FIDAP) and CFDRC claim to have the coupled fluid-structure interaction capabilities. They also come with their own preprocessors (which may not be as good as ICEM, I don't know). Would not that be a better route for you than working with 4 codes from 4 differnt vendors. Just a thought?

Thank you for your response. Yours is a nice general statement. But can you tell me, in your vast experience, was there anything specific that TYPICALLY consumed more time. It possibly can be dealing with customer support too if one is using a commercial code.

thank you all who have participated so far. what prompted this question was an interesting debate on Gambit on the Fluent's forum. One of the threads talk about TWO WEEKS of time on model creation and mesh generation. I thinks it's not specific to Gambit and other preprocessors would be no differnt. I also think it to be highly unlikely that solution would take this long (specially when we have the parallel codes).

If one includes CAD clean up as one of the model preprocessing activities, then preprocessing is probably the most labor intesive activity (post processing is also labor intensive). I would be very interested in learning from your experiences as to what the most promising techniques for reducing labor-intensiveness of pre-processing (automatic CAD clean up, automatic mesh generation for all classes of problems). Has anyone tried to use Aritificial intelligence in the entire cycle of CFD analysis? Am I dreaming?

(1). I think, every step in the CFD process is important. (2). And the complexity of the problem to be solved will determine how much time is required. (3). The lessons learned from the NASA's Mars Probe program simply says that if you have to repeat the English-Metric conversion for one thousand times to make sure that there is no error involved, it is still worth the effort. (4). By the way, "Time Spent" is really not a technical issue at all. On Internet, you take whatever is there, instead of requesting specific answers.

Faraz, I agree with your criteria for a good grid, and I have at various times in the past even been more specific.

1. The grid density should vary smoothly. I have, in general, tried to maintain a ration of adjacent cell edge lengths of 1.5:1 or less. Larger ratios were probably possible, but who needs potential problems when faced with a schedule.

2. The grid should be as othogonal as possible at boundaries. This is mainly done via eye.

3. For gradients at the wall, every code I've used has provided guidelines on y+. For sharp gradients in other locations (shear layers, jets), you have to guess what the flow is going to loo like, and assess the grid resolution later.