Hello,
I am trying to under
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 ! 
Hello Thomas,
First, a word
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 noncoupled boundary conditions: in other words, this does not apply for a cyclic, processor and other boundary types which formally create offdiagonal matrix coefficients. Every boundary condition of what is left is implemented by adding a contribution to the diagonal and righthandside (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 
Dear Foamers,
despites Hrvo
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_surfaceT_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 
Hi Stefan,
I believe you sh
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 http://www.cfdonline.com/OpenFOAM_D...part/happy.gif regards, Thomas 
Hi,
thanks for your opinion
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 patchtemperature and how can I get it? Any suggestions? br Stefan Radl 
Hmmm...
I am calculating a gr
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.67051e8*epslam_*((*this)*(*this)*(*this)*(*this)+TRef_*TRef_*TRef_* TRef_); in evaluate(), then, I do this, using underrelaxation: scalarField::operator= ( (1relax_)*(*this)+relax_*(this>patchInternalField() + gradient()/this>patch().deltaCoeffs()) ); Works, and reults compare well with results from other programs. regards, Thomas 
Dear Thomas,
thanks for tha
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 cfile (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 
Dear Thomas,
thanks for you
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 
diagonal and source of cell?
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 
Quote:

instantiate a virtual class
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. 
All times are GMT 4. The time now is 04:34. 