<The unstructured mesh approach will save time in the mesh generation stage and is good for average engineers>

This opinion is too categorical. For problems with moving adaptive grids (ALE-approach) the unstructured grid is almost only way, and scietifical enough, too.

With best regards

I think, since the moving boundary was not the focus of the original issue, I am not going to side track to a new question and answer. It is probably easier to state it in this way:" The overlapped multi-block mesh approach can ease the task of mesh generation and improve the efficiency of the solver operation in each block. The added befinit is that the problem with moving objects boundary can also be handled within the same framework."

Sure, thank You. Oversetting grids are the powerful and suitable tool for engineering problems. But what can You say about deformable boundaries (interfaces, shok waves etc.)?

A very interesting discussion, I should say. And different points of view. I agree with John C. Chien, that physics of the problems should be taken into account. But is it always possible in a way he advocates. Let's consider an example of cartesian grids. Yes, they are simple to generate they produce algebraical systems which are easy to solve, they can fit stream-lines in order to minimize error, etc. But still there is a number of questions. Did you ask yourself, why unstructured (for instance, tetrahedral) meshes are used so widely? Only to make life easier for "average" engineers? Cartesian grids work fine, if your domain is a union of quadrilaterals (2d) or hexahedrons (3d), and if you have a laminar and steady flow. What about more complex cases: (1) complex geometry - you know examples yourselves; (2) complex pattern flow: the simplest example - an incompressible flow around a rectangular cylinder with high Re. The geometry here is perfectly rectangular, but do you know how to fit streamlines of this highly unsteady flow? (3) local mesh refinement. I hope you would agree there are problem, where refinement IS necessary. If you refine a cartesian grid, a excessive number of nodes is generated, whereas with unstructured mesh you can reach the same accuracy with much (3-4-5 times) less number of nodes. From my point of view, the most efficient would be a combination of both approaches: (1) domain decomposition, whatever you call it - multiblock, mortar method, etc. Within each subdomain the mesh can be whatever you want - tetr, hex, structured, unstructured, etc. On the interfaces the meshes can be matching or not very much. Well, it's easy to write, but not very easy to code. Believe me. (2) ficticious domain method: the original computational domain is embedded to something very simple, parallelepiped, for instance, which is used to contruct an effective preconditioner. The grid here is locally fitted, i.e. structured almost everywhere, but the nodes in the vicinity of the boundary are shifted to the boundary.

