CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Programming & Development (https://www.cfd-online.com/Forums/openfoam-programming-development/)
-   -   low-level use of fvMatrix (https://www.cfd-online.com/Forums/openfoam-programming-development/80213-low-level-use-fvmatrix.html)

 Conny_T September 19, 2010 09:27

low-level use of fvMatrix

Hi everybody,
is the fvMatrix class general enough to represent equation systems that do not only come from finite volume discretization? The reason for my question is the following. For some internal cells of a finite volume problem I want to remove the standard discretization and instead impose a condition like "the sum of the cell values y_k1...y_kL is equal to 1". Basically I must be able to replace any row i in a fvMatrix with an arbitrary linear combination (ai1...aiN)*(y1...yN)=bi.

Related to this is my second question. The right hand side "bi" above may be coupled to another equation system. Is it possible to increase the number of rows and columns in an fvMatrix to add additional variables and constraints to the system?

Please let me know if I can find examples somewhere how to
1) modify individual rows
2) extend an fvMatrix with additional rows and columns

The background of my question is to couple minimization using lagrange multipliers with the finite volume discretization, but even though I know that there are other means to do this, I'd need to know how to modify the coefficients of an fvMatrix. I only found the diag(),lower(),upper() and source() methods, but I don't understand how to combine cell values that are not direct neighbours, not to mention additional constraints that are not at all represented by any cell value.

Thanks
Conny

 santiagomarquezd September 20, 2010 09:31

Conny

Quote:
 The background of my question is to couple minimization using lagrange multipliers with the finite volume discretization, but even though I know that there are other means to do this, I'd need to know how to modify the coefficients of an fvMatrix. I only found the diag(),lower(),upper() and source() methods, but I don't understand how to combine cell values that are not direct neighbours, not to mention additional constraints that are not at all represented by any cell value. Thanks Conny
fvMatrix inherits from lduMatrix

Code:

```00072 /*---------------------------------------------------------------------------*\ 00073                            Class lduMatrix Declaration 00074 \*---------------------------------------------------------------------------*/ 00075 00076 class lduMatrix 00077 { 00078    // private data 00079 00080        //- LDU mesh reference 00081        const lduMesh& lduMesh_; 00082 00083        //- Coefficients (not including interfaces) 00084        scalarField *lowerPtr_, *diagPtr_, *upperPtr_;```
the only info you have stored in the class is that is related with matrix non-zero coefficients,
only have information from shared faces, then if you want to add some other
coefficients info won't be consistent with the mesh. Maybe you can use the Foam::Matrix
class which is intended for full matrices storage or code your own generic
sparse matrix class.

Hope this info be useful.

Regards.

 Conny_T September 20, 2010 14:41

Yes, your info is helpful. So I give up OpenFOAM, because there is no solution to my problem.

Using the Matrix class is out of the question for any but the smallest problems.

Using more powerful sparse matrix packages comes close to rewriting everything except for lduMatrix.

I also had a look at cyclicFvPatchField and found that it does not actually couple non-adjacent boundary patches, but instead copies the values around in each iteration. Maybe this is another hint that lduMatrix cannot be used for advanced cell couplings?

Thanks
Conny

 santiagomarquezd September 20, 2010 14:54

Hmm, I don' know anything about the part of coupling, but respect of the matrices, the storing method is useful but it is necessary to have extra Addr arrays in order to be capable to address more coefficients than only which corresponds to shared faces. On the other hand FOAM is specially designed to avoid second neighbors, then changing this paradigm maybe force you to re-implement a lot of other things. At this point more experienced users/developers must give their opinions.