CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Bugs (http://www.cfd-online.com/Forums/openfoam-bugs/)
-   -   Particle-class uses wallImpactDistance on non-wall patches (http://www.cfd-online.com/Forums/openfoam-bugs/79306-particle-class-uses-wallimpactdistance-non-wall-patches.html)

gschaider August 19, 2010 07:54

Particle-class uses wallImpactDistance on non-wall patches
 
3 Attachment(s)
Versions: this is found in OF-Versions 1.5 till the present (1.7.x)

Description: When calculating the lambda (normalized time to impact on a patch) the wallImpactDistance (basically radius of the particle) is used to take a non-zero thickness into acount when a particle is being reflected on a wall. The problem is that the wallImpactDistance is used for all other types of patches. This leads especially for processor-patches to the problem that the exact time when the particle center crosses onto the other processor is not correctly predicted which for unfortunate circumstances (small timesteps are a big factor, then it happens even with very small particles) can lead to particles being transfered back and forth across a processor boundary (but also for symmetry-boundaries the particle never reaches the symmetry, but is reflected before it).
The picture below is from an uncoupledKinematicParcelFoam-simulation (1.7.x, no modifications to the code) and illustrates the problem:
Attachment 4452
(the strange blocking of the particles is a processor-boundary and is not seen in the serial version of this run)

This patch checks whether a boundary-face is a wall and only then applies the impact distance:
Attachment 4453

After applying the patch in the same simulation particles have no problem to "get to the other side" and the result looks like the serial computation (same decompostion as the original picture):
Attachment 4451

(it can be discussed of course whether the impact distance is relevant for other "regular" patches but for the general case - outlet, inlet - I think the particle center is the better point of reference)

Bernhard

heather August 20, 2010 05:17

Thanks for the report - I've pushed the fix from our internal line

Andy

flying March 21, 2011 05:38

Thanks for this kind of information. In fact, I has also met this problem. If it is possible. Would you please give some hint on how to solve the problem. I will be really grateful for it.

Quote:

Originally Posted by heather (Post 272134)
Thanks for the report - I've pushed the fix from our internal line

Andy


wyldckat March 25, 2011 06:37

Greetings flying,

I've looked up the commits made to the official git repo and believe the respective fix is this one: https://github.com/OpenCFD/OpenFOAM-...45ed21b5fdecd5

But this should only be necessary if you are using a version of OpenFOAM older than 1.7.1.

Best regards,
Bruno

flying March 25, 2011 08:30

Dear Wyldkat:

Thanks so much for the information

Quote:

Originally Posted by heather (Post 272134)
Thanks for the report - I've pushed the fix from our internal line

Andy

Quote:

Originally Posted by wyldckat (Post 301026)
Greetings flying,

I've looked up the commits made to the official git repo and believe the respective fix is this one: https://github.com/OpenCFD/OpenFOAM-...45ed21b5fdecd5

But this should only be necessary if you are using a version of OpenFOAM older than 1.7.1.

Best regards,
Bruno


Edison_Ge June 5, 2011 12:20

Hi Bernhard,
 
Hi Bernhard,
I'm using OF1.7.1 which alrealy include your patch fix for the wallImpactDistance but still experiencing the same particle transform back and forth the processor boundary patch.
I'm implementing a PDF method on OF. so the particle has no diameter and I would think the wallImpactDistance is not he only place OF got wrong. Do you have similar experience?



Quote:

Originally Posted by gschaider (Post 272005)
Versions: this is found in OF-Versions 1.5 till the present (1.7.x)

Description: When calculating the lambda (normalized time to impact on a patch) the wallImpactDistance (basically radius of the particle) is used to take a non-zero thickness into acount when a particle is being reflected on a wall. The problem is that the wallImpactDistance is used for all other types of patches. This leads especially for processor-patches to the problem that the exact time when the particle center crosses onto the other processor is not correctly predicted which for unfortunate circumstances (small timesteps are a big factor, then it happens even with very small particles) can lead to particles being transfered back and forth across a processor boundary (but also for symmetry-boundaries the particle never reaches the symmetry, but is reflected before it).
The picture below is from an uncoupledKinematicParcelFoam-simulation (1.7.x, no modifications to the code) and illustrates the problem:
Attachment 4452
(the strange blocking of the particles is a processor-boundary and is not seen in the serial version of this run)

This patch checks whether a boundary-face is a wall and only then applies the impact distance:
Attachment 4453

After applying the patch in the same simulation particles have no problem to "get to the other side" and the result looks like the serial computation (same decompostion as the original picture):
Attachment 4451

(it can be discussed of course whether the impact distance is relevant for other "regular" patches but for the general case - outlet, inlet - I think the particle center is the better point of reference)

Bernhard


gschaider June 7, 2011 07:07

Quote:

Originally Posted by Edison_Ge (Post 310577)
Hi Bernhard,
I'm using OF1.7.1 which alrealy include your patch fix for the wallImpactDistance but still experiencing the same particle transform back and forth the processor boundary patch.
I'm implementing a PDF method on OF. so the particle has no diameter and I would think the wallImpactDistance is not he only place OF got wrong. Do you have similar experience?

No. But I havn't worked with 1.7.1 and lagrangian in the last time. Have you tried 1.7.x?

gara1988 January 18, 2013 04:47

Tutorial for uncoupledKinematicParcelFoam
 
Hello, I see that Bernhard computes a case with uncoupledKinematicParcelFoam. I'm trying to run a similar case. Could you Bernhard send me the folder of your case? because I haven't find tutorials. Thanks a lot.

Best regards.

Mattia

gschaider January 18, 2013 08:20

Quote:

Originally Posted by gara1988 (Post 402591)
Hello, I see that Bernhard computes a case with uncoupledKinematicParcelFoam. I'm trying to run a similar case. Could you Bernhard send me the folder of your case? because I haven't find tutorials.

Can't give you the geometry. Sorry. Also that was with a quite old version of OF so it won't be much help.

Anyway: 2.1 has a tutorial in lagrangian/icoUncoupledKinematicFoam. My proposal: just run uncoupledKinematicParcelFoam on your case and add the things OF asks for (most work will be about the specification of the lagrangian particles and that strongly depends on your case anyway - if unsure check the other lagrangian-tutorials)

gara1988 January 18, 2013 08:22

What version of OpenFoam do you intend? I have to work on 1.7.

Thanks. Best regards.

Mattia

gschaider January 18, 2013 18:18

Quote:

Originally Posted by gara1988 (Post 402644)
What version of OpenFoam do you intend? I have to work on 1.7.

Not sure where I have the case and therefor unsure for which version this is. Anyway. Just run the utility in your case and give it the stuff it asks for

gara1988 January 19, 2013 10:31

Ok. Thanks. Last question. How can I see the parcel? I impose only one parcel in the CloudPosition file and I want to see this parcel. Thanks a lot.

Best regards.

Mattia

gschaider January 19, 2013 19:49

Quote:

Originally Posted by gara1988 (Post 402848)
Ok. Thanks. Last question. How can I see the parcel? I impose only one parcel in the CloudPosition file and I want to see this parcel. Thanks a lot.

Could you be a bit more specific about "see"? I assume you mean "postprocess in paraview". To my knowledge none of the two paraview-readers reads the CloudPosition-file. They only read (and display) the locations of particles that were written at later timesteps (you will have to select the particle "mesh" in the Reader-Panel, extract it with the ExtractParts-filter and visualize them with the Glyphs-filter)


All times are GMT -4. The time now is 13:55.