# Confusion about how the implicit coupled interfaces are implemented?

 Register Blogs Members List Search Today's Posts Mark Forums Read

 December 22, 2017, 22:38 Confusion about how the implicit coupled interfaces are implemented? #1 Member   Di Cheng Join Date: May 2010 Location: Beijing, China Posts: 47 Rep Power: 15 Thinking about the matrix is a discretization of linearized operator acted on state vector , there result is , which must be converged to source term . Considering parallism using domain decomposition method. x and b are divided as and . and are located and modifiable in processor j, and the access of and on another processor i needs communications. Now, assume the matrix A can be decomposed as So every time function Amul() is invoked in Krylov type solver. The on processor i must be calculated as: In Foam::lduMatrix, are stored as lower_, diag_ and upper_ scalarField. The is the cyclic operator (though I do not know how it is implemented). And the off-diagonal block operators must be implemented in processor interfaces. So my question is: where is off-diagonal block stored or implemented. It must be related to the action of processor j to processor i, which is related to a processor interface. Now, considering a face F. There are several possibilities: 1. F is an internal face, which connect cell O numbered o and cell N numbered n on processor i, so there will be matrix coefficients in (there might be some source term and diagonal term depending on the scheme used). This is the simplest case; 2. F is a boundary face, which only have an owner cell O numbered as o in processor i. It can only form source term and diagonal term on . This is the most normal boundary condition; 3. If face F is an processor interface, it will have two owner cells. One is owner cell on processor i, another one is owner cell on processor j. And there must be an off-diagonal term. I noticed that there is initMatrixInterfacesbefore LDU matrix*vector operation in Amul() function. And after that updateMatrixInterfaces is called. I see the parameter list is : Code: initMatrixInterfaces|updateMatrixInterfaces( add, interfaceBouCoeffs|interfaceIntCoeffs, interfaces, psi, result, cmpt ) I think psi is the state vector to be solved and cmpt is the direction to be solved if the state vector is not a scalar field. The interfaces is the list of processor or coupled patches. The interfaceBouCoeffs/interfaceIntCoeffs is the most confusing part. I do not know what it is. I do not know why it is not stored in lduMatrix but in fvMatrix. 4. If face F is an cyclic-like interface, it will have two owner in one processor. So in the so called implicit coupling implementation of cyclicFvPatchField, the function initInterfaceMatrixUpdate is empty. However, I still cannot understand why it is implicit. 5. When face F is on a cyclic processor interface... I am still unable to dig into it. I think the coupling implementation in openfoam is not 'zero halo'. In the terms of domain decomposition, pure 'zero halo' is like Dirichlet-Dirichlet coupling. It is not implicit.

 December 23, 2017, 21:40 #2 Member   Di Cheng Join Date: May 2010 Location: Beijing, China Posts: 47 Rep Power: 15 I just figured out what is going on in coupled BC. In openfoam, face addressing (owner, neighbour ) is different from lduAddressing (lower, upper). There are two implementation in OFv1706. One is fvMeshLduAddressing, another one is fvMeshPrimitiveLduAddressing. 1. in fvMeshLduAddressing, lower==owner[0:nInternalFaces], upper==neighbour; 2. in fvMeshPrimitiveLduAddressing which is used in overset, there can be more elements in lower and upper. fvMeshLduAddressing is most commonly used. Because of LDU addressing, the function of lduMatrix is limited and it is designed to be like that. lduMatrix is a scalar matrix which only stores none zero coefficients in upper_, lower_, diag_. So the coupled BC cannot be represented in lduMatrix because of this limitation. So the coupled BC is implementated like this: the coupled BC related coefficients are stored in fvMatrix as internalCoeffs_ and boundaryCoeffs_. And the type is FieldField. Now all the coefficients can be accessed in fvMatrix. And the coupled BC (both cyclic BC and processor BC) can be handled in an unified manner. However, I am still confusing about how fvVectorMatrix are solved in segrated or coupled manner. The code is very confusing. serles likes this.

April 18, 2019, 01:20
#3
Member

Join Date: Oct 2013
Posts: 92
Rep Power: 11
Quote:
 Originally Posted by chengdi I just figured out what is going on in coupled BC. In openfoam, face addressing (owner, neighbour ) is different from lduAddressing (lower, upper). There are two implementation in OFv1706. One is fvMeshLduAddressing, another one is fvMeshPrimitiveLduAddressing. 1. in fvMeshLduAddressing, lower==owner[0:nInternalFaces], upper==neighbour; 2. in fvMeshPrimitiveLduAddressing which is used in overset, there can be more elements in lower and upper. fvMeshLduAddressing is most commonly used. Because of LDU addressing, the function of lduMatrix is limited and it is designed to be like that. lduMatrix is a scalar matrix which only stores none zero coefficients in upper_, lower_, diag_. So the coupled BC cannot be represented in lduMatrix because of this limitation. So the coupled BC is implementated like this: the coupled BC related coefficients are stored in fvMatrix as internalCoeffs_ and boundaryCoeffs_. And the type is FieldField. Now all the coefficients can be accessed in fvMatrix. And the coupled BC (both cyclic BC and processor BC) can be handled in an unified manner. However, I am still confusing about how fvVectorMatrix are solved in segrated or coupled manner. The code is very confusing.
I also got to this point on my own and reading the OpenFOAM book, however I want to know how exactly are boundaryCoeffs_ and internalCoeffs_ are handled for processor boundary.

It is irrelevant for me, I exactly know the fvMatrix coefficients in terms of upper, diagnol and source, I just want to run the darn thing in parallel

 Tags coupled boundary, interface, openfoam