|
[Sponsors] |
Matrix coefficients from boundary conditions how |
![]() |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
![]() |
![]() |
#1 |
Senior Member
Thomas Jung
Join Date: Mar 2009
Posts: 102
Rep Power: 17 ![]() |
Hello,
I am trying to understand implementation of boundary conditions... Simple question: Why is e.g. when using a fixedGradientFvPatchField gradient(internal/boundary)Coeffs called, but not value(Internal/Boundary)Coeffs ? If I want to implement an implicit b.c. (flux depending on current value), how can I make Foam to call valueInternalCoefficients? Deriving from a different FvPatchField? Thank you very much for any hint ! |
|
![]() |
![]() |
![]() |
![]() |
#2 |
Senior Member
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,907
Rep Power: 33 ![]() |
Hello Thomas,
First, a word of warning: this is not easy. I hope you know your onions as far as finite volume method is concerned :-) I will limit my discussion to non-coupled boundary conditions: in other words, this does not apply for a cyclic, processor and other boundary types which formally create off-diagonal matrix coefficients. Every boundary condition of what is left is implemented by adding a contribution to the diagonal and right-hand-side (source) of the cell next to it. The address of the cells is obtained by doing faceCells on the patch - just for your info. Each boundary condition (of second order) can be expressed as a combination of a fixed value (Dirichlet) and fixed gradient b.c. Additionally, you have to worry about what operator the boundary condition works on: convection or diffusion. When you look at the class fvPatchField, you will see for relevant functions: - valueInternalCoeffs - valueBoundaryCoeffs - gradientInternalCoeffs - gradientBoundaryCoeffs The idea is that the first two give you the internal (read: diagonal coefficient) and boundary (read source) contribution for the convection term. The second two do the same for the diffusion term. The basic stuff will be found in the fixedValue, fixedGradient and mixed fvPatchFields. Now that you got all that, we should tallk about your particular problem. I bet (might lose, but it is unlikely) that your boudnary condition is a combination of a fixed value and fixed gradient, where the value, gradient and value fraction (= mix) depend on some other conditions in the field. If this is the case, you should derive your boundary condition from mixed, set the refValue, refGradient and valueFraction based on what you wish to do and let the mixed b.c. do the rest of the job for you. For vectors and tensors, there are some pretty comlicated ways of mixing things, e.g. separate mixed b.c. in the normal and tangential component like the stuff I did for the contact stress analysis with friction, but that's another story. Hope you understand most of the above (otherwise there may be trouble) :-) Enjoy, Hrv
__________________
Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk |
|
![]() |
![]() |
![]() |
![]() |
#3 |
Member
Stefan Radl
Join Date: Mar 2009
Location: Graz, Austria
Posts: 82
Rep Power: 18 ![]() |
Dear Foamers,
despites Hrvojes warning I've tried to implement my own boundary condition which shall represent convective heat transfer in the gas phase, i.e., a variable surface gradient of the temperature field in e.g. a solid. The gradient should be computed from dT/dx=-alpha/lambda*(T_surface-T_gas,bulk) with alpha, lambda, T_gas,bulk being constants and T_surface the temperature at the cell face of the boundary batch. Using the core of the mixed or fixedGradient boundary condition, this can be done quite easily. The remaining problem is to get the surface temperature (T_surface) out of the matrix for evaluating the gradient field in the "evaluate" member function. Ironically, this evaluate function should calculate the value at the patch boundary, so this might be trivial Can anybody give me a hint how to conveniently get this surface scalarField for the temperature? Has anybody ever implemented something similar? br Stefan Radl |
|
![]() |
![]() |
![]() |
![]() |
#4 |
Senior Member
Thomas Jung
Join Date: Mar 2009
Posts: 102
Rep Power: 17 ![]() |
Hi Stefan,
I believe you should calculate your surface temperature, which is a result from your prescribed gradient, like this: scalarField::operator= ( (this->patchInternalField() + gradient()/this->patch().deltaCoeffs()) ); ... but this is just another noobs opinion ![]() regards, Thomas |
|
![]() |
![]() |
![]() |
![]() |
#5 |
Member
Stefan Radl
Join Date: Mar 2009
Location: Graz, Austria
Posts: 82
Rep Power: 18 ![]() |
Hi,
thanks for your opinion, but it does not work :-) I can get the patchInternalField, which should represent the temperature in the cell centers of the patch cells. However, this seems to be a tensor field (the compiler complains about that when I try to subtract it from a scalarField)!! Consequently, I'm unable to calculate the difference between T_gas,bulk and this patchInternalField, which is clearly to me. The question now is: how is this tensor interelated with the scalarField of the patch-temperature and how can I get it? Any suggestions? br Stefan Radl |
|
![]() |
![]() |
![]() |
![]() |
#6 |
Senior Member
Thomas Jung
Join Date: Mar 2009
Posts: 102
Rep Power: 17 ![]() |
Hmmm...
I am calculating a gradient at the surface like this (in updateCoeffs(), for a radiation boundary condition. epslam is a factor containing thermal conductivity and emissivity. *this gives the field values at the surface. I think this is pretty much the same you want to do, for me it works. gradient() = 5.67051e-8*epslam_*(-(*this)*(*this)*(*this)*(*this)+TRef_*TRef_*TRef_* TRef_); in evaluate(), then, I do this, using underrelaxation: scalarField::operator= ( (1-relax_)*(*this)+relax_*(this->patchInternalField() + gradient()/this->patch().deltaCoeffs()) ); Works, and reults compare well with results from other programs. regards, Thomas |
|
![]() |
![]() |
![]() |
![]() |
#7 |
Member
Stefan Radl
Join Date: Mar 2009
Location: Graz, Austria
Posts: 82
Rep Power: 18 ![]() |
Dear Thomas,
thanks for that hint. Let me ask you some more questions. 1) What have you used as a basis for your boundary condition c-file (maybe fixedGradientFvPatchFields.C ?) 2) What are the declarations for gradient, TRef? (maybe Field<type> or scalarField) 3) Are you compiling your boundary condition file together with the solver or are you creating a library and then linke this library to the solver? I'm really wondering why you can have a scalar field in the evaluation function as in the fixedGradientFvPatchFields.C you have a Field<type>. I'm really confused about that my compiler calls for a tensor instead of a scalar. Would be great if you can send me your code to my email adress stefan <dot> radl <at> tugraz <dot> at to sort out this nasty issue. br Stefan Radl |
|
![]() |
![]() |
![]() |
![]() |
#8 |
Member
Stefan Radl
Join Date: Mar 2009
Location: Graz, Austria
Posts: 82
Rep Power: 18 ![]() |
Dear Thomas,
thanks for your explanation, with your guidance I did it!! A first test with a single cylindrical slab agrees with the analytical solution, so your/my implementation should be correct. The problem was that I declared the variable as "Field<type>", i.e., valid also for matrices. Now everything is set to a scalarField and it works. I've not used the underrelaxation, the simulation is stable without it. br Stefan Radl |
|
![]() |
![]() |
![]() |
![]() |
#9 |
New Member
Sam Lee
Join Date: Mar 2009
Location: Shanghai, P.R.China
Posts: 4
Rep Power: 17 ![]() |
Hi, Hrvoje Jasak and others
I read your post concerning the boundary condition using following functions - valueInternalCoeffs - valueBoundaryCoeffs - gradientInternalCoeffs - gradientBoundaryCoeffs I understood that convection term is using value of the boundary while the diffusion term is using the gradient of the boundary. I think that is why those function names are used? but, I am confused about the concept of diagonal and source of cell which differentiates two functions in one group. would you please explain that a little bit? any hint will be appreciated. thanks all |
|
![]() |
![]() |
![]() |
![]() |
#10 | |
Member
George Pichurov
Join Date: Jul 2010
Posts: 52
Rep Power: 16 ![]() |
Quote:
Last edited by jorkolino; December 20, 2010 at 03:40. |
||
![]() |
![]() |
![]() |
![]() |
#11 |
Member
Nicolas Lussier Clément
Join Date: Apr 2009
Location: Montréal, Qc, Canada
Posts: 61
Rep Power: 17 ![]() |
Hi jorkolino,
fvPatchField is a virtual class. Meaning that you cant instantiate it. To do so you will need to create a class from this one like all the other patch class. Wath you are tiring to do by instantiate fvPatchField is like tiring to create a object character in a RPG video game. The game as character object but you cant create a "character" you will need to choose which kind of character... fvPatchField is there to define what is a patch so every patch will be child of fvPatchField. Ther is a auto pointer class "autoPtr" that will aloud you to instantiate a virtual class. In some case it is useful but I'm guessing in your case it will be useless. ![]() For the question about LMA, I'm sorry to tel you that I don't understand the question and I probably don't know the answer. Hope you got the answer you wanted and that this helped you some. Regards Nicolas L. |
|
![]() |
![]() |
![]() |
|
|
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Burgerbs equation non constant Boundary Conditions Initial Conditions | arkangel | OpenFOAM Running, Solving & CFD | 1 | October 2, 2008 15:48 |
Addressing matrix element and reuse of system matrix | marziolettich | OpenFOAM Running, Solving & CFD | 2 | February 19, 2008 06:04 |
Integral boundary conditions turbulent intensitylength boundary conditions | olesen | OpenFOAM Running, Solving & CFD | 0 | July 27, 2006 08:18 |
matrix coefficients | dominik | Main CFD Forum | 0 | June 10, 2004 04:47 |
Elemtary matrix to CSR global matrix | xueying | Main CFD Forum | 2 | September 24, 2002 10:44 |