|
[Sponsors] |
November 27, 2012, 16:20 |
fvPatchFields - Description
|
#1 |
Member
Vitor Vasconcelos
Join Date: Jan 2012
Posts: 33
Rep Power: 14 |
Hello all,
I'm studying how to implement a variable gradient boundary condition for temperature. Reading the OpenFOAM official documentation, most of the classes have no *detailed description*. So my problem arises: how to know from which class derive my class? Of course I have a vague idea, but there is any more complete documentation about the set of classes implementing BCs? Second question in the same post: any explanation on what is the *fvsPatchField* class? I mean, what does this "s" means? Thanks a lot and sorry for any elementary question, but OpenFOAM documentation lacks some basic information to allow newcomers to "walk by themselves". Vitor |
|
November 28, 2012, 04:26 |
|
#2 |
Senior Member
Mohammad Shakil Ahmmed
Join Date: Oct 2012
Location: AUS
Posts: 137
Rep Power: 15 |
(1) *detailed description*--> For detailed description you can browse through the OpenFoam C++ documentation- (http://foam.sourceforge.net/docs/cpp/index.html) here all the class are listed, and also have UML diagram which represents the base and derived class
(2) "how to know from which class derive my class?"---> probably you have to read out the programmer's guide briefly, and there are several tutorials-and workshop slides for these stuffs.... dig them out!!! (3)"*fvsPatchField* class?"---> An abstract base class with a fat interface to all derived classes covering all possible ways in which they might be used. For newcomers, it would be better to worked out the various tutorials and workshop files.... |
|
November 28, 2012, 06:53 |
|
#3 |
Member
Vitor Vasconcelos
Join Date: Jan 2012
Posts: 33
Rep Power: 14 |
Thank you ahmmedshakil,
Just to clarify, I have a background in Computer Science. I'm quite new to CFD field. (1) *detailed description*--> For detailed description you can browse through the OpenFoam C++ documentation- (http://foam.sourceforge.net/docs/cpp/index.html) here all the class are listed, and also have UML diagram which represents the base and derived class Believe me, I have been reading it in a daily basis. The *description* field is missing in MANY classes. That's the information I'm looking for. I need to understand the meaning of the classes, not only its interfaces. I know there is a bunch of different field classes, but would be great to have a DESCRIPTION to be able to know where/why one class was planned to be used. Another example? The turbulentHeatFluxTemperatureFvPatchScalarField has a description, but when trying to use it it's still necessary to "guess" you need to define a KName (which is not in the class description). These are only some examples... (2) "how to know from which class derive my class?"---> probably you have to read out the programmer's guide briefly, and there are several tutorials-and workshop slides for these stuffs.... dig them out!!! Sorry, but I assure you it's easier to get to the class information than in this forum. Let's say I am a newby, but no so newby. (3)"*fvsPatchField* class?"---> An abstract base class with a fat interface to all derived classes covering all possible ways in which they might be used. Oh, great. Do you realize that this quote of the documentation of fvsPatchField class means ABSOLUTELY NOTHING? So, can you answer a simple question? What the S means in this class? Why is it defined and what the diference to fvPatchField classes? Please, don't say to me to look inside the source code. I can do that, I only don't have time to read the entire source code. I do that OFTEN. But even reading and re-reading the code it's IMPOSSIBLE to have an answer (sometimes only a guess). I'm sorry, but I'm very tired from this kind of answer "check the source code, check the documentation". Believe me, it's not funny to write here and bother you with questions. If I could, I would be doing my job without wasting your time in the forum. Regards, Vitor |
|
November 28, 2012, 07:40 |
|
#4 |
Senior Member
Mohammad Shakil Ahmmed
Join Date: Oct 2012
Location: AUS
Posts: 137
Rep Power: 15 |
Hi vitor,
I can feel your situation because I was in same sort of situation as like you.And I think I am still a newbie.But what I did to know about some issues- read out the forum and read out the work shop files. |
|
November 28, 2012, 07:56 |
|
#5 |
Member
Vitor Vasconcelos
Join Date: Jan 2012
Posts: 33
Rep Power: 14 |
Thank you ahmmedshakil,
I'll keep checking the forum and investigating the documentation and source code. I don't know about you, but I have nobody around me which works with OpenFOAM, so I really rely on this forum to keep moving. Good luck to us! Vitor |
|
November 28, 2012, 08:10 |
|
#6 |
Senior Member
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Copenhagen, Denmark
Posts: 1,902
Rep Power: 37 |
Hi Vitor,
The difference between fvPatchField and fvsPatchField is that the former gives boundary conditions for volField<Type>, whereas the latter describes boundary conditions for surfaceField<Type>. In the private data section of fvPatchField.H and fvsPatchField.H a reference to the internalField is declared. They read Code:
const DimensionedField<Type, volMesh>& internalField_; Code:
const DimensionedField<Type, surfaceMesh>& internalField_; I hope this has helped you to understand things better. Kind regards, Niels |
|
November 28, 2012, 08:15 |
|
#7 |
Member
Meindert de Groot
Join Date: Jun 2012
Location: Netherlands
Posts: 34
Rep Power: 14 |
Hi Vitor,
The difference between the fvPatchField and fvsPatchField is that the fvPatchField takes a volField as an argument and the fvsPatchField takes a surfaceField as an argument. |
|
December 10, 2012, 17:22 |
|
#8 |
Member
Vitor Vasconcelos
Join Date: Jan 2012
Posts: 33
Rep Power: 14 |
Hello fellows,
I'll start replying myself. Sorry for that. I've been doing research and diving into openfoam C++ documentation. I got some interesting results, but I am kind of stucked again. I am implementing a BC based of fixedValueFvPatchField. Althought I want to change values in the future, I'm using this as base class as a training to understand openFoam BC's rationale. Right now I'm able to read faces from my patch and, for example, get the normals of these faces. Quite promising, but I have two big doubts about how things work. First one: I created a mesh (following a former post of this forum) and based on it I got my patch (it is a wall which is a heat source) and was able to iterate over it face by face. I could do it using the mesh but I also tried to use a *this of my class. With both I got the same result. However, in my 0/T file I started my variable as nonuniform scalar from 1 to 840, which are the number of faces I have (attached are the my geometry). My point is: how to access the different temperatures of each cell? I was wondering it could be stored as "weights" for faces. But the face.normal() and face.mag() are always the same. My mesh is hexaedrical and, in fact, all faces have the same size. However, the nonuniform values are clearly different from cell to cell. Which data strucutres should I read? The second point is also inside the first? is it ok to use a IOobject mesh to get values or is better to use this->patch().patch()? My code is also attached. Sorry for the mess, but it is full of "Info" and very personal comments. Code:
template<class Type> cosFixedValueFvPatchField<Type>::cosFixedValueFvPatchField ( const fvPatch& p, const DimensionedField<Type, volMesh>& iF, const dictionary& dict ) : fixedValueFvPatchField<Type>(p, iF), refValueLow_("refValueLow", dict, p.size()), refValueHigh_("refValueHigh", dict, p.size()), startRamp_(readScalar(dict.lookup("startRamp"))), endRamp_(readScalar(dict.lookup("endRamp"))), curTimeIndex_(-1) { if (dict.found("value")) { fixedValueFvPatchField<Type>::operator== ( Field<Type>("value", dict, p.size()) ); } else { Info << "|||||||||||| Entered fixedValue operator== |||||||||||\n" << endl; fixedValueFvPatchField<Type>::operator== ( refValueLow_ ); } // Tentativa de ler o valor da gravidade uniformDimensionedVectorField gv(IOobject ("g", this->db().time().constant(), this->db(), IOobject::MUST_READ, IOobject::NO_WRITE) ); Info << "---- Saida g: " << gv << endl; //Tentando variar os valores do proprio campo (patchField) // Cria o mesh Foam::fvMesh mesh(Foam::IOobject( Foam::fvMesh::defaultRegion, this->db().time().timeName(), this->db().time(), Foam::IOobject::MUST_READ )); // Trying to understand the mesh and polypatch relation label patchID = mesh.boundaryMesh().findPatchID("combustivel"); Info << "patchID: " << patchID << endl; // const polyPatch& patchFound = mesh.boundaryMesh()[patchID]; const polyPatch& patchFound = this->patch().patch(); Info << "patchFound: \n" << patchFound << endl; labelList labelPatchFound( patchFound.meshPoints() ); Info << "Tamanho da lista de pontos: " << labelPatchFound.size() << endl; vectorList faceNormals(patchFound.size(), vector::zero); scalarList faceMag(patchFound.size()); Info << "Face inicial: " << patchFound.start() << endl; labelList minhasFaces(patchFound.faceCells()); Info << "Tamanho da lista de faces: " << minhasFaces.size() << endl; // Verificando as direcoes do mesh Info << "geometricD: " << mesh.geometricD() << endl; // Tentar extrair apenas as faces com a normal no x positiva pointField meshPoints(mesh.points()); unsigned int pr = 0; forAll(patchFound, faceI) { // const face& myFace = mesh.boundaryMesh()[patchID][faceI]; const face& myFace = this->patch().patch()[faceI]; faceNormals[faceI] = myFace.normal(mesh.points()); // faceMag[faceI] = myFace.mag(mesh.points()); if(faceNormals[faceI].x() > 0) { //Info << faceNormals[faceI] << " "; Info << faceI << " "; pr++; } } Info << "\n\n--- Numero de faces com normal x positiva: " << pr << endl; const scalarField& pesos = this->patch().weights(); Info << "size of scalarField: " << pesos.size() << "scalarField: \n" << pesos << endl; } Vitor |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
mass flow in is not equal to mass flow out | saii | CFX | 12 | March 19, 2018 06:21 |
error message | cuteapathy | CFX | 14 | March 20, 2012 07:45 |
Constant velocity of the material | Sas | CFX | 15 | July 13, 2010 09:56 |
Two-Phase Buoyant Flow Issue | Miguel Baritto | CFX | 4 | August 31, 2006 13:02 |
Transient natural gas flow description | Leila | FLUENT | 0 | November 29, 2003 17:06 |