[T.D.]

Hello Foamers,
Recently i was stuck with "const unallocLabelList& mesh.cellCells()". Here it is the story:

I am trying to create a spatial filter based on number of levels for neighbourhood cells but that can be limited to a predefined user disk (or sphere if 3D) of radius R for neighbourhood cells.
The filter loops overall mesh cells and for each cell it must identify only all the neighbourhood cells which are lying inside the disk of radius R.

The filter is as the following:
C_i = sum(C_n * H_ni) / sum(H_ni) with i=cell index, n=neighbourhood cell index
and H_ni = R - mag(C_i - C_n)

I followed an approach of a recursive function in a class to do this by calling itself, but the problem lies in the neigbours of neigbours indices update using the cellCells() function. I can not update the indices each time after calling my function due to the nature of const unallocLabelList& ? so any ideas ? i tried all like dynamic lists and labelList pointers, etc..
also I tried to do this filter by modifying the already class member functions fvc::average(), or spread(), etc.. but without success !

Any help or ideas ?? any other proposed approaches will be welcomed ..

Thanks

Best Regards,

T.D.

[wyldckat]

Quick answer: The only things that come to mind right now are:

1. Have you taken a look at how OpenFOAM deals with filtering in LES and IDDES?
2. If I remember correctly, "wallDist" uses a wave algorithm for calculating distances. It might be of use to you as well.

[T.D.]

Originally Posted by wyldckat

Quick answer: The only things that come to mind right now are:

1. Have you taken a look at how OpenFOAM deals with filtering in LES and IDDES?
2. If I remember correctly, "wallDist" uses a wave algorithm for calculating distances. It might be of use to you as well.

Hi wyldckat, thanks a lot. Yes, really, i was looking at what is done with LES the last week. But with no success.. i will look at the "wallDist", and IDDES..

Thanks a lot,

Best regards,

T.D.

[wyldckat]

Hi T.D.,

I hope you don't mind, but I'll answer the question you sent me via PM here on this thread of yours:

Originally Posted by T.D.

Do you have an idea how to get the mesh.C().cellCells() or mesh.C().pointCells() to work in parallel computations ?

I need a practical example of what you're trying to do. A simple test case+code would make it easier to diagnose.

Originally Posted by T.D.

If you know any suggestions or tutorials to start initiation in parallel programming with openfoam will be great.

The best I can remember right now is my blog post: Notes about running OpenFOAM in parallel - but I can't remember any specific tutorials on how to code these things... let me see if I can find an answer I gave someone else who didn't ask me things publicly... OK, here is a snippet:

Originally Posted by wyldckat

I'm not able to list out all of the possible problems, but in a nutshell:

• OpenFOAM is only able to automagically parallellize fields, such as "U" and "p_rgh".
• Anything else, such as lists of points that are farthest from one particular point, has to be joined in the master process or distributed to all processes.
• In addition, you must be extremely careful with accesses to data on certain temporary fields.

In other words, you should always follow the same design that OpenFOAM has got as a nearly-perfect code. Any code you try to hack in without following OpenFOAM's own coding guidelines, will likely result in problems when running in parallel.

As for code examples, look at the source code of other solvers and utilities that OpenFOAM has got.

And I know I answered someone recently about Test-parallel... mmm, it was this one: http://www.cfd-online.com/Forums/ope...ging-list.html
As for searching techniques: http://openfoamwiki.net/index.php/In...hing_for_files

Good luck! Best regards,
Bruno

[T.D.]

Hi Bruno,

Thanks

Here my example as the following:

I am doing a loop on all mesh cells, and i modify each cell value based on the neighboring cells values by calling the function mesh.cellCells(). This is Ok in serial. But in parallel, the function mesh.cellCells() runs but not correctly due to decomposition of the domain (it does mixing of cells IDs without taking in account the domain on each proc.). So my real problem is how to handle this issue in parallel ? In another way, how to handle this function to work fine on each processor ?

Thanks,

T.D.

Originally Posted by wyldckat

Hi T.D.,

I hope you don't mind, but I'll answer the question you sent me via PM here on this thread of yours:

I need a practical example of what you're trying to do. A simple test case+code would make it easier to diagnose.


The best I can remember right now is my blog post: Notes about running OpenFOAM in parallel - but I can't remember any specific tutorials on how to code these things... let me see if I can find an answer I gave someone else who didn't ask me things publicly... OK, here is a snippet:



And I know I answered someone recently about Test-parallel... mmm, it was this one: http://www.cfd-online.com/Forums/ope...ging-list.html
As for searching techniques: http://openfoamwiki.net/index.php/In...hing_for_files

Good luck! Best regards,
Bruno

[wyldckat]

Hi T.D.,

I've had this on my to-do list for sometime and only now did I finally managed to at least think a bit more about this.
I don't know if you've found a solution for this, but here's what comes to mind:

The first solution that comes to mind is to actually have more control over the decomposition itself, i.e. to avoid that a specific faceZone or faceSet is kept all inside the same processor. This can be achieved with the keywords "preserveFaceZones" and "singleProcessorFaceSets". More details are provided in the main example dictionary file "applications/utilities/parallelProcessing/decomposePar/decomposeParDict": https://github.com/OpenFOAM/OpenFOAM...composeParDict

The second solution I can think of requires an auxiliary field, similar to the wave algorithm for calculating distances that is already used in OpenFOAM. The difference is that instead of a single value being stored inside each face centre, you would need a more complex field, e.g. a 3D tensor (3x3x3), that has the sums for each direction. The other downside to this is that it requires a specific equation for calculating this... which depends on what you're trying to calculate.
The idea here is that since the values are then calculated with equations, the solver will take care of propagating the values between neighbours, since the values are stored on the faces of the cells, which are transported via processor patches.

Beyond this, I can't think of more solutions right now.

Best regards,
Bruno

[T.D.]

Hi Bruno,

Thank you very much. I will think about it..

Best Regards,

T.D.