Face weighted Velocity average at a boundary patch
Hi everybody,
I am currently trying to implement the calculation of a cell face weighted Velocity average in flow direction as a dimensioned scalar. The cell face for weighting shall be the one at the defined boundary patch. I tried: Code:
dimensionedScalar weightedVelocity = (flowDirection & U)().weightedAverage(mesh.boundary()[patchID].Sf()); Code:
error: no matching function for call to ‘Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::weightedAverage(const Foam::Field<Foam::Vector<double> >&)’ Code:
dimensionedScalar weightedVelocity = average(flowDirection & U.boundaryField()[patchID]); Code:
--> FOAM FATAL ERROR: Thanks for your answers, Cheers Lu |
Greetings Lukas,
I did a quick search on this subject and found this thread: http://www.cfd-online.com/Forums/ope...onditions.html From it you'll see that they mention patchAverage. The source code for this application is located here: "applications/utilities/postProcessing/patch/patchAverage/patchAverage.C" If I'm not mistaken, this code uses area weighted average on patches. If you need to integrate, looks like patchAverage has a sibling named patchIntegrate ;) Best regards, Bruno |
Hi Bruno,
thanks for your answer, I also stumbled upon this thread during my search for a solution. The problem is that I want to integrate the calculation into my solver and use the average value as a corrector. As far as I can see this is just for post processing. But I'll have a closer look at patchAverage, maybe it'll help. I'll post the solution when I found it. Cheers Luk |
Hello again Bruno,
hello everybody, I worked something out now but only for serial computation. In parallel it does not work because the area of the patch on which I want to average is not calculated properly. My code for that is: Code:
label PatchID = mesh.boundaryMesh().findPatchID(patchName); I appreciate your help, Luk /edit: Now I added an output to see what the areas of the surface on the different processors are: It gives: Code:
[3] area_proc: 0 |
Hi Lukas,
That's strange, the code seems good enough to work in parallel as well. Have you tried running patchAverage with your case, both in serial and parallel? Because if patchAverage is not working correctly, then the problem could be in OpenFOAM itself! Best regards, Bruno |
Hi Bruno,
first of all thanks for concerning yourself with my stuff. I tried to run the patchAverage on my case in parallel. Since I want to run in on the x-Component of the velocity in my solver I first did the foamCalc operation: Code:
lukas@cluster:/scratch/luk/testcase$ mpirun -np 16 foamCalc components U -parallel Code:
lukas@cluster:/scratch/luk/testcase$ mpirun -np 16 patchAverage Ux INLET -parallel Up to now I'm a bit clueless on the reason but I'll try the patchAverage on the pitzDaily tutorial later in paralell to verify that the problem is not in my case. So long, best regards, Lukas |
Hi Lukas,
Which OpenFOAM version are you using? I've used both OpenFOAM 2.1.1 and 2.1.x, did a quick test with the tutorial "multiphase/interFoam/laminar/damBreak" in both serial and parallel with these commands: Code:
blockMesh I haven't tried on a cyclic patch yet... I'll have to find a tutorial first... I'll edit this post if and when I find one and test it. edit: I've tested with the tutorial "incompressible/pimpleFoam/TJunctionFan", by modifying the last line in Allrun from this: Code:
runApplication $application Code:
runApplication decomposePar Code:
cp $FOAM_TUTORIALS/multiphase/interFoam/laminar/damBreak/system/decompo* system/ Code:
./Allrun Code:
patchAverage p fan_half0 edit2: The other corresponding cyclic patch "fan_half1" gave veeeery different values, by about an order of magnitude of 10x! For comparison, at time = 1.5s and "p" field:
I'm going to test with scotch decomposition instead of simple, because the cyclic patch was split between 2 processor sub-domains... edit3: With scotch decomposition the patch wasn't split:
Best regards, Bruno |
Hi Bruno,
hi all. first of all thank you Bruno for your help, your last sentence gave the hint on the actual bug which is in both my code and the patchAverage tool. I used OFv 2.1.0 for all the previous and following stuff. I ran the tutorials you gave and got the same results, but what lightened me up was the channel395 tutorial which works with channelFoam. When a cyclic case is decomposed the and the processor boundary is at the cyclic patch the patch is reassigned from e.g. "INLET" to "processorXtoprocessorYthroughINLET". The "INLET" patch however will still be present in the files. This yields that Code:
label PatchID = mesh.boundaryMesh().findPatchID(patchName); Well that is that. Since I still want my solver to work I now need the patch ID's of all patches which involve the string stored in patchName in their name. Is there something like a wildcard in openFoam like findPatchID(.*patchName) (seen it the BCs of the motorbike tutorial)? (This does not work, I already tried it :D). Since the class for one single patchID was label I tried to extract the patchIDs of all patches which contain the string stored in patchName as a labelList as follows: Code:
labelList UbarPatches; Thanks in advance, your help is appreciated! Best regards, Luk |
Hi Lukas,
There is a somewhat easier way to take care of this. Using as a reference the previous example tutorial:
Best regards, Bruno |
Works perfectly fine. Thank you very much!
|
Hey guys,
I am trying to calculate the patch average value of phi (or mass flux) when running in parallel. I have written the code below which works well for serial computation. is there any suggestion how to make it work for parallel computation? word inletPatchName = "inflow_cyclic"; //access boundary elements const fvPatchList& patches = mesh.boundary(); //loop over boundaries forAll(patches, patchI) { const fvPatch& cPatch = patches[patchI]; //check boundary name if(cPatch.name() == inletPatchName) { //loop over all faces of selected //boundary forAll(cPatch, faceI) { //calculate boundary face mass flux dimensionedScalar cFaceFlux = phi.boundaryField()[patchI][faceI]*magUbar; //sum face mass fluxes massFluxInlet += mag(cFaceFlux); |
Hi pooyan,
Which decomposition method do you use? Have you used the preservePatches option for your cyclic patches? Best regards, Lukas |
I have used simple method. And have included preservePatches(cyclic boundaries) in the decomposeParDict. Even when I use simple method and use (4 1 1), I expect that the decomposition is made in x direction, so only one processor is working on my inflow_cyclic and therfore It should be able to calculate the right flux. Any suggestion?
Thanks |
Hi pooyan,
sorry for replying late but i was out of office for a few days. Actually I have no idea why it does work in serial but not in parallel. But I think I have a general problem with understanding your calculation. You want to calculate the "average value of the flux over your inlet patch" is this correct? Your computation: Quote:
You could do an averaging with the number of faces considered. But imo you should calculate a flux average weighted with they area of the considered faces. Something like Code:
scalar area = gSum(mesh.magSf().boundaryField()[patchI); // Total area of your boundary Patch Regards Luk |
All times are GMT -4. The time now is 07:08. |