View Issue Details

IDProjectCategoryView StatusLast Update
0003212OpenFOAMBugpublic2019-04-23 13:40
Reportermike_b_33 Assigned Towill  
Status resolvedResolutionfixed 
PlatformLinuxOSUbuntuOS Version16.04
Product Versiondev 
Fixed in Versiondev 
Summary0003212: Lagrangian particles encountering a rotational cyclicAMI patch are wrongly flagged for removal
DescriptionDepending on the displacement direction and patch normal direction, particles can be flagged for removal by the hitCyclicAMIPatch function in $FOAM_SRC/lagrangian/basic/particle/particleTemplates.C file. The relevant section of code is:

    // If the displacement points into the receiving face then issue a warning
    // and remove the particle
     && ((displacement - fraction*receiveDisplacement) & receiveNormal) > 0
        td.keepParticle = false;
            << "Particle transfer from " << cyclicAMIPolyPatch::typeName
            << " patches " << << " to " <<
            << " failed at position " << pos << " and with displacement "
            << (displacement - fraction*receiveDisplacement) << nl
            << " The displacement points into both the source and receiving "
            << "faces, so the tracking cannot proceed" << nl
            << " The particle has been removed" << nl << endl;

For rotational periodic boundaries, the inner product of the pre-transformed displacement and normal of the receiving patch can result in a positive number, causing particles to be flagged for removal. This can occur even when a particle's original displacement points out of the source patch, and the rotated/transformed displacement points into the receiving patch.
Steps To ReproduceThe attached case is periodic with a rotational transformation of 30 degrees about the z-axis . Particles are injected with two different starting velocities. Particles started via vanishesAcrossPatch vanish upon contact with a cyclicAMI patch.

1. Unzip the case.
2. Run Allrun
3. Post-process to view the behavior of particles hitting cyclicAMI patches (vanishing vs. surviving). The first particle vanishes near t=0.068.
Additional InformationObserved on OpenFOAM-dev running on Linux Ubuntu 16.04 LTS, 18.04 LTS, and the Linux subsystem on Windows 10 (Ubuntu 16.04).

Some additional comments:

Particles injected via vanishesAcrossPatch injection model have a velocity of (-6.0 -1.5 0.0). When these parcels encounter the cyclic AMI boundary, they are flagged for removal. This is because the receiving patch has a normal of (-0.259 0.966 0). The inner product of the particle displacement and the receiving patch is greater than 0. If the particle's velocity (or displacement) were to be transformed prior to this check, it would be (-4.4 -4.3 0.0). Taking the inner product of the transformed velocity and the receiving patch normal results in a negative number, indicating the transformed velocity points into the patch.

Particles injected via survivesAcrossPatch have a velocity of (0.0 -6.0 0.0). When these parcels cross the AMI boundary, no problems are encountered, and the particles and their properties are transformed appropriately.

Potential fixes:
For my cases, I commented out the section of code given in the description, fixing my issue on a stationary mesh. Other possibilities could be
1) transforming the displacement with the cyclicAMI transformation. Use the transformed displacement for the check
2) I've seen particles move against displacement in poor quality cells. I think this has been referred to negative space within barycentric tracking. This causes the parameter "behind" to become greater than 0. Maybe the use of behind > 0 as a check that the particle's displacement isn't pointing into the source patch (and out of the receiving patch).
TagsNo tags attached.



2019-03-29 05:01



2019-04-23 13:40

manager   ~0010437

It was a transformation issue. The check needed an addition transformation doing on the displacement.

Resolved in dev by

Issue History

Date Modified Username Field Change
2019-03-29 05:01 mike_b_33 New Issue
2019-03-29 05:01 mike_b_33 File Added:
2019-04-23 13:40 will Assigned To => will
2019-04-23 13:40 will Status new => resolved
2019-04-23 13:40 will Resolution open => fixed
2019-04-23 13:40 will Fixed in Version => dev
2019-04-23 13:40 will Note Added: 0010437