# Hiting the wall by particle

 Register Blogs Members List Search Today's Posts Mark Forums Read

 April 28, 2010, 02:39 #21 Member   Mihails Ščepanskis Join Date: Jul 2009 Posts: 36 Rep Power: 9 Niklas, you were right, this check does not work. But I cannot understand why. Code: ``` vector Sf = Sfbc[j]; //area of the face vector pHit = position_ + lam*(endPosition - position_); //pHit is the radius vector of hit point scalar S = 0.0; forAll(facePoints, fi) { label fi1 = (fi + 1) % facePoints.size(); vector p1 = points[facePoints[fi1]]; vector p0 = points[facePoints[fi]]; //lHit1 and lHit2 are vectors between face points and hit point vector lHit1 = p1 - pHit; vector lHit2 = p0 - pHit; //I calculate the area of triangle between lHit1 and lHit2 scalar S += mag(lHit1 ^ lHit2) / 2.0; } //pHit can be within edges only if sum of the areas of triangles are equal to area of the face if (S == mag(Sf)) { faces.append(facei); }``` S is more than mag(Sf) for all faces! __________________ Mihails Ščepanskis Laboratory for Mathematical Modelling of Environmental and Technological Processes University of Latvia

 April 28, 2010, 03:06 #22 Super Moderator     Niklas Nordin Join Date: Mar 2009 Location: Stockholm, Sweden Posts: 693 Rep Power: 21 comparing scalars with == is always a bad idea. if you are going to do that use mag(scalar1 - scalar2) < eps instead, or (mag(area1/area2 - 1.0)) < eps to get relative difference (even better here), but apart from that you are decomposing the area using the point and if a face is slightly warped (which it always is numerically when you have more than 3 points) you will get different areas depending on where the point is. I would not use that area-comparison method, but if you want to get it working on simple cases where you know the faces arent so bad just increase the tolerance. Im currently working on a new tracking algorithm and what Im doing there is to decompose the face in triangles, using its face center and face points, and then check if the face hit is within one of these triangles, the algorithm for that looks like this (I just copy/paste'd this so variable names might differ, but you should get the idea I hope) Code: ``` const faceList& faces = mesh.faces(); const labelList& f = faces[facei]; label nPoints = f.size(); for(label i=0; i= 0.0) && (lam <= 1.0)) { vector px = from + lam*(to -from); // calculate the outward pointing triangle edge normals vector normal1 = line3 - ( (line3 & line1)/(line1 & line1) )*line1; vector normal2 = line1 - ( (line1 & line2)/(line2 & line2) )*line2; vector normal3 = line2 - ( (line2 & line3)/(line3 & line3) )*line3; normal1 /= mag(normal1); normal2 /= mag(normal2); normal3 /= mag(normal3); // calculate the distance to the edges scalar d1 = (px - pi) & normal1; scalar d2 = (px - pj) & normal2; scalar d3 = (px - Cf) & normal3; // check if point is inside triangle and allow for small overlap on edges // inside means that all d's, 1-3, are negative. // d2 and d3 are internal edges, so tolerance can be increase further for those if needed if ( (d1 <= myTol) && (d2 <= myTol) && (d3 <= myTol)) { hitFace = true; } } }```

 April 28, 2010, 05:35 #23 Member   Mihails Ščepanskis Join Date: Jul 2009 Posts: 36 Rep Power: 9 Your method: normal1 is outward pointing triangle edge normal. vector (px - pi) is vector FROM px TO pi. Thus if px is within the triangle then vector (px - pi) will have the same direction as normal1. Thus (px-pi) & normal1 will be positive (but you've written that it should be negative!) __________________ Mihails Ščepanskis Laboratory for Mathematical Modelling of Environmental and Technological Processes University of Latvia

 April 28, 2010, 06:08 #24 Super Moderator     Niklas Nordin Join Date: Mar 2009 Location: Stockholm, Sweden Posts: 693 Rep Power: 21 eehhh.... example: px = (1 0 0) pi = (0 0 0) px - pi = (1 0 0) how can this vector be from px to pi?

April 28, 2010, 07:11
#25
Member

Mihails Ščepanskis
Join Date: Jul 2009
Posts: 36
Rep Power: 9
Quote:
 Originally Posted by niklas eehhh....
