[liuhuafei]

Files:
fvMatrix.C
fvMatrixSolve.C
lduMatrixATmul.C

Some question about the coupled boundary.
In fvMatrix.C
In subroutine Foam::lduMatrix::solverPerformance Foam::fvMatrix<Type)::solve。

Firstly we call addBoundarySource(source)，then the 'implicit' part of coupled boundary has been added to the source.

void Foam::fvMatrix<type>::addBoundarySource
(
....
if (!ptf.coupled()){
addToInternalField(lduAddr().patchAddr (patchI), pbc, source);
}
else if (couples)
{
...
forAll(addr, facei)
{
source[addr[facei]] += cmptMultiply(pbc[facei], pnf[facei]);
}

But in the following code, the updateMatrixInterface will add the 'implicit' part to the source once again. If the updateMatrixInterface has the same function, the addBoundarySource doesn't need including the coupled boundary part. Why need add the 'implicit' part twice?

Another question,what the function of the initMatrixinterfaces

In addition,In lduMatrix's AMul and TMul also call the initMatrixInterfaces and UpdateMatrixInterfaces，it seems that we needn't call the initMatrixInterfaces and Updatematrix in the solve subroutine.

[henry]

All this messing around is because the solver is segregated so the contributions for the other components must be included explicitly and those for the component being solved for included implicitly for each component.

H

[hjasak]

Heya,

The coupled treatment is done in updateMatrixInterface and its init function. This business of the addBoundarySource is there because the boundary condition contribution is kept separate until the matrix is completed. This used to be necessary because the matrix coefficients were only scalar and for a vector/tensor variable the b.c. contribution is clearly a vector or a tensor. Therefore, splitting it in components means you have to add the (explicit) part one at a time.

Don't worry, all is well.

Hrv

[liuhuafei]

Thanks for your answer

[malaboss]

Originally Posted by hjasak

The coupled treatment is done in updateMatrixInterface and its init function.
Hrv

Hi FOAMers,
I have been examining in details how boundary conditions were implemented in OpenFOAM since for my problem, when I commented out updateMatrixInterface my case converged more easily than with it, especially when I set the reference pressure with cell reference.

Does anyone know what is precisely meant by the "coupled treatment" of updateMatrix Interface that Hrv is talking about ?

Thanks in advance !

[chengdi]

"coupled treatment" of updateMatrix Interface that Hrv is talking about is `coupled BC treatment`. Coupled BC includes cyclic and processor BC. They are `interfaces` so every face on the BC have two owner cells. The face on normal BC only have one owner.

More importantly, the matrix coefficient (indicating the interaction between the cells sharing a face) cannot be expressed in lduMatrix class because of the limit of lduAddressing used in most programs which uses "lower==owner, upper==neighbour" strategy for simplification. So the extra off-diagonal coeffs must be stored in another way.

[EmadTandis]

Originally Posted by malaboss

Hi FOAMers,
I have been examining in details how boundary conditions were implemented in OpenFOAM since for my problem, when I commented out updateMatrixInterface my case converged more easily than with it, especially when I set the reference pressure with cell reference.

Does anyone know what is precisely meant by the "coupled treatment" of updateMatrix Interface that Hrv is talking about ?

Thanks in advance !

The way that updatematrixInterface acts is as below:
the matrixUpdateBuffer_ -which is calculated by initMatrixInterfaceUpdate, and actually is the most recent approximation of interpolated unknown variable on neighbour cells- is multiplied by boundaryCoeffs() of regionCouplePatch and then added to the source of current matrix.