Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 6 commits into from
Jul 24, 2024

Conversation

acdaigneault
Copy link
Collaborator

@acdaigneault acdaigneault commented Jul 23, 2024

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

@acdaigneault acdaigneault added Quick fix Ready for review Refactoring This PR is only refactoring or clean up labels Jul 23, 2024
@acdaigneault acdaigneault self-assigned this Jul 23, 2024
@blaisb
Copy link
Contributor

blaisb commented Jul 23, 2024

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
Copy link
Collaborator Author

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
Copy link
Contributor

blaisb commented Jul 24, 2024 via email

@acdaigneault
Copy link
Collaborator Author

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

@blaisb blaisb merged commit a236260 into master Jul 24, 2024
8 checks passed
@blaisb blaisb deleted the cfddem_remove-sort-cells-pbc branch July 24, 2024 16:34
blaisb pushed a commit that referenced this pull request Jul 24, 2024
…on in unresolved CFD-DEM (#1205)

Solution
Forces a contact search at the last DEM iteration of a CFD iteration for more robustness related to the update of the reference location of the particles prior the void fraction calculation.
See discussion in #1204 .

Testing
All tests are updated.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Quick fix Ready for review Refactoring This PR is only refactoring or clean up
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants