View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003237 | OpenFOAM | Feature | public | 2019-05-13 20:00 | 2019-05-30 11:18 |
| Reporter | dusweave | Assigned To | will | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | suspended | ||
| Platform | Unix | OS | Other | OS Version | (please specify) |
| Summary | 0003237: patchCollisionDensity and particleErosion not working for DPMFoam | ||||
| Description | MPPICFoam works well with patchCollisionDensity and particleErosion but DPM produces zero values. | ||||
| Steps To Reproduce | Add: patchCollisionDensity1 { type patchCollisionDensity; minSpeed 1e-3; } particleErosion1 { type particleErosion; patches (PLATE); libs ("grpLagrangianIntermediateFunctionObjects"); p 1100000000; psi 2; K 2.6; } to kinematicCloudProperties file | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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. |
| 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 | |
| 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 |
