[aerosayan]

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

[FMDenaro]

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]

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

[FMDenaro]

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...

[sbaffini]

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"

[LuckyTran]

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.