
[Sponsors] 
Reasons for decoupling the pressure and velocity computations 

LinkBack  Thread Tools  Search this Thread  Display Modes 
March 31, 2017, 06:00 
Reasons for decoupling the pressure and velocity computations

#1 
New Member
Jan Heiland
Join Date: Mar 2017
Location: Berlin
Posts: 3
Rep Power: 7 
I'm currently writing a review paper that analyses methods for solving the incompressible NavierStokes equations from a very mathematical point of view. And I'm lacking some reasoning...
The standard routines in the prominent flow solvers, like Ansys CFX or OpenFoam, rely on some sort of pressure correction schemes, say SIMPLE or RhieChow interpolation. The advantages of these schemes, that I have found so far, are
Anyways, I am still missing the definitive argument why decoupling schemes are preferable over schemes that solve for velocity and pressure simultaneously. 

March 31, 2017, 06:38 

#2 
Senior Member
Filippo Maria Denaro
Join Date: Jul 2010
Posts: 6,259
Rep Power: 67 
First, RhieChow interpolation is not a decoupling method but it is used when colocated arrangement leads to pressurenode decoupling in the Laplacian stencil.
Then, your main question is about an issue developed for some decades by researchers and you can find a lot of literature. The main reason is that the decoupling is somehow inherent to the fact that the pressure is an auxiliary variable. The momentum equation is suitable to be considered in the form of the Hodge decomposition. The decoupling is a way to resolve faster the system, thus some projection method can be efficient. Of course, as happens in a splitting, something is resulting about the cost in terms of the accuracy. Again, this issue is complex and the topics are largely studied in the literature. 

March 31, 2017, 07:24 

#3  
New Member
Jan Heiland
Join Date: Mar 2017
Location: Berlin
Posts: 3
Rep Power: 7 
Thanks for the instructive remarks.
This is basically how I find it discussed in the literature... You say Quote:
Quote:
However, I am still looking for a more satisfactory argument. Maybe, I should ask the other way round. What is wrong with schemes that keep pressure and velocity coupled? 

March 31, 2017, 07:31 

#4 
Senior Member
Filippo Maria Denaro
Join Date: Jul 2010
Posts: 6,259
Rep Power: 67 
Nothing wrong... it is just computationally very expensive


March 31, 2017, 09:49 

#5 
Senior Member
Filippo Maria Denaro
Join Date: Jul 2010
Posts: 6,259
Rep Power: 67 
just as example of the topic, you can read the first pages of this paper
http://www.ecs.umass.edu/mie/tcfd/Papers/FSM0.pdf 

March 31, 2017, 09:51 

#6 
Senior Member
Michael Prinkey
Join Date: Mar 2009
Location: Pittsburgh PA
Posts: 363
Rep Power: 23 
Just to put some scale to the question. If we consider 3D incompressible flow, steady or transient, you will find that in a segregated scheme, the pressure equation will require O(10) times more work to solve than each of the three momentum equation. For transient simulations using fractionaltimestepping, it can be even larger because you need super accurate pressure results. So, the cost of one iteration/timestep is O(1 + 1 + 1 + 10). If, instead of solving the segregated system, you lump all of those equations together and introduce all of the interfield coupling terms, you will still need to iterate that larger system until the pressure field converges, say O(4*10). Pushing the pressure terms into an implicit system generally does not make timestepping more stable or implicit corrections much more accurate. So, instead of doing cheap momentum solutions and one hard pressure solution per timestep/iteration...you are doing roughly the same number of iterations for the full system as you did for the segregated pressure solution just to chase a pressure solution and continuity enforcement.
It can seem counter intuitive. If you put everything together into the same system, it seems that it *should* converge faster, but in practice, it often doesn't...or at least, it doesn't converge more quickly than the segregated solution scheme sufficient to justify its larger periteration cost. It is a bit like a convergence series, if you like. You can build a multidimensional Taylor series and compute all of the cross terms in all of the dimensions and you will have lots and lots of terms. That is like the coupled system. It will work. And it will be robust. Or you can notice, that one particular variable really controls the convergence of the series. And you selectively expand in that variable (aka pressure) and you keep far fewer terms for the other variables. Are you missing some details in the crossterms and lowerorder expansions? Sure. Are they important to getting to your answer? Usually not. So, you get virtually the same results with far less effort. 

