# Iterative equation solvers in CFD

 Register Blogs Members List Search Today's Posts Mark Forums Read

 February 25, 1999, 12:35 Re: Iterative equation solvers in CFD #21 Shigunov Guest   Posts: n/a 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

 February 25, 1999, 13:26 Re: Iterative equation solvers in CFD #22 John C. Chien Guest   Posts: n/a 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."

 February 25, 1999, 16:07 Re: Iterative equation solvers in CFD #23 Shigunov Guest   Posts: n/a 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.)?

 February 26, 1999, 09:49 Re: Iterative equation solvers in CFD #24 Gassan Abdoulaev Guest   Posts: n/a 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?

 February 26, 1999, 11:01 Re: Iterative equation solvers in CFD #25 Vitaly Bulgakov Guest   Posts: n/a 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

 February 26, 1999, 12:13 Re: Iterative equation solvers in CFD #26 John C. Chien Guest   Posts: n/a (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.

 February 26, 1999, 15:22 Re: Iterative equation solvers in CFD #27 Shigunov Guest   Posts: n/a 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

 February 26, 1999, 16:43 Re: Iterative equation solvers in CFD #28 Sergei Chernyshenko Guest   Posts: n/a 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

 February 26, 1999, 16:58 Re: Iterative equation solvers in CFD #29 Vitaly Bulgakov Guest   Posts: n/a 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

 March 1, 1999, 07:54 Re: Iterative equation solvers in CFD #30 Sergei Chernyshenko Guest   Posts: n/a >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

 March 1, 1999, 08:30 Re: Iterative equation solvers in CFD #31 Gassan Abdoulaev Guest   Posts: n/a (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!

 March 1, 1999, 10:58 Re: Iterative equation solvers in CFD #32 John C. Chien Guest   Posts: n/a 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.

 March 1, 1999, 12:11 Re: Iterative equation solvers in CFD #33 Vitaly Bulgakov Guest   Posts: n/a >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

 Thread Tools Display Modes Linear Mode

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post CFD Main CFD Forum 16 July 18, 2016 18:59 Jas Main CFD Forum 10 March 30, 2013 13:26 John C. Chien Main CFD Forum 36 January 24, 2001 22:10 Tareq Al-shaalan Main CFD Forum 10 June 12, 1999 23:27 Heinz Wilkening Main CFD Forum 38 March 5, 1999 12:44

All times are GMT -4. The time now is 06:43.