Setting up a Roadmap

[anicusan]

Hello,

Do you have a roadmap for future lethe development plans? I've seen a lot of very useful information scattered around the repository - e.g. no immediate plans for compressible solvers, but ideas for more complex rheology; I think having such details brought together into a single roadmap would be useful for potential outside contributors to the library and perhaps help concentrate expertise to the most impactful / helpful areas.

Best wishes,
Leonard

[blaisb]

Dear Leonard,
Lot's of posts for a single day :).
You are definitely right. There is not a clearly well-established written roadmap. I mean, there is one in my head, and in the head of my students, but i'm not sure that counts. The one in my head should not at least ^^!
What form would such a roadmap take on github? In the project pane, or more like a page on the documentation that gives details on the Roadmap for 2022?

A few cool features are coming this year:

• Implicit high-order resolved CFD-DEM
• Unresolved CFD-DEM
• DEM with moving geometries
• Better linear solvers
• Rheology models
• Temperature dependent physical properties
• ....

So yeah, there's a lot coming up this year.

[anicusan]

Hi Bruno,

Lots of posts indeed, thank you for giving such insightful answers to all of them :D.

To reduce duplication between the GitHub README and the actual documentation (which is looking great! I like setting it up in Sphinx), perhaps a separate page on lethe-cfd.github.io/lethe/ would be best; then the GitHub README can simply point to the most useful parts of the online documentation. Also, is there a way to move the index.html to its parent directory, so that the docs are simply lethe-cfd.github.io ?

Those features are extraordinary!! Are you working on them as part of a grant or for a specific project, or want to create a feature-complete CFD-DEM multiphysics library?

Also, what are your plans on the DEM side? While the CFD/FEM part builds on deal.II, I don't see source/dem depending too much on it; have you looked at other solutions, perhaps LAMMPS (with its granular package) or LIGGGHTS?

Best wishes,
Leonard

[blaisb]

Dear Leonard,

Hi Bruno,

Lots of posts indeed, thank you for giving such insightful answers to all of them :D.

To reduce duplication between the GitHub README and the actual documentation (which is looking great! I like setting it up in Sphinx), perhaps a separate page on lethe-cfd.github.io/lethe/ would be best; then the GitHub README can simply point to the most useful parts of the online documentation.

This is what we will be moving towards to once the online documentation will be fully fleshed out. Once it is fleshed-out, we will remove the wiki and have the readme / wiki point to the relevant section of the online documentation. The idea is to phase out progressively the wiki as we transition to the more robust sphinx documentation. It is much easier to manage having a documentation in the repository than outside.

Also, is there a way to move the index.html to its parent directory, so that the docs are simply lethe-cfd.github.io ?

I'm not sure I want to go there. We will eventually have other github.io pages for other side projects in the Lethe organization so most likely the link will remain the same. I don't think that's a deal breaker anyway :).

Those features are extraordinary!! Are you working on them as part of a grant or for a specific project, or want to create a feature-complete CFD-DEM multiphysics library?

We are working on these features as part of multiple grants and fellowship. Lethe is currently used for multiple academic and industrial projects.

Also, what are your plans on the DEM side? While the CFD/FEM part builds on deal.II, I don't see source/dem depending too much on it; have you looked at other solutions, perhaps LAMMPS (with its granular package) or LIGGGHTS?

This is a bit misleading. The DEM part actually relies heavily on the work in deal.II made by Rene Gassmoeller. The DEM code in Lethe is a fully fledge independent DEM code that leverages the particle functionnalities of deal.II. It can be seen as an infinitely more complex extension of step-68. https://dealii.org/developer/doxygen/deal.II/step_68.html

The DEM module contains load balancing and a lot of very cool features. You can read all about it in the following preprint: https://arxiv.org/abs/2106.09576

I did some significant development in LIGGGHTS and CFDEM in the past. LIGGGHTS was a very good platform, but we aim at a more profound CFD-DEM coupling and if you want an efficient one, at one point having to couple to completely different code that have two different algorithmic structure is highly detrimental. Right now our CFD-DEM code has a lot of advantages:

• It works with a single mesh for both DEM and CFD
• Locating the particles in the CFD mesh is done at quasi zero cost
• Interpolating to the particle location is trivial
• etc.

So actually, we really aim at developing this monolithic CFD-DEM approach instead of patching two codes together. It's more work for sure, but the underlying particles architecture of deal.II is crazy efficient.

I>

Best wishes, Leonard

[anicusan]

Thank you again for such a detailed response; I enjoyed the Lethe-DEM paper very much - developing it together with the CFD part makes a lot of sense now - and frankly, I got excited reading about it!

Related to DEM simulations and future plans - is there any dynamic simulation management functionality planned? E.g. to simulate a shear cell, you'd pre-shear the particles, save the simulation state, then shear the particles at a given vertical load - then reload the pre-sheared state and repeat at different applied vertical forces. This requires being able to manage the simulation at runtime. A bit more generally, reactants (DEM particles or CFD phases) may be added to the system at a given point in time or when a condition is fulfilled. Perhaps a C++ API could be fixed and lethe compiled as a shared library - this is, of course, in line with the Python / Julia interface idea in the other discussion; I was thinking of taking the <solver>::solve methods' steps apart into individual methods (e.g. run_to(time) for integration) that can be called directly, as needed - I wanted to know if you've already envisioned a solution to this?

Apologies for the list of questions (again) - is there polyhedral particle functionality planned? How closely tied to the deal.II architecture is the neighbour list contact detection - I was always keen to use bounding volume hierarchies in DEM (they've all but replaced neighbour lists in the field of graphics - this approach seems excellent for dynamic "scenes"); being able to use a BVH with deal.II's load balancing would be awesome. I am very interested to implement ideas like above if it's welcome in the long-term development of lethe :).

[blaisb]

Dear Leonard,
Please find my answers below.

Thank you again for such a detailed response; I enjoyed the Lethe-DEM paper very much - developing it together with the CFD part makes a lot of sense now - and frankly, I got excited reading about it!

Related to DEM simulations and future plans - is there any dynamic simulation management functionality planned? E.g. to simulate a shear cell, you'd pre-shear the particles, save the simulation state, then shear the particles at a given vertical load - then reload the pre-sheared state and repeat at different applied vertical forces. This requires being able to manage the simulation at runtime. A bit more generally, reactants (DEM particles or CFD phases) may be added to the system at a given point in time or when a condition is fulfilled. Perhaps a C++ API could be fixed and lethe compiled as a shared library - this is, of course, in line with the Python / Julia interface idea in the other discussion; I was thinking of taking the <solver>::solve methods' steps apart into individual methods (e.g. run_to(time) for integration) that can be called directly, as needed - I wanted to know if you've already envisioned a solution to this?

At the moment there are no plans for this. The DEM code supports full simulation restart. Consequently, the currently plan is to envision the different step of a simulation as a series of parameter files. E.g. you load with a parameter file, you move the shear cell with a second parameter file. A scripting language like is available in LIGGGHTS would be very nice to achieve much higher flexibility, but that's not planned for now. Not because i'm opposed to the philosophy, on the contrary, we just don't have time / energy / funds / expertise to achieve this :).

Apologies for the list of questions (again) - is there polyhedral particle functionality planned? How closely tied to the deal.II architecture is the neighbour list contact detection - I was always keen to use bounding volume hierarchies in DEM (they've all but replaced neighbour lists in the field of graphics - this approach seems excellent for dynamic "scenes"); being able to use a BVH with deal.II's load balancing would be awesome. I am very interested to implement ideas like above if it's welcome in the long-term development of lethe :).

There are not plans for polyhedral particles. Right now, the contact detection is tied to the deal.II architecture, but it is still a class in itself. Consequently, you could write a new contact detection class and replace the current one with it at run time and it could handle different type of detections. This is possible at the moment. The core limitation is that you will always be limited to having a deal.II triangulation in the background because this is what is used for load balancing and to structure the particles. You could do the contact detection without using this grid as a contact detection grid, yet we do it because it is quite efficient (at least for now).

[blaisb]

Dear @anicusan , it seems I really dropped the ball on this discussion. Sorry, I am poor at managing my github threads.
The contact detection in the DEM part is related to the deal.II mesh, but it would be relatively easy to swap the contact detection mechanism for something else and just use the background mesh for the load balancing. All of this is always open to discussion. We try to have a cooperative and non-dogmatic approach :).