March 31, 2017, 09:56 

#7  
Senior Member
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 1,135
Rep Power: 29 
Quote:


March 31, 2017, 09:58 

#8 
Senior Member
Filippo Maria Denaro
Join Date: Jul 2010
Posts: 6,259
Rep Power: 67 
As wrote in the paper of Perot, the key is in the nature of the matrix for the coupled system...


March 31, 2017, 10:13 

#9 
Senior Member
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 1,135
Rep Power: 29 
The term decoupling in navier stokes is used in different sense. The more appropriate term here is segregated algorithm vs coupled or monolithic algorithms.
The are various things wrong with coupled system, at least the way things stand today. (in future we may find ways to overcome them). First of all we are looking at system [A G] u s [D 0] p = 0 or Au + Gp = s u = Ainverse[s  G p] D ( Ainverse[s  G p] ) = 0 D Ainverse G p = D Ainverse s To solve this system you need to solve (D Ainverse G ) which is Schur compliment. Since you can not construct this schur compliment you try to approximate this with various methods. Approximating Ainverse as inverse of diagonal elements would lead to SIMPLE algorithm. To understand what is wrong with coupled system you need to understand that Schur Compliment is extremely difficult to solve fully (Though i have idea where i can use GMRES to solve this schur without constructing it, many other people have tried similar approach). Approximating this schur leads to different algorithms like SIMPLE i mentioned. Then you can have commuter based approach where you basically move the Ainverse out and solve in two steps. Here Ainverse is just solving from A. The major problems with the coupled solver can be classified in two main categories. 1. Finding a suitable preconditioner to this Schur or to whole system. 2. Finding proper smoother for multilevel scheme. For the point 2, it has been shown that SIMPLE is not a good smoother for it. Gauss Siedel method diverges too easily and pretty much useless. LU factorization method have had some success but fail when A is not diaginally dominant. Last point, over the years companies have developed way to keep SIMPLE stable and convergent, but coupled systems have not seen this fine tuning as we are just starting off with them. Hope it summarizes. 

March 31, 2017, 10:20 

#10 
Senior Member

Let me put it the other way around. What would you like your solver to be? Fast and with a low memory consumption on one side, robust (i.e., always converging) and flexible to physical modeling complexities on the other one. Accuracy is only partially relevant, in the sense that one can still consider only accurate options.
These are mostly conflicting requirements, that's why both kind of solvers are still in large use today. Let's see few specific points: 1) Memory requirements for matrix allocations scale with the square of the block size of the matrix. A typical coupled solver will have 5x5 block entries in the main matrix, which is 25 times higher than the scalar case. Adding species transport or anything else coupled to this will get things worst. A typical segregated solver will use, at most, one scalar (i.e., nonblock) matrix per time. In some cases it actually goes down to use just two matrices, one for pressure and the other one for the remaining scalar quantities, and one might consider retaining the latter in memory for reuse. This is a huge +1 for segregated solvers. 2) Having a coupled solver doesn't necessarily means that everything is coupled. Still, some fields, like species, typically require to be solved coupled with the main equations. If you want to add some field to an already developed coupled solver, you mostly end up rewriting the whole thing. For segregated solvers you just add a new solve in the queue. This is a huge 1 for coupled solvers. 3) Convection schemes for coupled solvers are quite different from those for scalars. You basically end up using a specialized Roe solver or an AUSM like scheme. Preconditioning also adds specificities for some coupled solvers. In contrast, the recipe for a scalar in a segregated solver (time discretization, convection, diffusion) will serve most of the variables. +1 for segregated. 4) The sparsity patterns of the matrices arising in implicit discretizations of PDEs are both a strength and a weakness. The strength comes from the fact that you just need to store few coefficients per row. The weakness is that you don't have a regular access pattern or even direct access to columns (i.e., for the CSR matrix storage format). Coupled solvers, just like highorder ones (DG or spectral element), use such access pattern more efficiently. For example, a segragated solver will require accesing the same matrix coefficient n times, one for each variable. But each access is in a different loop. Coupled solvers will instead access an NxN block (which typically still stays in memory) only once. +1 for coupled solvers. 5) Nonetheless, the world is short of matrix algebra packages working with block matrices (I can only think of PETSc and Hypre... maybe Trilinos, I don't know). You will probably need to write your own or stick to such large packages. Also, I guess, a coupled discretization increases the complexity of the possible resulting systems, with the result that only few recipes can robustly handle most cases (e.g., GMRES+ILU0 in most density based solvers). 6) Coupled solvers, to the best of my knowledge, always require outer iterations for the nonlinearity. For some cases, efficient segregated solvers can be built which do not require them (e.g., the fractional step). +1 for segregated solvers. 7) Still, segregation is not always the recipe for convergence. You probably know better than me the reasons. 1 for segregated. How huge is this... well, it depends. If you need to solve a problem which, for some reason, cannot be handled by any segregated solver, I guess this is a huge 1. A coupled solver also greatly enhances convergence in general cases. So, long story short, the coupled solver is a workhorse for complex cases where no other possibility exists or, when memory is not an issue, to speed up things. From the development side it is less flexible to adapt and more complex to handle, requiring a more specialized knowledge than just ellipticparabolic PDE stuff. Coupled solvers which are just the coupled trasposition of a segregated incompressible one only slightly ameliorate the complexity, while the burden still remains. The whole point, I think, is to have the best instrument to handle efficiently a given case. Most of the times this is a segregated solver... just not always. That's why, I think, coupled solvers are not rule but the exception. Most of the times they are just overkill (note also that they tend to be less flexible to user lack of knowledge in setting up a case). Sometises they are your only chance. For cases where both are a solution, you should consider if the memory overhead is allowed and balance it with the faster convergence. There might be a break even point with respect to the problem size, physics involved and memory available (per node). 

March 31, 2017, 11:42 

#11 
Senior Member
Filippo Maria Denaro
Join Date: Jul 2010
Posts: 6,259
Rep Power: 67 
I agree with you
Just as a note, the operators A, D, G, should be seen after a discretization is introduced so that their expressions are not unique. 

April 2, 2017, 04:49 

#12 
Senior Member
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 1,135
Rep Power: 29 
Anyway if anyone wants to read up onto this whole issue, i could recommend this book
http://www.springer.com/br/book/9780387715636 I have this book and it gets very high recommendation from me. Very nicely written. (Just note that book is written from finite element view and not from finite volume view) 

April 2, 2017, 09:10 

#13  
Senior Member
Filippo Maria Denaro
Join Date: Jul 2010
Posts: 6,259
Rep Power: 67 
Quote:
Good textbook, thanks. Actually, I think that the real issue is about the errors introduced by the decoupling of the equations and how to work with. 

April 3, 2017, 03:40 

#14 
New Member
Jan Heiland
Join Date: Mar 2017
Location: Berlin
Posts: 3
Rep Power: 7 
Good point made by arjun in #9 (and also by sbaffini in #10). I haven't thought of that. Namely that there are no generally good preconditioners or linear algebra packages for the coupled system.


April 6, 2017, 12:36 

#15 
Senior Member
Lucky
Join Date: Apr 2011
Location: Orlando, FL USA
Posts: 5,112
Rep Power: 60 
Although the discussion was nice, I would like to add that we should be a little careful to clarify what we mean by coupled.
Coupled solvers that solve coupled systems (such as density based solvers) usually solve the mass, momentum, and energy equations simultaneously. Segregated solvers (usually) decouple the energy equation. Now because you lack an independent equation of motion for pressure, you end up with the pressurevelocity coupling problem. Here you have still have another choice of the coupled mass & momentum equations for pressure & velocity. If you choose not to solve the coupled system directly, then you must use some predictorcorrector scheme (SIMPLE, etc.). As for why a predictorcorrector scheme is preferred, the answer is well explained by post #3. It just so happens (via experience) that more efficient convergence can be achieved, and the coding is elegant! A similar thing also happens for coupled systems and coupled solvers. You can imagine solving an isothermal flow with a coupled solver. At every iteration you solve an energy equation together with mass & momentum to solve for a temperature solution which is more or less trivial. You waste computational effort for no gain, but you get to brag about how you solved mass, momentum, & energy! The question is what is limiting your convergence? Wherever that is, that's where you should focus your effort rather than bruteforcing the entire coupled system. Hence, even with density based solvers, they usually do not couple additional equations beyond energy. I.e. species transport equations are still segregated. Btw this issue doesn't only pop up in pressurevelocity coupling problems and not limited to nonlinear problems. In general, the numerical solution of linear systems of equations is littered with tons of general examples. As an elementary example: consider the Jacobi method, or GaussSeidel, or successive overrelaxation methods. These methods converge really fast when the systems are diagonally dominant and really slow when they are not diagonally dominant. It's quite easy to set up a system of equations in the wrong order and have a diagonally nondominant system. It is a mathematically trivial operation to reorder the equations and putting the largest elements on the diagonal. The system of equations that need to be solved are the same but one form is faster than the other! The issue is that we are not only interested in convergence, but fast convergence! 

April 7, 2017, 07:06 

#16 
Senior Member

I have to say that, while I certainly agree on the fact that a segregated solver is the winner in most cases, I do not quite agree on the general idea which is emerging (or seems to, for me) in the comments. That is, if pressure gets you troubles, why bothering coupling all the rest? Also, don't bother coupling "energy modes" (which is what temperature and pressure are) which always exist, and completely rely on your incompressible/isothermal approximation.
First of all, pressure and momentum ARE coupled. Only in the inviscidincompressible limit one is the potential for the other. If it was so easy, the Fluent potential flow initialization would always give fields within few iterations from convergence. Also note that, this coupling is quite different from, say, the one with turbulence models, where the turbulence model only affects the magnitude of the diffusion coefficient. As long as the physical coupling exists, I think the matter is only about the amount of advantage the actual coupling in code gives you, not the sign of the advantage (which is always +). More in general, I would put the question in the following terms: for a given iteration, would you treat all the flow energy modes separately or allow energy to go where it more likely (read also physically, somehow) would go? There are cases where the coupling is evident and better taken into account: strong buoyancy, all the compressible world, combustion with species transport (I still think that knowing how the change of concentration will affect the temperature field at the next iteration is better than not, in predicting the temperature at the next iteration) and, in general, all the cases where the fluid motion is generated by an external force governed by another transported variable. But even in the incompressible/isothermal world, huge pressure differences are likely to give more trouble to a segregated solver than a coupled one. Obviously, all the concerns on the numerical efficiency and availability of robust solvers clearly remain. 

April 7, 2017, 07:45 

#17 
Senior Member
Filippo Maria Denaro
Join Date: Jul 2010
Posts: 6,259
Rep Power: 67 
I am not sure where this discussion will drive us ...however, the incompressible hypothesis leads to a different world wherein one thinks differently to the coupling. The compressible flow world encounters different problems. Note that the mathematical character of the equations change.
I would focus on the former case. Coupling with energy equation by Bousinnesq model is a different issue. 

April 7, 2017, 10:06 

#18  
Senior Member

Quote:


April 7, 2017, 11:42 

#19 
Senior Member
Filippo Maria Denaro
Join Date: Jul 2010
Posts: 6,259
Rep Power: 67 
..... :d:d


April 7, 2017, 11:42 

#20 
Senior Member
Filippo Maria Denaro
Join Date: Jul 2010
Posts: 6,259
Rep Power: 67 

Tags 
poisson equation, pressure and velocity, pressure correction 
Thread Tools  Search this Thread 
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Pressure loss Velocity coupling  CFXMUFFIN  CFX  1  February 6, 2016 05:43 
Neumann pressure BC and velocity field  Antech  Main CFD Forum  0  April 25, 2006 03:15 
Variables Definition in CFX Solver 5.6  R P  CFX  2  October 26, 2004 03:13 
Terrible Mistake In Fluid Dynamics History  Abhi  Main CFD Forum  12  July 8, 2002 10:11 
what the result is negatif pressure at inlet  chong chee nan  FLUENT  0  December 29, 2001 06:13 