Closed acdaigneault closed 1 month ago
Very good change. I think it would be good, as a next step, to always force the location of the particles (like force a contact detection step) after the last DEM step. This way, when we do the CFD coupling, the reference location of the particle would have been updated. Right now if the particles are not moving a lot, the reference location can kinda drift away and the interpolation becomes innacurate. We should always be locating them once at the end in all cases. This is a bit orthogonal to this PR, so I'd rather merge this one as it is, but I still think synchronizing everything at hte end should be done in all cases
Very good change. I think it would be good, as a next step, to always force the location of the particles (like force a contact detection step) after the last DEM step. This way, when we do the CFD coupling, the reference location of the particle would have been updated. Right now if the particles are not moving a lot, the reference location can kinda drift away and the interpolation becomes innacurate. We should always be locating them once at the end in all cases. This is a bit orthogonal to this PR, so I'd rather merge this one as it is, but I still think synchronizing everything at hte end should be done in all cases
Already added here #1113 ! https://github.com/chaos-polymtl/lethe/blob/84af220e55f84cdd08cd8d8afa10c1fab578d841/include/fem-dem/cfd_dem_coupling.h Line 253 - 258
Actually, it forces a contact detection at the last DEM iteration of the CFD iteration if and only if there was not at least one contact search in this cfd iteration. Do you prefer to really force it at the last dem one? The refactor I'm doing is on the organization of those kind of calls so I could change it.
I see. I think it would be good to force it always as the last step to ensure that when the force will be calculated at the next CFD time step the calculation will be coherent. It’s a small price to pay for added robustness :)!
On Tue, Jul 23, 2024 at 17:02 Audrey Collard-Daigneault < @.***> wrote:
Very good change. I think it would be good, as a next step, to always force the location of the particles (like force a contact detection step) after the last DEM step. This way, when we do the CFD coupling, the reference location of the particle would have been updated. Right now if the particles are not moving a lot, the reference location can kinda drift away and the interpolation becomes innacurate. We should always be locating them once at the end in all cases. This is a bit orthogonal to this PR, so I'd rather merge this one as it is, but I still think synchronizing everything at hte end should be done in all cases
Already added here #1113 https://github.com/chaos-polymtl/lethe/pull/1113 !
https://github.com/chaos-polymtl/lethe/blob/84af220e55f84cdd08cd8d8afa10c1fab578d841/include/fem-dem/cfd_dem_coupling.h Line 253 - 258
Actually, it forces a contact detection at the last DEM iteration of the CFD iteration if and only if there was not at least one contact search in this cfd iteration. Do you prefer to really force it at the last dem one? The refactor I'm doing is on the organization of those kind of calls so I could change it.
— Reply to this email directly, view it on GitHub https://github.com/chaos-polymtl/lethe/pull/1204#issuecomment-2246580554, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB34SQ4A3FESQ3YEAK3NORTZN3VIVAVCNFSM6AAAAABLLI7MPWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBWGU4DANJVGQ . You are receiving this because your review was requested.Message ID: @.***>
I see. I think it would be good to force it always as the last step to ensure that when the force will be calculated at the next CFD time step the calculation will be coherent. It’s a small price to pay for added robustness :)! … On Tue, Jul 23, 2024 at 17:02 Audrey Collard-Daigneault < @.> wrote: Very good change. I think it would be good, as a next step, to always force the location of the particles (like force a contact detection step) after the last DEM step. This way, when we do the CFD coupling, the reference location of the particle would have been updated. Right now if the particles are not moving a lot, the reference location can kinda drift away and the interpolation becomes innacurate. We should always be locating them once at the end in all cases. This is a bit orthogonal to this PR, so I'd rather merge this one as it is, but I still think synchronizing everything at hte end should be done in all cases Already added here #1113 <#1113> ! https://github.com/chaos-polymtl/lethe/blob/84af220e55f84cdd08cd8d8afa10c1fab578d841/include/fem-dem/cfd_dem_coupling.h Line 253 - 258 Actually, it forces a contact detection at the last DEM iteration of the CFD iteration if and only if there was not at least one contact search in this cfd iteration. Do you prefer to really force it at the last dem one? The refactor I'm doing is on the organization of those kind of calls so I could change it. — Reply to this email directly, view it on GitHub <#1204 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB34SQ4A3FESQ3YEAK3NORTZN3VIVAVCNFSM6AAAAABLLI7MPWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBWGU4DANJVGQ . You are receiving this because your review was requested.Message ID: @.>
Ok! I might introduce it in this PR then since it's only 1 line. Next PR will improve the process to not regenerate contact search based of the dynamic contact search if it was already done at the last time step (reset the displacement vector).
Description
When using PBCs in CFD_DEM, the last DEM iteration of a CFD iteration was forcing the execution of the displacement (translation the location of particles from one PBC to the other) of particles crossing the periodic boundaries. In the past, it was an issue since the QCM was not able to take the particles outside of the domain into account. Some refactor has been done in the previous months and this is not currently an issue anymore, so this "expensive" step was done for nothing.
Solution
Remove this step, meaning the particles crossing the PBC hang outside of the domain, but are still linked to the cell. Having particles outside of the linked cell is already done for none PBC cells until the cell of "sort_particles_into_subdomain_and_cells". I tested a few configuration with no issue. The printing of particle summary is also now done like in DEM to allow printing in multi-core.
Testing
Update the test
periodic_boundaries_qcm
according to new position, comparison with the particle not on PBCs is still coherent. Add the testperiodic_boundaries_qcm_opposite_flow
that is the same test with the same principle, but with the particle on PBCs is placed on the other PBC with an opposite flow. Test is also with 2 cores, so it tests the PBC with CFD-DEM in multi-core. Tested on the pneumatic conveying example also with no issue.Miscellaneous (will be removed when merged)
I found that during another refactoring trying to simplify this check, but wanted to have it reviewed by itself. I tried to point point why it works now, and I genuinely don't know/remember with it was needed between #786 and #1043.
Checklist (will be removed when merged)
See this page for more information about the pull request process.
Code related list:
Pull request related list: