|
[Sponsors] |
October 13, 2006, 06:35 |
Findcell in parallel
|
#1 |
New Member
Magnus Åberg
Join Date: Mar 2009
Posts: 11
Rep Power: 17 |
Hi,
I had some problems defining a momentum source. the first step was to locate the cells that should have nonzero source. If I make the call label point=mesh.findCell(r) // r is vector located in the domain if ( point >= 0) { Info << "cell found"; } It works fine in serial, but when I decompose the domain and run in parallel the cell cannot be found. Did I miss something here? Do I need to explicit loop over the processors or what? I guess this is trivial for most of you so remember; a short answer is infinately more appreciated than no answer Thanks! |
|
October 13, 2006, 06:48 |
Every processor looks for that
|
#2 |
Assistant Moderator
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51 |
Every processor looks for that vector in it's own sub-Grid. Only the one that has the right cell enters the if-statemen. As I understand it (havn't looked at THAT source) the Info-stream is only output for the first processor, all others are mute. So if the point is NOT on the first processor nothing is output (allthough he was found).
My fix (but I'm not very good with that) would be: label point=mesh.findCell(r) { label tmpPoint=myPoint; reduce(tmpPoint,maxOp<label>()); // is point on ANY processor bigger than 0 if ( tmpPoint >= 0) { Info << "cell found"; } } if(point>=0) { // do it only on the processor that HAS this point }
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request |
|
October 13, 2006, 07:26 |
Bernhard is right, if you want
|
#3 |
Senior Member
Eugene de Villiers
Join Date: Mar 2009
Posts: 725
Rep Power: 21 |
Bernhard is right, if you want all processors to be able to report the message, use
Pout << "cell found" Instead of Info. This will prefix the statement with the originating processor number as well (say thanks to Mattijs). |
|
October 13, 2006, 08:58 |
Thanks alot guys!
That rea
|
#4 |
New Member
Magnus Åberg
Join Date: Mar 2009
Posts: 11
Rep Power: 17 |
Thanks alot guys!
That really made me alot clearer on whats going on. Now it works like a charm (Although it should have worked before also but the output was not what i believed it to be). /M |
|
November 10, 2009, 05:15 |
|
#5 |
Senior Member
|
Hi Foamers,
it's possible to use findCell to find a cell on a processor that's different from the local one? If not, is there any workaround to do it? Thanks, Ivan |
|
November 14, 2009, 05:31 |
|
#6 |
Senior Member
Francesco Del Citto
Join Date: Mar 2009
Location: Zürich Area, Switzerland
Posts: 237
Rep Power: 18 |
If I understand your question, a possible solution is to use findCell on all the processors, then reduce the result so that each processor knows where the requested point is.
Hope this helps, Francesco |
|
November 15, 2009, 14:07 |
|
#7 | |
Senior Member
|
Quote:
unfortunately your suggestion can't work, as in my code each cell have to search points that can be on different processors, and findCell finds cells that belong to the local processor... |
||
November 17, 2009, 14:01 |
|
#8 |
Senior Member
Francesco Del Citto
Join Date: Mar 2009
Location: Zürich Area, Switzerland
Posts: 237
Rep Power: 18 |
If it's only one point (I'm writing by heart, so please forgive errors):
Code:
labelList localCellId(Pstream::nProcs(),0); localCellId[Pstream::myProcNo()] = mesh.findCell(YOUR_POINT); reduce(localCellId, maxOp<labeList>()); If you have to look for a point in the mesh, I think that you have to spread this information among all the processors before searching. Each processor can only look for things in its domain, and then can communicate the result of the search operation to the others, if needed. Francesco |
|
September 11, 2012, 05:58 |
related problem
|
#9 | ||
New Member
Fabien Farella
Join Date: Jan 2012
Posts: 7
Rep Power: 14 |
Hi,
I have a somewhat related problem. I want to perform a simple post-processing task (in parallel, using meshsearch). Basically: Quote:
Quote:
(By the way, it is a simplified version of my problem. I am not trying to find offset points outside my mesh, as this sample code would suggest) Do you have an idea why? I have been struggling for quiet a while!!! Thanks, Fabien |
|||
March 5, 2013, 20:40 |
findCell in parallel and reduce
|
#10 |
Member
Jim Carow
Join Date: Apr 2010
Location: Michigan, USA
Posts: 41
Rep Power: 16 |
Fabien & Foamers,
Did you solve this problem? I suspect it may be related to what I am seeing when I loop over cells in a decomposed mesh. Unfortunately, I don't have an answer only another question... Code:
forAll(alpha.internalField(),cellI) { vector centerR = ptsR[cellI]; labelList targetCellId(Pstream::nProcs(),0); targetCellId[Pstream::myProcNo()] = mesh.findCell(centerR); reduce(targetCellId, maxOp<List<label> >()); Pout << "targetCellId: " << targetCellId << endl; } Code:
[3] targetCellId: 4(0 0 0 -1) [1] targetCellId: 4(0 -1 0 0) [2] targetCellId: 4(0 0 -1 0) [1] targetCellId: 4(0 288 0 0) [0] targetCellId: 4{0} [0] targetCellId: 4(1 0 0 0) [3] targetCellId: 4(0 0 0 -1) [2] targetCellId: 4(0 0 -1 0) [2] targetCellId: 4(0 0 -1 0) [0] targetCellId: 4(34 0 0 0) [1] targetCellId: 4(0 289 0 0) [3] targetCellId: 4(0 0 0 -1) [0] targetCellId: 4(35 0 0 0) [1] targetCellId: 4(0 290 0 0) Code:
[0] targetCellId: 4{0} [1] targetCellId: 4{0} [2] targetCellId: 4{0} [3] targetCellId: 4{0} [0] targetCellId: 4(1 288 0 0) [1] targetCellId: 4(1 288 0 0) [2] targetCellId: 4(1 288 0 0) [3] targetCellId: 4(1 288 0 0) [3] targetCellId: 4(34 289 0 0) [2] targetCellId: 4(34 289 0 0) [0] targetCellId: 4(34 289 0 0) [1] targetCellId: 4(34 289 0 0) [3] targetCellId: 4(35 290 0 0) [2] targetCellId: 4(35 290 0 0) [0] targetCellId: 4(35 290 0 0) [1] targetCellId: 4(35 290 0 0) How can I match each CPU's unique findCell request with a unique found cell ID? thanks and regards, James |
|
April 26, 2017, 05:11 |
|
#11 |
Member
Thomas Flint
Join Date: Jan 2016
Posts: 60
Rep Power: 10 |
Has anybody been able to use findCell() in parallel or got a viable work-around? I'm really pulling my hair out over this one.
Thanks |
|
October 2, 2018, 11:02 |
Reply to Thomas Flint on findCells() in parallel
|
#12 |
New Member
Join Date: May 2017
Posts: 2
Rep Power: 0 |
Hi Thomas,
findCells() tries to find the cell index of the given point in each decomposed mesh. If it doesn't find the point, it returns a cell index of -1. You can find what the function does in src/OpenFOAM/meshes/primitiveMesh/primitiveMeshFindCell.C. If you are looking to get the cell index of a single point, you can write an if statement so that your code only runs if the cell index is not -1. For example: Code:
vector position(0.5,0.5,0.5); label cellI = mesh.findCell(position); if (cellI != -1) //if the point is in the sub-mesh { //do stuff } |
|
June 3, 2020, 14:13 |
|
#13 | |
New Member
Konstantinos Missios
Join Date: Mar 2017
Location: Copenhagen, Denmark.
Posts: 12
Rep Power: 9 |
Quote:
Lets suppose that you want to store the velocity and density of a point of interest (myPoint). But at the same time you want your code to be able to handle parallel mode. A possible solution would be: Code:
point myPoint=point(myX,myY,myZ);//initialize the point of interest label myCellId=mesh.findCell(myPoint);//search myPoint in the mesh and return the Cell id(if myCellId!=-1 then the cell is found) vector myU = vector(VGREAT, VGREAT, VGREAT);//initialize velocity vector with a very high value (this will help later on when you use reduce command) scalar myRho = VGREAT; if (myCellId != -1) //if cell is found { myU = U[myCellId];//store values in myU myRho = rho[myCellId]; } reduce(myRho, minOp<scalar>()); reduce(myU, minOp<vector>());//reduce vector Best, Konstantinos |
||
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
parallel cfd | venkatesh | FLUENT | 3 | November 13, 2011 05:45 |
On Parallel ? | Kate Frack | Main CFD Forum | 0 | February 8, 2007 09:30 |
FindCell | evgenii | OpenFOAM Pre-Processing | 1 | February 15, 2006 05:43 |
UDF in Parallel | Gavin | FLUENT | 1 | June 19, 2005 22:17 |
CFX-5.5 Parallel NT | Kawena | CFX | 4 | March 13, 2002 20:24 |