-
Notifications
You must be signed in to change notification settings - Fork 61
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
Conversation
ed2038f
to
d056c3d
Compare
applications_tests/lethe-fluid-particles/spouted_bed_load_balancing.mpirun=2.output
Outdated
Show resolved
Hide resolved
279c50a
to
f8f12c0
Compare
There was a problem hiding this 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
include/dem/dem_action_manager.h
Outdated
|
||
/** | ||
* @brief Reset all triggers to false. | ||
* TODO |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
Outdated
* calculation. | ||
*/ | ||
inline void | ||
last_dem_of_cfd_iteration_step() |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
0f760b0
to
ae0cb19
Compare
There was a problem hiding this 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 :)
There was a problem hiding this 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
DEM::DEMProperties<dim> properties_class; | ||
|
||
/** | ||
* @brief The acceleration acting of the particles. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* @brief The acceleration acting of the particles. | |
* @brief The gravitational acceleration acting on the particles. |
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agreed
There was a problem hiding this 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
} | ||
|
||
/** | ||
* @brief Check if the periodic boundaries are enabled to perform some actions. |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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."
f72b1d7
to
1589b7f
Compare
@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
Fix tests
Add doxygen doc to DEM for functions
I think the solid object changed because the mapping of solid object and cells was not done after a load balancing before
699308a
to
22ef4d7
Compare
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
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
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:
Refactoring suggestions:
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:
Pull request related list: