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

Introduce the DEM action manager #1206

Merged
merged 25 commits into from
Jul 30, 2024
Merged

Introduce the DEM action manager #1206

merged 25 commits into from
Jul 30, 2024

Conversation

acdaigneault
Copy link
Collaborator

@acdaigneault acdaigneault commented Jul 24, 2024

Description

Introducing singleton design pattern with the DEM action manager.
In DEM, we often check if an action has to be performed (insertion, load balancing, contact detection, etc), and those action result in resetting containers and/or do a particle contact search. The way it was handled was turning into a spaghetti code with the addition of new features.
Before, when an event was performed, a flag was set to true. And then a few places in the code was checking the flag to know if the current action has to be executed.
It was getting weird because some flags where nested into others if they triggered the same actions, but the flag has lost its meaning (ex: checkpoint in load balance flag, same for the solid object mapping).

In order to overcome this,, the action manager is introduced in the DEM and CFD-DEM to manage what event triggered what.
How does it works? Any event that needs some following actions are handled by the action manager. The event communicates to the action manager that it happened and the action manager will change the trigger flags to the actions to do. When this action is about to be performed, it checks with the action manager if it should be trigger.
Many events can triggered the same actions, but when the action is about to be performed, it only checks if it has to be performed, not what event have happened.

Many checks in the DEM and CFDDEM solvers were moved into the called function, even though the feature might not be implemented. The first thing in the function is a check with a return if so.

Testing [WIP]

The following tests have changed because the displacement vector was not reset after a contact search for every cases: restart-gas-solid-fluidized-bed.mpirun=2.output. dynamic_contact_search.mpirun=1.output.

load_balancing_solid_mobiliity_status=2.output: it seems also be related to the contact search that is shifted by one iteration. The difference between the old results with LB and without LB balancing are more different than the difference in this PR.
load_balancing_solid_mobiliity_status=2.output

Miscellaneous (will be removed when merged)

I found a few bugs-ish where checks were incoherents
There's also a lot of splitting of steps into functions, it was easier to handle, but I managed to make the DEM and the CFD-DEM almost the same that way. Then, I was able to add the action manager to the CFD-DEM also, and it would help to maybe add the DEM solver into the CFDDEM solver and only use the functions of the DEM.

Bugs found, but not fixed:

  • Display of new particles distribution after load balancing is wrong, it shows the previous distribution since particle_handler is not updated until "sort_particles_into_subdomains_and_cells".
  • All DEM iteration in the first CFD iteration use half step?
  • The tangential overlaps for particles-walls are not explicitly reset after a load balancing as done for particles.

Refactoring suggestions:

  • Would be nice to have a dem_force_manager as done for contacts instead of the function in DEM.
  • Use the DEM solver as an object of CFD-DEM solver or double inheritance.

I did most of the Doxygen doc of the CFD-DEM, but will continue in a other PR for the variables.
I still have a small detail I want to change, but it is ready for review.

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
  • The branch is rebased onto master
  • Code is indented with indent-all and .prm files (examples and tests) with prm-indent
  • If parameters are modified, the tests and the documentation of examples are up to date
  • Changelog (CHANGELOG.md) is up to date if the refactor affects the user experience or the codebase

Pull request related list:

  • No other PR is open related to this refactoring
  • 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 any future works is planed, an issue is opened
  • The PR description is cleaned and ready for merge

@acdaigneault acdaigneault self-assigned this Jul 24, 2024
@acdaigneault acdaigneault added Enhancement New feature or request WIP When a PR is open but not ready for review Refactoring This PR is only refactoring or clean up labels Jul 24, 2024
@acdaigneault acdaigneault force-pushed the dem_action-manager branch 2 times, most recently from 279c50a to f8f12c0 Compare July 26, 2024 16:04
@acdaigneault acdaigneault added Ready for review and removed WIP When a PR is open but not ready for review labels Jul 26, 2024
Copy link
Contributor

@blaisb blaisb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First batch of comments, will continue. Very good owrk though


/**
* @brief Reset all triggers to false.
* TODO
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO here being setting the documentation?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I want to remove the contact_search_trigger = mobility_status_reset_trigger; because it's sketchy and not clear haha

include/dem/dem_action_manager.h Show resolved Hide resolved
include/dem/dem_action_manager.h Outdated Show resolved Hide resolved
include/dem/dem_action_manager.h Outdated Show resolved Hide resolved
include/dem/dem_action_manager.h Outdated Show resolved Hide resolved
include/dem/dem_action_manager.h Outdated Show resolved Hide resolved
include/dem/dem_action_manager.h Outdated Show resolved Hide resolved
include/dem/dem_action_manager.h Outdated Show resolved Hide resolved
include/dem/dem_action_manager.h Outdated Show resolved Hide resolved
* calculation.
*/
inline void
last_dem_of_cfd_iteration_step()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe last_dem_of_cfd_dem_coupling_step()?
I know it's a bit long, but it's clearer I find

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I renamed to last_dem_of_cfddem_iteration_step()
last_dem_of_cfd_dem_coupling_step() sounds more like it is the very last one of the simulation in the CFD-DEM sovler

Copy link
Contributor

@blaisb blaisb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went through all the files once. Only minor comments. I will take a look again once theses changes (small ones really) are addressed :)

