[RJCHARLIE]

In FVM, the face normal gradient is split into orthogonal and non-orthogonal part. The orthogonal part is evaluated implicitly, whereas the non-orthogonal part is evaluated explicitly as a source term using known velocity field. My question is why is the non-orthogonal part not implimented in a way such that it is evaluated implicitly? Is there any advantage in the explicit implimentation?

[FMDenaro]

Could you better details your question with an example to a textbook/paper?
I suppose your are talking about FV on unatructured grids.

[sbaffini]

Originally Posted by RJCHARLIE

In FVM, the face normal gradient is split into orthogonal and non-orthogonal part. The orthogonal part is evaluated implicitly, whereas the non-orthogonal part is evaluated explicitly as a source term using known velocity field. My question is why is the non-orthogonal part not implimented in a way such that it is evaluated implicitly? Is there any advantage in the explicit implimentation?

The non orthogonal term involves the cell gradients, which has a number of issues.

Let's bypass the difficulty in tracking the coefficients with all the different methods and go straight to the point: you get an enlarged system band getting higher memory consumption, less cache efficiency and reduced diagonal dominance as you put in second layer neighbors. Deferred correction is just simpler and works better.

[sbaffini]

Now let me highlight that tracking the coefficients for general methods is a real difficulty. For example, in my code I have a method where a weighted least squares gradient is used as initialization for a green gauss method. It's not impossible but nothing I want to deal with in a general purpose CFD code.

[aerosayan]

Originally Posted by sbaffini

Now let me highlight that tracking the coefficients for general methods is a real difficulty. For example, in my code I have a method where a weighted least squares gradient is used as initialization for a green gauss method. It's not impossible but nothing I want to deal with in a general purpose CFD code.

Dr. Nishikawa made a two-step LSQR method which is apparently easier to parallelize since it only depends on the neighbors, and not also the neighbors of neighbors.

[sbaffini]

Originally Posted by aerosayan

Dr. Nishikawa made a two-step LSQR method which is apparently easier to parallelize since it only depends on the neighbors, and not also the neighbors of neighbors.

The issue is not about parallelization per se (it would be but, for example, the number of layers in my code is a parameter, so I just need to change a number if that is required).

The issues are the book keeping to derive the exact coefficient formulas for each gradient method (and, as I wrote, some methods would be very challenging to derive, imagine debugging) and the matrix diagonal dominance in serial as well parallel. More off diagonal terms is bad for diagonal dominance independently from the parallelization.

Even a single layer least squares gradient (which is super easy for the coefficients, because you already have them) still increases the number of layers by 1.