Introduce the DEM action manager

[acdaigneault]

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:

• [x] All in-code documentation related to this PR is up to date (Doxygen format)
• [x] Lethe documentation is up to date
• [x] The branch is rebased onto master
• [x] Code is indented with indent-all and .prm files (examples and tests) with prm-indent
• [x] 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:

• [x] No other PR is open related to this refactoring
• [x] Labels are applied
• [ ] There are at least 2 reviewers (or 1 if small feature) excluding the responsible for the merge
• [x] 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

[blaisb]

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

[acdaigneault]

@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