Going back to the very first question about nonsymmetric problems. I hate to solve iteratively nonsymmetric problems! Let me explain. What are the basic requirement to an iterative method? It should be efficient, ideally - algebraically optimal, i.e. the cost to solve a problem with a prescribed accuracy should be proportional to the number of nodes. And you should be able to implement it to a wide range of problems. There are many such methods for PDS problems, coming from elliptic equations; there are such methods for saddle point problems (Stokes problem, mixed FE). There are (are there?) very few methods for nonsymmetric (convection-dominated) problems in general case. Upwind has nothing to do with an iterative solution of an algebraic problem. Whatever you take, the system is always bad. Again I insist, that the best choice (if you can't avoid it) is GMRES+ILU or MG+ILU (there is a number of moditications). Take care!

P.S. By the way, why there are so many guys from fSU, replying this posting? Good mathematical school or lack of fast computers?

Really good discussion. We can see that development of efficient general purpose iterative methods is not waste of time in the context of CFD problems.

Gassan, can you clarify what you mean in your P.S. Best Regards

(1). First of all, I don't pay attention to the name and source of the authors. The important thing is to be able to stimulate some discussions. And may be somewhere along the line, a new door to the future will open to the readers. Naturally, it is very difficult to change one's point of view and the programs already written in one's mind ( brain), so, the open minded approach is essential in the discussion. And we hope that some hints from the discussion will find itself into the un-used areas of the mind ( we don't know where and how ). (2). About the complex geometry,I agree that, at the current state of development, it is easier to fill the empty computational domain with beans of different sizes and shapes. It is a intuitive and common sense approach. That's why it is practical and widely used. It is good. If we look at the source of the complex geometry, I think, in many cases, it is because the design itself does not take into consideration of the fluid dynamic aspect of the problem. I will continue the same discussion into the next paragraph. (3). For example, the complex flow pattern around a simple rectangular comes from the ignorance of the fluid dynamics of the designer. Sure, one can study this from purely academic point of view, and publish papers on the complex nature of the unsteady shear layer and wake. But, in reality, a good engineer with fluid dynamics training will definitely change the design to eliminate the sharp corners ( unless he is using it as a flame holder). Design of bicycle frame is a very good example. Golf head design and the high speed train design are two other examples. So, as we gain more insight into the fluid dynamics using the current unstructured mesh, the design will be changed and the blocked, structured, efficient methods will be used later on the rvised design. (4). As for the unsteady flows, in the test environment, we are still using fixed probes to obtain the data. So, the fixed Cartesian mesh is appropriate also. The only difficulty is the mesh resolution , computer memory and speed. Suppose that some day in the future, you have almost unlimited computer memory and speed available ( sooner of later, it will come.) ,it would be much easier to use the simple Cartesian mesh to cover the whole domain, including the wall layer. In 60's, a 40x40 mesh size for a 2-D problem was considered very large, but today, a workstation with 128 meg RAM is everywhere. For example, a 1000x1000 2-D mesh requires 4 meg RAM per variable. Let's say one write a 2-D program and stores 20 variable per nodal point or cell, the total memory required is 80 meg RAM. The question is: do you really need to use unstructured, adaptive mesh to cover the flow over a 2-D rectangle? As for the computing time, my rough estimate is 10x(1000 + 1000) minimum iterations for a point iteration method. So, you are talking about the time to solve a 1meg point 2-D problem for 20 thousand times. If uniform mesh is used, essentially, there is no need to compute any geometry related parameters, and the execution will be very fast. (5). Once we understand the physics of the problem, we should be able to know the location of the shear layer, the development of the shear layer, the location and movement of the vortices in the wake, and thus we should be able to develop a simple analytical, algebraic, dynamic mesh for such type of problems. ( build a dynamic mesh model and use motion capture technique from the previous computed results to create a transient, analytical , dynamic mesh.) (6). I think , in certain ways, CFD world is lagging far behind the animated motion picture world. If one can animate a 3-D object ( mesh) to simulate the real world motion, one can also animate a CFD mesh to capture the real world flow over a rectangular object (and also far more complex objects). (7). As for the GMRES+ILU or MG+ILU , I will have to do some research to understand the methods first. As I said, point iteration method is easy to code and is good enough for my application so far. But I will look into that area. (8).Thank you for your time.

Hi, can anyone please reply to yet one question about the method of approximate LU factorisation (as in, for instance, in: Pan&Lomax/AIAA J. 26,163(1988)). Thank You very much for any reference on the articles concerning practical implementation of this scheme.

With best regards

Hi again.

ILU was used by Jitesh Gajjar, of the Math. Dept. of Manchester U., UK, for calculating some viscous-inviscid interaction problems. He says it is all right, but nothing exceptional. You could risk contacting him directly for more precise references, allthough he is really busy.

Some other here around prefer matrix Thomas technique.

Sergei

You can contact me regarding ILU if you want. I dare say I have some experience in this field. I'v been working in this area for a long time, espessially in the context of developing equation solvers for practical large-scale problems in structural analysis, geomechanics and CFD.

Best regards

>You can contact me regarding ILU if you want.

Thank you. At the moment I am busy with coding. May be later.

W b/w, Sergei

(1) Agree! Opennes to innovations is very important.

(2) There are many cases when a geometry is given and one has nothing to do with a design: e.g. simulation of blood flow in a heart and arteries. So a CFD engineer is forsed to use something more complex then a cartesian grid.

(3) The aim of CFD simulation is not always reducing the drag. And aero/fluid dynamics is not always the most important consideration. An architect would be interested to know an air flow around a building to be constructed, but I'm not sure he would change the design significantly to reduce the drag.

(4) Fixed Cartesian grids are not appropriate for moving boundaries (heart and heart valves). And CFD simulation is implemented when it's impossible to make an adequate test. With unlimited memory and CPU speed there is no point to discuss - take any mesh, make it as fine as you want (ten billion nodes is okey?) and use Gauss elimination procedure from LINPACK. We would be unemployed then. The point is, that we ARE limited, though the limits are increasing constantly. 2D problems will not be a constrain. What is of interest - it's 3D. How about 1000x1000x1000 grid? 4 giga RAM per variable.... For incompressible NSE you need 16 giga at least.

(5) The well known effect for the incompressible NSE is that using a mesh not fine enough, you can loose some details of a flow pattern (recirculation zones), which can be important. You don't know in advance the location of those details. If your grid is not fine, where is required, you will not see those details. The flow computed on the coarse mesh would behave itself as if there is nothing. The only ways are to use a fine mesh everywhere, or local mesh refinement based on aposteriori error estimates.

(6) First, flow pattern can be very complex, so the mesh would not be able to capture every detail, so there will always be a mismatch between the mesh orientation and the flow. Second, a moving mesh means recomputing of all the matrices at every time step, which can be quite a burden. It's reasonable for moving boundaries, but not for fixed geometry.

(7) And finally, I don't want to say, that Cartesian meshes are not good. They are, but for a certain class of problems, which , unfortunately, is not wide enough to cover all applications. I think that complex problems require sofisticated solution methods.

Best regards!

I think, everything you are saying is true, but there are exceptions. (1). Civil engineers ignoring the drag of the bridge design will run into the same problem as the "Tacoma narrow bridge" which took the master like Von Karman to show the fluid dynamics aspect of the design. The drag reduction design also has been incorporate into some tall chiminy. (2). When you look at the computer monitor, the coordinates is Cartesian and the unit is in piexl. At about 1000x1000 resolution, the curve, the objects are relatively smooth. As for the computer memory, 6 giga hard disk is very common nowadays, some programs automatically use the hard disk as memory device. In the mini-computer days, the same idea was used and it is limited by the hard disk memory available, there is no need for the programmer to do anything except to specify the dimension in his Fortran program. The system automatically takes care of the memory needed. I think, commercial structure codes have been doing this for a long time. So, memory is really almost unlimited. (3). The high density Cartesian mesh approach is really the simplest and the most accurate way to handle CFD problems, fixed or moving boundary. When one starts using other systems with coarse meshes in some part of the domain, there is always uncertainty of missing the details of the flow motion. (4). As for the unemployment issue, 2-D and 3-D grid generation was ideal PhD idssertation topics back in 70's and 80's. Unfortunately, with todays unstructured commercial codes everywhere, CFD codes can now be used by an average engineer, without any knowledge about the CFD, fluid dynamics, aerodynamics or heat transfer, as long as he is familiar with the use of a mesh generation code. The use of the solver is really nothing but making some selections from the menu. (5). When you realize that a CFD problem can be solved by using a commercial code and an average engineer, the market of a real CFD engineer is already gone. I don't think that there are companies still investing in CFD research at all. Based on what I have seen recently, they are cutting the cost and just running the codes. (6). This is why I predicted that in the year 2000, there will be wars in CFD. Computers will be powerful enough so that real CFD engineers will be able to come up powerful codes to defeat large companies, nations as well.

>The system automatically takes care of the memory needed. I think, commercial structure codes have been doing this for a long time. So, memory is really almost unlimited.

Yes, but time is very limited. Disk memory is still very slow and swapping, you are talking about, is very slow. Now, if we imagine that we have unlimited RAM, then it is also slow. The most of computer architectures are cash-based. Only cash is fast, but cash memory is expensive and limited. Let us say, everything is in cash (cash is large). Still the speed is limited against this devil 3D asymptotic.

Regards