View Issue Details

IDProjectCategoryView StatusLast Update
0003237OpenFOAMFeaturepublic2019-05-21 10:07
ReporterdusweaveAssigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
PlatformUnixOSOtherOS Version(please specify)
Product Version6 
Fixed in Version 
Summary0003237: patchCollisionDensity and particleErosion not working for DPMFoam
DescriptionMPPICFoam works well with patchCollisionDensity and particleErosion but DPM produces zero values.
Steps To ReproduceAdd:

    patchCollisionDensity1
    {
        type patchCollisionDensity;
        minSpeed 1e-3;
    }

    particleErosion1
    {
        type particleErosion;
        patches (PLATE);
        libs ("grpLagrangianIntermediateFunctionObjects");
        p 1100000000;
        psi 2;
        K 2.6;
    }

to kinematicCloudProperties file


TagsNo tags attached.

Activities

dusweave

2019-05-13 20:00

reporter  

Goldschmidt.tar.gz (243,266 bytes)

will

2019-05-21 10:07

manager   ~0010481

Last edited: 2019-05-21 10:07

View 2 revisions

When a pair collision model is being used a parcel interacts with the wall at a distance equal to its radius and rebounds. The tracking (of the parcel's centre) never considers it to have actually reached the wall, so wall post-processing never gets triggered.

There used to be a hack in the collision model to get around this, but it only worked on non-referred faces; that is wall faces that are on the same processor as the parcel. Anything transferred from another processor was ignored. This was removed as the inconsistency in operation between serial and parallel was judged to be worse than simply not having the functionality.

What is needed is a means of referring the interactions between parcels and non-processor-local wall faces back to the wall face's processor so that post-processing can be done correctly. There would then need to be a further referral back to the particles in order to effect any changes there (i.e., to apply the keep flag). This is a significant undertaking and would require funding. It is also unclear as to whether or not the computational expense of two additional communication steps would be acceptable.

Issue History

Date Modified Username Field Change
2019-05-13 20:00 dusweave New Issue
2019-05-13 20:00 dusweave File Added: Goldschmidt.tar.gz
2019-05-21 10:07 will Note Added: 0010481
2019-05-21 10:07 will Note Edited: 0010481 View Revisions