View Issue Details

IDProjectCategoryView StatusLast Update
0003237OpenFOAMFeaturepublic2019-05-30 11:18
ReporterdusweaveAssigned Towill 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionsuspended 
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.

dusweave

2019-05-24 19:40

reporter   ~0010491

Hi Will,

Thank you for your reply. Could you get around this by using the cloudFunctionObject ParticleCollector? A set of polygons could be a particle radius distance from the patch with the patchCollisionDensity function being called when they pass those polygons.

dusweave

2019-05-24 19:43

reporter   ~0010492

I have seen quite a lot of papers that have used the partchCollisionDensity and ParticleErosion functions with "DPMFoam" but I'm sure now they are merely using MPPICFoam.

will

2019-05-28 09:31

manager   ~0010497

Yes, a surface a little over a radius inside the boundary in question would work. The only issue is how to set the distance. Too close and you'll get false negatives, too far away false positives. You would need to investigate.

MPPICFoam has a fundamentally different collision model and is not relevant to this discussion.

will

2019-05-30 11:18

manager   ~0010500

This is a limitation. Fixing it would require funding and an analysis of the benefit relative to the additional complexity and cost. Report suspended pending these requirements.

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
2019-05-24 19:40 dusweave Note Added: 0010491
2019-05-24 19:43 dusweave Note Added: 0010492
2019-05-28 09:31 will Note Added: 0010497
2019-05-30 11:18 will Assigned To => will
2019-05-30 11:18 will Status new => closed
2019-05-30 11:18 will Resolution open => suspended
2019-05-30 11:18 will Note Added: 0010500