I'd be grateful for opinions regarding the use of tet vs. hex meshes. I am modelling airflow in gas turbine intake & exhaust systems and the code my company has recently introduced uses only tets for the mesh ( I believe their main criteria may have been integration with Solidworks).

The resulting tet mesh is very messy and I wonder if it is computationally efficient. Furthermore it seems to take all the resources my pc has to offer (dual 2.7 GHz Xeon, 2GB RAM) to solve even a simple duct assembly. At this rate I cannot foresee how it will be possible to model a full assembly under a 32 bit Windows application due to the RAM limitation.

My questions are: For a given geometry (say a curved duct) would a combination of hex and tets produce a better, more structured mesh than pure tets ?

Is the use of pure tets a 'brute force' approach, resulting in a large number of elements with a consequent increase in computing power ?

Is running a 32 bit code under windows realistic, or should I consider 64 bit (are the Itanium processors any good ?), or run under Unix ?

Thank you. Simon.

Hi,

If you have narrow duct, the hex mesh is better. If the geometry is very complicated, tet mesh mignt be easier to generate and better to resolve the flow-field change.

The main point is to use such a mesh method, which will give good resolution in places where you need it. Hex mesh will be always smaller. Some software gives better results (specially heat transfer through the wall) with the hybrid mesh.

To combine the mesh might be the best solution.Depends on the software. Also the memory is not the only parameter. What is the convergence rate improvement? Memory is cheap, time not.

performance: windows will geneally take a bit more memory for the same case, than any unix, (on 800MB case,win+120MB) that's the only difference we noticed. I do not think 64 bit has to do anything with it.

matej

Sorry not to answer your question but your post makes me wonder..... If integration to SolidWorks is key then I would think your company would be using COSMOS FloWorks which is supplied by SolidWorks. FloWorks does NOT use a tet mesh but a hex mesh. What product did your company choose for compatability with SolidWorks??????

TIA

I suppose I have to give a bit of background here.. My company is using Solidworks for 3D modelling, as part of the movement from 2D to 3D the company had identified a need to develop some CFD capability in house. I joined the company after the software had been selected, and it seems that integration with Solidworks was one of their main criteria for selecting a CFD code. The original plan I believe was for CAD drivers to do the CFD, no doubt due to the misconception that CFD is now just an extension of CAD. The code they chose was CFDesign on the recommendation of a consultancy. Now I'm not knocking CFDesign, it's a very good tool for some applications, and the user interface is wonderful, but it's a bit too much fly by wire for me personally. I like to have much more control over what I'm doing, but being an ex Fluent user you could say I'm biased.

One of the things I want to do here is make sure CFD is done properly, so we have to look at the flow physics and validation in particular . I don't want to say too much about CFdesign yet, as I'm just getting into it, am trying to remain objective and the last thing I want to do is kick off a slagging match between software vendors/users. What I will say is that I will be looking to benchmark CFdesign aginst other codes to see which is best for our particular applications.

I'd be interested in other members experiences concerning implementing CFD in their company from scratch.

Simon.

Hello Simon,

When establishing an in-house CFD capability, there are several considerations to be made. The most obvious is of course to make sure the tool you choose is capable of handling the applications you are interested in in the first place. If this requires moving meshes, multi-phase capabilities, or other special features, it tends to narrow your choice quite a bit. And of course, the integration with your CAD package is also important here. If you can live with geometry transfer by means of third party formats like IGES, basically all alternatives will be satisfactory. If you need closer integration such as direct CAD-readers or interfaces, or if you have special needs concerning coupled FEM/CFD analyses, your possible choices again reduce. A first survey should also take the pricing into account since it makes little sense to test and develop an affinity for a tool that your superiors will never let you buy.

Another aspect is how well the code actually performs in your applications. Here, benchmark results available for instance on the web may be of use, but actual testing is probably inavoidable. Contact the vendors left after the initial survey and ask for free trial licenses or have them run test cases for you. Both approaches are common practice.

