Remove forcing particle displacement in PBC with CFD-DEM at last DEM iteration

[acdaigneault]

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 test periodic_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:

• All in-code documentation related to this PR is up to date (Doxygen format)
• Lethe documentation is up to date
• Fix has unit test(s) (preferred) or application test(s), and restart files are in the generator folder
• The branch is rebased onto master
• Changelog (CHANGELOG.md) is up to date
• Code is indented with indent-all and .prm files (examples and tests) with prm-indent

Pull request related list:

• Labels are applied
• There are at least 2 reviewers (or 1 if small feature) excluding the responsible for the merge
• If this PR closes an issue or is related to a project, it is linked in the "Projects" or "Development" section
• If the fix is temporary, an issue is opened
• The PR description is cleaned and ready for merge

[blaisb]

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

[acdaigneault]

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.

[blaisb]

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: ***@***.***>

[acdaigneault]

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).