Possible bug at intersections

[jordisanglas]

Hi,

There might another issue with the way DFNTrans checks for intersections, which makes particles skip them in some rare cases.

The bug happens when a particle is very close to an intersection, but is in a cell that only has one node in contact with it. The code then defines three variables:

• int1: Node that belongs to that cell and is in contact with the intersection.
• int2: Neighbor node of int1 in contact with the intersection.
• int3: If it exists, second neighbor node in contact with the intersection.

DFNTrans then checks a segment-segment intersection between the particle's trajectory and segment int1<->int2. However, as seen in the figure below, this might not detect the particle crossing the intersection. A possible fix would be to check if int3 exists and, if so, check for an intersection between the particle's trajectory and segment int2<->int3.

Regards, Jordi

[hymanjd]

Thanks for pointing this our Jordi. Things are crazy right now with the shutdown but we'll try to address this as soon as possible.

[dfnWorks]

Thank you for your question and for looking into the code deeply. In the case when only one (int1) node of the triangular cell belongs to an intersection, the algorithm is looking for another node (int2 or/and int3) in order to define the intersection line. All three points, int1, int2, and int3 belong to the same intersection line and we use only int1 & int2 to define it (if two nodes belong to the same line it's enough to define it) and then to see if particle crosses the intersection during the next predictor step. If it does, the new particle position is defined on the intersection line. Then, instead of searching for the new triangular cell, int1-int2 or int1-int3, we call the function CheckNewCell (), which defines a new particle’s cell on the same fracture. Of course, there are several ways to do that. If you would like to do it explicitly, you can call twice AcrossIntersection (prevcell, int1, int2, mixing_rule) function with parameters int1 and int3 and see if there is a difference. Thank you for your question.

[jordisanglas]

Hi,

Thanks for your help! I think that, although int1-int2 and int2-int3 define the same line, the CheckDistance function checks for an intersection with the segment between the two nodes instead of the whole line.

To test that, I took the 4-user-rects test and set a much lower pressure difference (500 Pa from inlet to outlet). With 100 000 particles, 46 got lost. Then I modified the condition in CheckDistance so that, if int3 exists, the segment is defined using int2-int3 instead of int1-int2. Now, only 8 particles get lost. That could be because, when defining the segment using int1-int2, the particle might skip the intersection and go to a zone with almost no flow, where it gets stuck.

[dfnWorks]

Thanks again for pointing at the issue. I will test it and make the necessary changes in the code to fix it. The correct version will appear in the repository. Thank you!