|
[Sponsors] |
Retrieving boundary patch values adjacent to a given cell |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
March 16, 2006, 18:06 |
So, I have an OpenFOAM code th
|
#1 |
Guest
Posts: n/a
|
So, I have an OpenFOAM code that's creating output files based on the values in a mesh created using blockMesh on a single block. At this point, everything's working reasonably nicely for the cell-centered values.
What I'd now like to include is values on the outer boundaries of the block. Specifically, given a cell that I happen to know is on a face of the block, I'd like to get the values of U and p on its face that's on the boundary patch. (Or, if it's on an edge or corner, the values on all of the relevant faces.) Is this possible? How would I go about it? What bits of code should I look at for a starting point? Thanks! |
|
March 17, 2006, 03:19 |
Two ways (the clever one and t
|
#2 |
Senior Member
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,906
Rep Power: 33 |
Two ways (the clever one and the round-about one).
If you want lots of faces and cells, go onto the boundary patch and as for faceCells(), which gives you cells on the inside of the patch. This is good if you want to do lots of them, but if you only want one face of one cell, that would involve search, which is not good. This would look something like: const fvPatchVectorField& patchU = U.boundaryField()[patchI]; const labelList::subList fc = patchU.patch().faceCells(); blah blah. The second way is to go directly from the cell to the patch face. So assuming you know the cell index, you will ask for its faces and then go through them and ask "which patch does this face belong to". Because of my clever ordering stuff :-) this does not involve searching. So: faces of cell const cell& c = mesh.cells()[cellI]; // a cell is a list of faces forAll (c, i) { // This gives you the patch ID for a face. If the face is internal, you get -1 label patchID = mesh.boundaryMesh().whichPatch(c[i]); if (patchID > -1) { label faceID = mesh.boundaryMesh()[patchID].whichFace(c[i]); blah blah } } The faceID gives you the face index in the patch. You can now recover the boundary face value as: U.boundaryField()[patchID][faceID]; For internal faces, (say, if you want the flux), you firs find out that it is internal (whichPatch gives -1), and then you ash phi.internalField()[c[i]]; to get the value. Beware, the internalField() function is not trivial and if you're doing this lots, you should take a local reference. Enjoy, Hrv P.S. Nice question!
__________________
Hrvoje Jasak Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk |
|
December 8, 2008, 10:00 |
Hi,
I have written a postpr
|
#3 |
Member
Niklas Winkler
Join Date: Mar 2009
Location: Stockholm, Stockholm, Sweden
Posts: 73
Rep Power: 17 |
Hi,
I have written a postprocessing solver for which I want to set some boundaries as fixed and some as zeroGradient. To check that the zeroGradient boundaries actually are zeroGradient after the postprocessing step I've used the function fvc::snGrad at the faces on the specific boundary found according to the 2nd method suggested above. I believe snGrad should give me the gradient normal to each face and if it's numerically zero then the zeroGradient condition is fulfilled. As a test I've tried to calculate snGrad for all faces, both internal and external for a totally uniform field. The problem is that snGrad gives me zero within numerical accuracy for the internal faces, approx. 0.16 for most faces on the boundary and zero for some faces on the boundary. Is there an explanation for this? Is it ok. to use snGrad on the boundary since it normally uses the 2 cells closest to the face? Is there a better or more correct way of checking that the zeroGradient condition is numerically fulfilled? Thanks (and I'm really enjoying OF!) /NW |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
In reply to: "only one adjacent cell thread." | Krystian | FLUENT | 0 | August 27, 2008 20:39 |
adjacent cell zones | Louisa | FLUENT | 4 | August 31, 2007 06:49 |
Retrieving the values stored in UDM | Sri | FLUENT | 2 | March 1, 2007 16:48 |
Adjacent cell number | Jing | Siemens | 5 | October 21, 2002 06:29 |
two adjacent cell zones. | Thejasvi | FLUENT | 3 | November 26, 2001 08:35 |