[Conny_T]

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]

Conny

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

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,
their position is given by uppperAddr and lowerAddr arrays. These arrays
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]

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]

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.

Good luck with your job.

Santiago.