I am really sorry, I am little bit tired(
__________________
Mihails Ščepanskis
Laboratory for Mathematical Modelling of Environmental and Technological Processes
University of Latvia

 April 28, 2010, 07:49 #26 Member   Mihails Ščepanskis Join Date: Jul 2009 Posts: 36 Rep Power: 9 Niklas, thank you very much. It seems that treated solver works correct. I am really very thankful! __________________ Mihails Ščepanskis Laboratory for Mathematical Modelling of Environmental and Technological Processes University of Latvia

July 25, 2010, 09:29
#27
New Member

Fiorenzo Ambrosino
Join Date: Mar 2010
Location: Naples, Italy
Posts: 5
Rep Power: 8
Hi Niklas and Shchepan, I'm also working with particles that near wall have the radius bigger than the cell size and than I have the problem on the rebound.
I've implemented the idea shown in this thread and I've solved almost all the problems on the rebound. I still have some problem on few particles.
I'm thinking in other ways to solve the problem on the hitting of the wall by particles and I have a question for you:
I'm not sure if I have understood properly the logic behind the particle tracking algorithm implemented in OpenFOAM but, in a situation of thetraedric mesh (like the 2D sketch attached below), is it possible that particles with center position in a cell that not have a wall face could not hit the wall properly? I mean although their radius length is smaller than the characteristic cell size?

Fiorenzo
Attached Images
 rebound_tri_mesh.png (8.7 KB, 26 views)

 July 26, 2010, 11:37 #28 Super Moderator     Niklas Nordin Join Date: Mar 2009 Location: Stockholm, Sweden Posts: 693 Rep Power: 21 your problem is the same as shchepan's. Since the particle only can belong to 1 cell at a time there is a chance the particle can 'escape'. When your particle can extend into neighboring cells you have to check all boundary faces for wall interaction, otherwise you will make assumptions that can cause problem.

August 4, 2010, 11:50
#29
Member

Franco Marra
Join Date: Mar 2009
Location: Napoli - Italy
Posts: 52
Rep Power: 9
Dear Niklas,

thank you for the answer to Fiorenzo. We are working together on this problem. We would highlight a situation that could cause the algorithm to fail. We have the feeling that this situation has not been considered before. In the attached image, we illustrate two particles hitting the walls starting from different cells but following exactly the same trajectory. The starting position of the particles is indicated in black, the hit in red. Particles have dimension smaller than the cell size, indicated with a dashed line. Both cells include the hitting position of the particle centre. It is not a matter of the dimension of the particle, it depends upon the fact that the second cell does not share any face plane with the boundary patch plane. Of course the smaller the particle dimension, the smaller the probability that this situation happens.

Your suggestion to include in the hitting test also the neighbour cells should fix this problem but I do not know how much difficult could be to implement such test.

Any comment on this will greatly help us to better understand the algorithm implemented in OpenFOAM.

Franco
Attached Images
 rebound_tri_mesh2.png (8.5 KB, 23 views)

 October 2, 2011, 06:29 #30 New Member   Yangyang Join Date: Aug 2011 Posts: 3 Rep Power: 7 dear niklas: I'm a fresh for the particle-flow interaction, and I need to make some treatment depends on the angle that a particle hit on the wall. I need to consider the heat exchanges between a particle and the wall the particle hits, and the thermal resistance has some relationship with the hit agle,so and I wonder how can i get the expression about this "angle"? looking forward for your reply yours sincerely Bella

 November 3, 2015, 05:25 #31 New Member   Join Date: Apr 2015 Posts: 9 Rep Power: 3 Hi there, I would like to throw something into this rather old topic. I had very similar problems with wall-collisions and particle sizes like they are depicted here (I am using OF2.3.0 with swak4foam). Due to a necessarily fine mesh 80% of my particles are bigger than the cells. So what I do is: Check if particle Volume is bigger than cell volume. If it's not, continue with original code. If it is, check how far particle extends into neighbour cells. Repeat process for neighbours neighbours and so on until the new neighbours don't fullfill the "inside particle" criterium anymore (e.g. dist(cell.centre(), p.centre())). Do the originial code for all cells considered inside the particle. Unfortunatelly this doesn't work so well as it seems that there is a problem with the hitFace() function when the considered cell isn't cellI_ (the particles cell) anymore. Therefore I simplified it all and simply deactivate the particles if a cell considered inside has any wall-faces. Maybe someone has some ideas on this topic?

February 4, 2016, 06:09
#32
New Member

Join Date: Apr 2015
Posts: 9
Rep Power: 3
Just to push this topic a little bit and maybe get some new ideas.
Here are two plots for the filtration of particles with the original code and with my additions.

As can be seen the modifications improve the filtration behaviour as the filtration rate doesn't decrease for bigger particles anymore. However, the transition regime between the original code and the modified one remains a problem as there is no interpolation scheme for particles which are in their dimensions close to the cells dimensions.

Does anybody have an idea on how this could be improved?
Attached Images
 Original.png (30.4 KB, 4 views) Modified.png (21.7 KB, 4 views)

 Thread Tools Display Modes Linear Mode

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post simvun OpenFOAM Other Meshers: ICEM, Star, Ansys, Pointwise, GridPro, Ansa, ... 48 May 14, 2012 05:20 dm2747 FLUENT 0 April 17, 2009 01:29 unoder OpenFOAM Installation 11 January 30, 2008 21:30 Andrea CFX 2 October 11, 2004 05:12 yueroo FLUENT 0 April 14, 2001 03:56

All times are GMT -4. The time now is 21:47.