On the other hand, you may not always want to buy a Rolls-Royce if you need a car. If your company has been using CFD consultants previously and is somewhat experienced in putting CFD results to use, you may find yourself more demanding regarding the choice of an in-house tool. As an experienced user, you yourself will want to have the best of the best too but it may not be necessary for CFD to add value to your company. If it is taking the step from spread-sheet estimates to CFD, you may often find it OK to compromise on the accuracy and quality of the CFD solutions and still find them highly useful. In such instances however, a contributing cause is often the inability to produce good boundary conditions and validation data.

Finally, you should consider the human resources available for CFD analysis work now and in the immediate future. If you're on your own and trying to boost the use of CFD in the company, you may want to concentrate on a high output, i.e. doing what might be considered less advanced work but a lot of it. This raises the profile and awareness of CFD and its usefulness, which may be extremely valuable for you in the start-up phase. Doing leading edge work that doesn't come to practical use only serves to isolate you in the company, a situation that is very difficult to get out of. On the other hand, if your management is supportive and has a clear vision for CFD combined with a realistic idea of the possibilities of CFD as well as its limitations, you may be more free to focus on tasks where its potential is better utilised already from the start.

Let me stress that I'm not particularly in favour of quick-and-dirty CFD work. I myself use STAR-CD (I have no experience with CFDesign), which I regard a very powerful but, as a consequence, complex CFD tool. However, I speak from my own experience when saying that there must be consistency between what you (or rather your management) want from CFD and what you are willing to put into it. Easy solutions might not be the most satisfying to you personally, but it may be sufficient to your company, and it may be a proper step on the way to a better situation. But then again, I of course don't know your situation and your applications in detail. You should regard these thoughts of mine as no more than personal advice on a general basis.

Good luck further!

Lars Ola

IMHO that was an excellent post Lars Ola.

Lars,

Thank you for your excellent response, I apologise for not getting back to you earlier but I've been on holiday. I agree that in the early stages of implementing CFD it may be appropriate to output quantity rather than quality; this gets management's attention and reassures them that they have not wasted their money. It also safeguards my job!

On the other hand, I have to balance this against the accuracy of the simulation, I could very easily fall into the trap of high output for simple problems (like duct flow), only for output to drop off as soon as I start to tackle more complex problems like vortex shedding. For example, the simplest analysis we may wish to do may be to compute velocity profiles in a square duct following a 90 degree bend. On the opposite end of the spectrum, we may have a flow induced vibration problem, where we are looking to couple a non linear transient CFD solution to a non linear FEA model. Clearly one is going to take much longer than the other, what I need to do is show that even for a simple case, there are many areas to go wrong.

To get my message across, taking the very simplest example I could think of, I have already been able to show the effect of differing mesh densities on flow velocity profiles through a typical intake system and how these could range from 70 m/s to 25 m/s depending on the grid size. The general reaction here was one of surprise, comments ranging from 'why would it do that' to 'I thought the CFD software would do all this automatically'. My point being that now when I highlight other problems to management such as the problems associated with a pure tet, unstructured mesh and running on 32 bit windows pc platform, people will take notice rather than just think ' a bad workman blames his tools'.

My biggest problem now is getting people to take a step back and allow me to review other codes, as I have been having a lot of problems running our current code (which we have had for 2 months). I'm not knocking it, but I am much happier being able to access the nuts and bolts of the problem, rather than use a code that is more fly by wire.

The most important thing for me is to make sure the CFD is implemented correctly and my focus will be on trying to achieve a reasonable level of accuracy in our simulations within reasonable timescales. I intend that we make use of historical test data, or where we do not have it, physically test real geometry in the wind tunnel at the local university and get some validation that way. Until now, people hadn't really considered the need for validation, for me, it is one of the cornerstones of my CFD strategy.

Simon.