# Is iteration direction over a structured mesh important?

 User Name Remember Me Password
 Register Blogs Members List Search Today's Posts Mark Forums Read

 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 free-stream 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 Gauss-Seidel methods for linear algebric system. Jacobi iteration updates each components at k+1 as function of the solely state k. Gauss-Seidel 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. aerosayan likes this.

April 5, 2020, 07:03
#3
Senior Member

Sayan Bhattacharjee
Join Date: Mar 2020
Posts: 495
Rep Power: 8
Quote:
 Originally Posted by FMDenaro 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.

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:
 Originally Posted by aerosayan 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

yes, however Jacobi would be slower than GS also if you use a non-optimal 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 cache-miss. You can get an optimal number of iteration but the CPU time is relevant...

 April 5, 2020, 08:31 #5 Senior Member     Paolo Lampitella Join Date: Mar 2009 Location: Italy Posts: 2,173 Blog Entries: 29 Rep Power: 39 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" aerosayan likes this.

 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 Gauss-Seidel 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 Cuthill-McKee algorithm). Still, Cuthill-Mckee 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 square-ish 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 Coppersmith-Winograd algorithms and so on. Convergence issues are dictated more-so 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. aerosayan likes this.

 Tags euler equation, iteration process, solver development

 Thread Tools Search this Thread Search this Thread: Advanced Search 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 Off Pingbacks are On Refbacks are On Forum Rules

 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 Andrea Panizza FLUENT 1 November 9, 2003 03:48

All times are GMT -4. The time now is 13:31.

 Contact Us - CFD Online - Privacy Statement - Top