include/dem/periodic_boundaries_manipulator.h Outdated Show resolved Hide resolved
include/dem/periodic_boundaries_manipulator.h Outdated Show resolved Hide resolved
include/fem-dem/cfd_dem_coupling.h Outdated Show resolved Hide resolved
source/dem/CMakeLists.txt Outdated Show resolved Hide resolved
source/dem/CMakeLists.txt Outdated Show resolved Hide resolved
source/dem/dem_contact_manager.cc Outdated Show resolved Hide resolved
source/dem/explicit_euler_integrator.cc Show resolved Hide resolved
source/dem/gear3_integrator.cc Show resolved Hide resolved
source/fem-dem/cfd_dem_coupling.cc Outdated Show resolved Hide resolved
source/fem-dem/cfd_dem_coupling.cc Outdated Show resolved Hide resolved
Copy link
Collaborator

@OGaboriault OGaboriault left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not finish to review

include/dem/dem.h Outdated Show resolved Hide resolved
include/dem/adaptive_sparse_contacts.h Outdated Show resolved Hide resolved
include/dem/adaptive_sparse_contacts.h Outdated Show resolved Hide resolved
DEM::DEMProperties<dim> properties_class;

/**
* @brief The acceleration acting of the particles.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* @brief The acceleration acting of the particles.
* @brief The gravitational acceleration acting on the particles.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Theoretically, it can be other forces (let's say from a electromagnetic field). Like, we use it for gravity and the letter it g, but stilll!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed

Copy link
Collaborator

@voferreira voferreira left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Super cool! I commented some very minor things but all clear to me.

include/dem/dem_action_manager.h Outdated Show resolved Hide resolved
include/dem/dem_action_manager.h Outdated Show resolved Hide resolved
include/dem/dem_action_manager.h Outdated Show resolved Hide resolved
include/dem/dem_action_manager.h Outdated Show resolved Hide resolved
}

/**
* @brief Check if the periodic boundaries are enabled to perform some actions.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Periodic boundaries checker? Minor thing but "to perform some actions" is super vague :P

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a bit vague on purpose, because those actions are not in the class, meaning that they will probably won't be updated here even tho I write the current ones. But I did added "... that are not handled by triggers of the action manager."

@blaisb
Copy link
Contributor

blaisb commented Jul 30, 2024

@acdaigneault do you know what is the origin of the two failing tests?

@acdaigneault
Copy link
Collaborator Author

@acdaigneault do you know what is the origin of the two failing tests?

Yeah I fixed it last night, seems I did not push it correctly

Cleanup in initialization of parameter in DEM

Rearrange setting order so it matches between dem and cfd-dem
Remove load-balancing step to cfd-dem

Remove "step" flags, raw version
Here DEM and CFD-DEM works well
Refactor solid objects triggers
remove solid object flag

Remove periodic flag

Remove has_sparse_contacts flags

Put feature abstration in dem manager

Add restart abstraction level in dem
Reset contact search counter

Remove PBC sort_in_cells at last time step
@blaisb blaisb merged commit 63f64ab into master Jul 30, 2024
8 checks passed
@blaisb blaisb deleted the dem_action-manager branch July 30, 2024 18:01
M-Badri pushed a commit to M-Badri/lethe that referenced this pull request Sep 29, 2024
Description
Introducing singleton design pattern with the DEM action manager.
In DEM, we often check if an action has to be performed (insertion, load balancing, contact detection, etc), and those action result in resetting containers and/or do a particle contact search. The way it was handled was turning into a spaghetti code with the addition of new features.
Before, when an event was performed, a flag was set to true. And then a few places in the code was checking the flag to know if the current action has to be executed.
It was getting weird because some flags where nested into others if they triggered the same actions, but the flag has lost its meaning (ex: checkpoint in load balance flag, same for the solid object mapping).

In order to overcome this,, the action manager is introduced in the DEM and CFD-DEM to manage what event triggered what.
How does it works? Any event that needs some following actions are handled by the action manager. The event communicates to the action manager that it happened and the action manager will change the trigger flags to the actions to do. When this action is about to be performed, it checks with the action manager if it should be trigger.
Many events can triggered the same actions, but when the action is about to be performed, it only checks if it has to be performed, not what event have happened.

Many checks in the DEM and CFDDEM solvers were moved into the called function, even though the feature might not be implemented. The first thing in the function is a check with a return if so.

Co-authored-by: Bruno Blais <blais.bruno@gmail.com>
Former-commit-id: 63f64ab
blaisb added a commit that referenced this pull request Sep 30, 2024
Description
Introducing singleton design pattern with the DEM action manager.
In DEM, we often check if an action has to be performed (insertion, load balancing, contact detection, etc), and those action result in resetting containers and/or do a particle contact search. The way it was handled was turning into a spaghetti code with the addition of new features.
Before, when an event was performed, a flag was set to true. And then a few places in the code was checking the flag to know if the current action has to be executed.
It was getting weird because some flags where nested into others if they triggered the same actions, but the flag has lost its meaning (ex: checkpoint in load balance flag, same for the solid object mapping).

In order to overcome this,, the action manager is introduced in the DEM and CFD-DEM to manage what event triggered what.
How does it works? Any event that needs some following actions are handled by the action manager. The event communicates to the action manager that it happened and the action manager will change the trigger flags to the actions to do. When this action is about to be performed, it checks with the action manager if it should be trigger.
Many events can triggered the same actions, but when the action is about to be performed, it only checks if it has to be performed, not what event have happened.

Many checks in the DEM and CFDDEM solvers were moved into the called function, even though the feature might not be implemented. The first thing in the function is a check with a return if so.

Co-authored-by: Bruno Blais <blais.bruno@gmail.com>
Former-commit-id: 63f64ab
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement New feature or request Refactoring This PR is only refactoring or clean up Reviewed and ready to merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants