
[Sponsors] 
Is iteration direction over a structured mesh important? 

LinkBack  Thread Tools  Search this Thread  Display Modes 
April 5, 2020, 06:13 
Is iteration direction over a structured mesh important?

#1 
Senior Member
Sayan Bhattacharjee
Join Date: Mar 2020
Posts: 495
Rep Power: 8 
I'm trying to code an explicit compressible Euler solver for a flow over a compression corner using a structured grid with the following wall configuration.
Left wall : Inlet Right wall : Outlet Top and bottom wall : Inviscid wall AFAIK, the freestream condition will be set as the initial condition throughout the domain. The current plan is to start the iteration from the bottom wall and move layer by layer towards the top wall. The figure below shows how the iterations are planned to be like. FINISH +>>>+ +>>>+ +>>>+ +>>>+ +>>>+ +>>>+ START Here is my doubt though : In commercial codes like Fluent/CFX, we get an option of "starting the solution from a certain boundary". And in college, we were taught that we should start the solution from the inlet boundary, otherwise it would take too much time or give wrong solution. + I don't understand how this "start solution from a certain boundary" is implemented in the code. + Does it mean that If the inlet is on the left and if the iterations are done as shown in the figure above, then we will get a wrong result or need large iterations till convergence? + Basically, is the iteration direction over a structured mesh important? Thanks 

April 5, 2020, 06:36 

#2 
Senior Member
Filippo Maria Denaro
Join Date: Jul 2010
Posts: 6,832
Rep Power: 73 
I can answer using the example of Jacobi and GaussSeidel methods for linear algebric system.
Jacobi iteration updates each components at k+1 as function of the solely state k. GaussSeidel iteration updates the components at k+1 depening on a part of available components at k+1 and the other part at k. This way you can think that the GS accelerates if the sweep is done properly from the side of more relevant physical variation. Is it that really convenient? You can gain some interation but the method must converge independently from the chosen direction and the chose threshold must be reached by all the residuals. 

April 5, 2020, 07:03 

#3  
Senior Member
Sayan Bhattacharjee
Join Date: Mar 2020
Posts: 495
Rep Power: 8 
Quote:
Thank you for the help. I also thought that the direction of iteration would be important in case of GS acceleration. Could you kindly ensure that I understood the quoted portion correctly? I understood it as this : Using the optimal iteration direction and something like GS acceleration, we can gain some performance improvement and hence require less iterations. But if we select something like Jacobian iterations (which doesn't have an optimum iteration direction), the iterations will still converge to the correct solution, but it will take more iterations to do so. Did I understand that correctly? Thanks 

April 5, 2020, 07:31 

#4  
Senior Member
Filippo Maria Denaro
Join Date: Jul 2010
Posts: 6,832
Rep Power: 73 
Quote:
yes, however Jacobi would be slower than GS also if you use a nonoptimal sweep direction. However, there are further issues to be considered, for example the adoption of the "for" cycle using the external index to face possible cachemiss. You can get an optimal number of iteration but the CPU time is relevant... 

April 5, 2020, 08:31 

#5 
Senior Member

No, Fluent, or any other major commercial CFD code, doesn't actually iterate from the inlet to the outlet, not in the common sense you understand this. They use AMG, that actually does something similar, but in a way that is completely different from classical iterations.
Still, of course, the order might be relevant in general, but is problem dependent, I guess. A good source of information might be "Saad, Iterative Methods for Sparse Linear Systems" 

April 5, 2020, 13:51 

#6 
Senior Member
Lucky
Join Date: Apr 2011
Location: Orlando, FL USA
Posts: 5,730
Rep Power: 66 
Jacobi and GaussSeidel methods are solvers for linear systems in implicit solvers. The directionality of those methods are kinda different. There are sweeping directions and ways to sort the system to make it better for sweeping (e.g. the Reverse CuthillMcKee algorithm). Still, CuthillMckee is for making the Gaussian elimination faster and doesn't do anything for convergence.
If we're talking about fully explicit solvers then the task comes down to how to multiply a sparse squareish matrix A by a column matrix x to get the updated solution x'. Your question is equivalent to which element in the matrix or which cell in the mesh should we calculate first? How to multiply Ax is handled in the underlying library for doing sparse matrix calculations (e.g. a c library or whatever). The software doesn't know nor need to pick (although the linked library would). Then the question is, how does matrix multiplication algorithms works. And here you could turn to CoppersmithWinograd algorithms and so on. Convergence issues are dictated moreso by the problem physics (e.g. the characteristics of the matrix/linear system) than the algorithmic method you use to calculate/solve the system. Your choice of discretization schemes and so on in setting up the problem matter much more than where you start and which direction you sweep. 

Tags 
euler equation, iteration process, solver development 
Thread Tools  Search this Thread 
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
[mesh manipulation] Importing Multiple Meshes  thomasnwalshiii  OpenFOAM Meshing & Mesh Conversion  18  December 19, 2015 18:57 
[snappyHexMesh] No layers in a small gap  bobburnquist  OpenFOAM Meshing & Mesh Conversion  6  August 26, 2015 09:38 
[snappyHexMesh] snappyHexMesh won't work  zeros everywhere!  sc298  OpenFOAM Meshing & Mesh Conversion  2  March 27, 2011 21:11 
[snappyHexMesh] external flow with snappyHexMesh  chelvistero  OpenFOAM Meshing & Mesh Conversion  11  January 15, 2010 19:43 
Structured mesh refinement  Andrea Panizza  FLUENT  1  November 9, 2003 03:48 