[gschaider]

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:
unpatchedParticle.jpg
(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:
wallParticles.patch

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):
patchedParticle.jpg

(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]

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

Andy

[flying]

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.

Originally Posted by heather

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

Andy

[wyldckat]

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]

Dear Wyldkat:

Thanks so much for the information

Originally Posted by heather

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

Andy

Originally Posted by wyldckat

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]

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?

Originally Posted by gschaider

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]

Originally Posted by Edison_Ge

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]

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]

Originally Posted by gara1988

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]

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

Thanks. Best regards.

Mattia

[gschaider]

Originally Posted by gara1988

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]

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]

Originally Posted by gara1988

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)