chaos-polymtl / lethe Goto Github PK
View Code? Open in Web Editor NEWRepository for the open-source lethe CFD/DEM/CFD-DEM project
Home Page: https://chaos-polymtl.github.io/lethe/index.html
License: GNU Lesser General Public License v2.1
Repository for the open-source lethe CFD/DEM/CFD-DEM project
Home Page: https://chaos-polymtl.github.io/lethe/index.html
License: GNU Lesser General Public License v2.1
Hello,
Sorry to post here in the Issues tab of this github page; if you would have enabled the discussions tab for the community using lethe it would be really great.
Coming to my query, I was just playing with the incompressible solvers of lethe (both transient & steady). All the examples provided along with are only basic examples. I would like to know the robustness of the lethe incompressible solvers (in comparison with its Openfoam counterparts) if you would have done some HPC solves at common Reynolds numbers involving turbulence. In the related article, I read lethe was designed with chemical engineering point of view. Does it mean, the solvers won't be good for turbulence (low speed aerodynamics: popular cars, bikes) modeling.
If you have some articles showing the robustness & scalability of lethe solvers; please pass me a reference. With p4est & trilinos backend, the solver will be scalable; but does the solver & preconditioners reliable for the aerodynamics physics.
We have a unit test "periodic_boundary_collisions.mpirun=2.output" which is very fragile
I will fix it during the Hackathon.
Dear Lethe authors,
Again, thank you for developing this library, we're finding it extremely powerful for our chemical engineering problems at Birmingham. I'm working with a complex case we're trying to run on 2560 CPUs: turbulent air flow through a column packed with pellets, each pellet having holes through them; for such a tortuous geometry, I've only been able to do a tetrahedralization with GMSH. The .msh file alone is 26 GB - and even that's a mesh too coarse for our Reynolds numbers...
For this case, additional node-local refinement would be necessary to not exhaust the RAM - or some other way to split a pre-refined mesh between nodes. From what I gathered off Google, deal.II can refine simplex meshes, right? What work would need to be done to include initial refinement functionality within source/core/grids.cc
?
Thank you,
Leonard
In intial_conditions.h (include/solvers/initial_conditions.h) when declaring uvwp
, in the declare_parameters(ParameterHandler, n_components)
function, the n_components
argument is set to dim
and not dim+1
. However, everything seems to work well.
The sharp ib parameter section has become messy with the addition of multiple parameters in the last few months. The parameter should be redivided into smaller and clearer subsections.
The dem test find_full_cell_neighbors
is passing on the CI but not on my computer (gcc --version
= 7.5). The output does display the same lines but not on the same order. It may be necessary to add a sorting mechanism to make it more robust.
Right now, there is a degree of confusion on the cfd-dem example
the unresolved examples are in examples/cfd-dem/example_name, but the unresolved examples are in examples/cfd-dem/resolved-cfd-dem/example_name.
I suggest we use a structure like:
examples/unresolved_cfd-dem/
examples/resolved_cfd-dem/
This way it will be clear from the get go.
@tonielgeitani or @Luckabarbeau I'll let you decide who takes care of that, it will be a very small PR to make.
When using a simplex mesh for both the Nitsche solid and the fluid, particles are lost at the very first iteration.
Maybe this has something to do with the mapping. I can provide files for testing that.
While trying to relax the steady BDF solution process with a ramp in velocity, the simulation systematically stopped after the first time step, even if the residual error was not reached.
Hi,
I've been playing with the Nitsche mixer example, and because I've decided to give my computer some abuse then I'm looking at cranking up the rotation speed and lowering the viscosity, so I am obviously interested in the Reynolds stresses and turbulent kinetic energy.
In lines 47-48 of include/solvers/postprocessing_velocities.h there is a comment saying that these calculations are currently available when using adaptative meshing, yet in the example provided, the Reynolds stress components are calculated, alongside the turbulent kinetic energy. I'm wondering if this is a comment that simply hasn't been removed yet or are these values only valid for a static mesh size?
So, am I able to ignore this comment and trust the Reynolds stress values that are calculated, or is further work still needed?
Cheers,
Dan
Currently, the restart uses multiple times the last time step for all the previous solutions of the particles. This cause problem with high order bdf scheme restart.
I think it just needs to be updated with the shape PR and have a test for one or two more shapes.
Dummy DOFs are not part of the problem and have a value imposed based on the value of the solution in the proximity to them. At the moment, the proximity of two immersed boundaries may lead to a circular reference of the value imposed on these DOFs.
Some vectors are defined and sized particle + 1 within the scratch_data member "reinit_particle_fluid_interactions". Example: fluid_pressure_gradients_at_particle_location.resize(particle_number + 1).
Ttitle says it all. This is mostly a bug with the way the preconditioner are set-up.
It seems like the test is not stable on the CI, I suggest passing it through Valgrind to see if there is not a value that is not initialized correctly
Multiple examples do not have the .msh file in the example folder. This inhibits the usage of the example, since it requires that the user already installs GMSH. It would be a good thing to address this.
The examples I found that had this issue are:
Title says it all.
A small PR to do.
We should use proper typedefs in Lethe instead of unsigned int.
There are many in Lethe. A good example is the use of boundary_id.
See https://www.dealii.org/current/doxygen/deal.II/namespacetypes.html
Hi,
Is it possible for user-created geometries (e.g. an agitator) to interact with DEM particles in either DEM or CFD-DEM simulations? I can see from the docs that I can define parameters for a wall, but nothing about how to define additional geometries. I'm interested in using Lethe for a stirred mill, so, ideally I would like the stirrer to be able to move and interact with the DEM particles.
Cheers,
Dan
Tables appearing in the finish_simulation() function are not checkpointed.
The tables in their respective physics that need to be checkpointed are listed below.
FD:
Heat Transfert:
Tracer:
VOF:
Cahn Hilliard:
The current code does not write the simplex mesh for the immersed boundary and thus, when restarting will crash.
Depending on the difficulty of serializing meshes that are made of simplices, this may be hard or difficult to do :)
Hi there.
I pulled the docker image and I am having some issues.
First of all I expected the image to create a container that I could run interactively but I can't.
Secondly, when I try to run the example as explained here:
docker run --rm
-v $(pwd):/home/dealii
ghcr.io/lethe-cfd/lethe:master
lethe-fluid examples/incompressible_flow/2d_lid_driven_cavity/cavity.prm
I have the following error:
Exception on processing:
An error occurred in line <392> of file </home/dealii/lethe/source/core/utilities.cc> in function
std::string get_last_value_of_parameter(const string&, const string&)
The violated condition was:
x_file.fail() == false
Additional information:
An input/output error has occurred. There are a number of reasons why
this may be happening, both for reading and writing operations.
If this happens during an operation that tries to read data: First,
you may be trying to read from a file that doesn't exist or that is
not readable given its file permissions. Second, deal.II uses this
error at times if it tries to read information from a file but where
the information in the file does not correspond to the expected
format. An example would be a truncated file, or a mesh file that
contains not only sections that describe the vertices and cells, but
also sections for additional data that deal.II does not understand.
If this happens during an operation that tries to write data: you may
be trying to write to a file to which file or directory permissions do
not allow you to write. A typical example is where you specify an
output file in a directory that does not exist.
#0 /opt/lethe/lib/liblethe-core.so: get_last_value_of_parameter(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)
#1 /opt/lethe/lib/liblethe-core.so: get_dimension(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&)
#2 lethe-fluid: main
Hello, and thank you for developing this very high quality code.
Once a simulation is restarted, the previously-computed nitsche particle forces and torques are lost; new values are overwritten instead of being appended to their files; e.g. I ran a simulation up to t = 4 s
, saving forces acting on particle 0 in solid_force_00.dat
and stopped - after restarting, solid_force_00.dat
will only contain forces computed after t = 4 s
.
I used the gls_nitsche_navier_stokes_33
solver, though I guess file overwriting might be orthogonal to the specific solver employed. For completeness, I attach the .prm
script I used:
#=================================================================================================
# Simulating two spheres approaching at constant velocity up to the point of contact, measuring
# the drag forces and torques acting thereon.
#
# The spheres' Reynolds number can be modified by changing the kinematic viscosity of the fluid
# (physical properties section); to fine-tune their individual Reynolds numbers change their radii
# and velocities (nitsche solid section).
#
# Author: Andrei Leonard Nicusan <[email protected]>
# Date: 28.12.2021
# License: LGPL
#=================================================================================================
#-------------------------------------------------------------------------------------------------
# Simulation and IO Control
#-------------------------------------------------------------------------------------------------
subsection simulation control
set method = sdirk2
set bdf startup method = sdirk step
set time step = 0.02 # Time step
set time end = 4.5 # End time of simulation
set adapt = true
set max cfl = 0.5
set adaptative time step scaling = 1.1
set output name = approaching_spheres # Prefix for VTU outputs
set output path = ./results/ # Output directory
set output boundaries = true # Output domain boundaries
set output frequency = 1 # Frequency of simulation output
set subdivision = 1 # Output mesh subdivision
end
#-------------------------------------------------------------------------------------------------
# Simulation Checkpointing
#-------------------------------------------------------------------------------------------------
subsection restart
set checkpoint = true # Enable checkpointing
set restart = true # Start from previous checkpoint
set filename = restart
set frequency = 10
end
#-------------------------------------------------------------------------------------------------
# Force
#-------------------------------------------------------------------------------------------------
subsection forces
set verbosity = verbose
set calculate forces = true
set force name = force
set calculate torques = true
set torque name = torque
set output precision = 15
set calculation frequency = 1
set output frequency = 1
end
#-------------------------------------------------------------------------------------------------
# FEM
#-------------------------------------------------------------------------------------------------
subsection FEM
set velocity order = 1
set pressure order = 1
# set qmapping all = true
end
#-------------------------------------------------------------------------------------------------
# Physical Properties
#-------------------------------------------------------------------------------------------------
subsection physical properties
subsection fluid 0
set kinematic viscosity = 0.001
end
end
#-------------------------------------------------------------------------------------------------
# Timer
#-------------------------------------------------------------------------------------------------
subsection timer
set type = iteration
end
#-------------------------------------------------------------------------------------------------
# Initial condition
#-------------------------------------------------------------------------------------------------
subsection initial conditions
set type = nodal
subsection uvwp
set Function expression = 0;0;0;0
end
end
#-------------------------------------------------------------------------------------------------
# Mesh
#-------------------------------------------------------------------------------------------------
subsection mesh
# Automatically generate mesh using deal.II's functions:
# https://www.dealii.org/current/doxygen/deal.II/namespaceGridGenerator.html
set type = dealii
set grid type = subdivided_hyper_rectangle
set grid arguments = 1,1,1 : -10,-5,-5 : 10,5,5 : true
set initial refinement = 3
end
#-------------------------------------------------------------------------------------------------
# Immersed Boundary Particles
#-------------------------------------------------------------------------------------------------
subsection nitsche
set verbosity = verbose
set beta = 10
set calculate forces on solid = true
set solid force name = solid_force
set calculate torques on solid = true
set solid torque name = solid_torque
set number of solids = 2
subsection nitsche solid 0
set enable particles motion = true
set particles sub iterations = 5
set stop if particles lost = true
subsection mesh
set type = dealii
set grid type = hyper_ball
set grid arguments = -5,0,0 : 0.5 : true
set initial refinement = 5
set simplex = false
end
subsection solid velocity
set Function expression = 1;0;0
end
end
subsection nitsche solid 1
set enable particles motion = true
set particles sub iterations = 5
set stop if particles lost = true
subsection mesh
set type = dealii
set grid type = hyper_ball
set grid arguments = 5,0,0 : 0.5 : true
set initial refinement = 5
set simplex = false
end
subsection solid velocity
set Function expression = -1;0;0
end
end
end
#-------------------------------------------------------------------------------------------------
# Boundary Conditions
#-------------------------------------------------------------------------------------------------
subsection boundary conditions
# Boundaries ID 0 1 2 3 4 5 <=> xmin xmax ymin ymax zmin zmax
# Open boundaries perpendicular to particle movement (x)
# Slip conditions parallel to particle movement (y and z)
set number = 4
subsection bc 0
set id = 2
set type = slip
end
subsection bc 1
set id = 3
set type = slip
end
subsection bc 2
set id = 4
set type = slip
end
subsection bc 3
set id = 5
set type = slip
end
end
#-------------------------------------------------------------------------------------------------
# Mesh Adaptation Control
#-------------------------------------------------------------------------------------------------
subsection mesh adaptation
set fraction coarsening = 0.2
set fraction refinement = 0.3
set fraction type = number
set frequency = 1
set max number elements = 1250000
set max refinement level = 8
set min refinement level = 3
set type = kelly
set variable = pressure
end
#-------------------------------------------------------------------------------------------------
# Non-Linear Solver Control
#-------------------------------------------------------------------------------------------------
subsection non-linear solver
set verbosity = verbose
set solver = newton
set max iterations = 10
set tolerance = 1e-5
end
#-------------------------------------------------------------------------------------------------
# Linear Solver Control
#-------------------------------------------------------------------------------------------------
subsection linear solver
set verbosity = verbose
# GMRES linear solver, good for < 1,000,000 elements
# set method = gmres
# set max iters = 5000
# set max krylov vectors = 200
# set relative residual = 1e-4
# set minimum residual = 1e-9
# set ilu preconditioner fill = 1
# set ilu preconditioner absolute tolerance = 1e-12
# set ilu preconditioner relative tolerance = 1.00
# AMG linear solver, more efficient for > 1,000,000 elements
set method = amg
set max iters = 5000
set relative residual = 1e-4
set minimum residual = 1e-9
set amg preconditioner ilu fill = 1
set amg preconditioner ilu absolute tolerance = 1e-10
set amg preconditioner ilu relative tolerance = 1.00
set amg aggregation threshold = 1e-12
set amg n cycles = 1
set amg w cycles = false
set amg smoother sweeps = 2
set amg smoother overlap = 1
end
@voferreira Does this alter the time it takes to compute the cut cells?
Originally posted by @blaisb in #502 (comment)
@blaisb Yes! It is cut by half, since it was looping twice over local_dof_indices
When the set number of boundary conditions is higher than the number of defined conditions, the boundary with id 1 gets defaulted to a no slip boundary without giving an error message. The defined condition with id 1 gets overwritten and the outputted results don't fit the expectations.
If the sharp IB solver is forced to use a single thread per MPI process when using Q1Q1 the force evaluation is wrong.
This can be recreated by adding the following line at the beginning of the function GLSSharpNavierStokesSolver::solve() :
MultithreadInfo::set_thread_limit(1);
The best PRM to highlight this problem is the static_stokes application test.
Hi,
I've been trying to use the load particles from file
option for the sharp solver, and I can't seem to get it to work, I'm not sure if I've missed something obvious or not. Following the docs, I set the type column to sphere and Lethe complains that a <sphere> cannot be converted to a double
- I've also tried specifying individual IDs to each row and that instead results in a segfault.
I've attached the file used below:
Cheers,
Dan
Enabling simplex crashes the output of the boundaries.
Not sure yet if this is a deal.II or a lethe problem.
@oguevremont let's keep track of this.
The Nitsche IB solver can currently restart, but it will crash automatically at the first mesh refinement or mesh adaptation step that occurs after the restart.
I have not been able to pinpoint the issue, but it is in the navier-stokes bases solver in the prepare triangulation for refinement and coarsening.
Most likely a signal is not set correctly or a similar issue.
Hi,
First off I'd like to say that I am amazed at just how good and easy to use this code is!
I am running simulations of fluid flowing past packed spheres in a box, using sharp particles and by default I cannot have more than 50 particles present. I found that in parameters.cc
, on line 1836 we have:
unsigned int max_ib_particles = 50;
Currently, I have modified this line to a larger number and recompiled to allow the use of more particles. So, my question is - is there a need to have a hard coded limit in the source code?
Hi there,
Many thanks for developing this solver. I can see great potential for Lethe on CFD simulations.
I followed the Lethe documentation to install Lethe on Ubuntu 22.04.1 LTS. The candi is used for the installation of all dependencies and deal.ii. It should be noted that there is no "STABLE_BUILD" keyword in "candi.cfg" in candi dealii-9.4 branch. I installed the deal.ii v9.4.0.
After installation of deal.ii and its dependencies, I use
cmake ../lethe -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/home/username/path/to/installation
make -j4
to install Lethe, but hit the following error during make:
[ 25%] Building CXX object source/dem/CMakeFiles/lethe-dem.dir/dem_solver_parameters.cc.o
/*/Lethe/packs/lethe/source/dem/dem_container_manager.cc: In instantiation of ‘void DEMContainerManager<dim>::execute_particle_wall_broad_search(const dealii::Particles::ParticleHandler<dim>&, BoundaryCellsInformation<dim>&, const Parameters::Lagrangian::FloatingWalls<dim>&, double, bool) [with int dim = 2]’:
/*/Lethe/packs/lethe/source/dem/dem_container_manager.cc:410:16: required from here
/*/Lethe/packs/lethe/source/dem/dem_container_manager.cc:272:51: error: cannot convert ‘std::unordered_map<unsigned int, std::set<dealii::TriaActiveIterator<dealii::CellAccessor<2, 2> >, std::less<dealii::TriaActiveIterator<dealii::CellAccessor<2, 2> > >, std::allocator<dealii::TriaActiveIterator<dealii::CellAccessor<2, 2> > > >, std::hash<unsigned int>, std::equal_to<unsigned int>, std::allocator<std::pair<const unsigned int, std::set<dealii::TriaActiveIterator<dealii::CellAccessor<2, 2> >, std::less<dealii::TriaActiveIterator<dealii::CellAccessor<2, 2> > >, std::allocator<dealii::TriaActiveIterator<dealii::CellAccessor<2, 2> > > > > > >’ to ‘const std::unordered_map<long unsigned int, std::set<dealii::TriaActiveIterator<dealii::CellAccessor<2, 2> >, std::less<dealii::TriaActiveIterator<dealii::CellAccessor<2, 2> > >, std::allocator<dealii::TriaActiveIterator<dealii::CellAccessor<2, 2> > > >, std::hash<long unsigned int>, std::equal_to<long unsigned int>, std::allocator<std::pair<const long unsigned int, std::set<dealii::TriaActiveIterator<dealii::CellAccessor<2, 2> >, std::less<dealii::TriaActiveIterator<dealii::CellAccessor<2, 2> > >, std::allocator<dealii::TriaActiveIterator<dealii::CellAccessor<2, 2> > > > > > >&’
271 | particle_wall_broad_search_object
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
272 | .find_particle_floating_wall_contact_pairs(
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
273 | boundary_cell_object.get_boundary_cells_with_floating_walls(),
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
274 | particle_handler,
| ~~~~~~~~~~~~~~~~~
275 | floating_walls,
| ~~~~~~~~~~~~~~~
276 | simulation_time,
| ~~~~~~~~~~~~~~~~
277 | particle_floating_wall_candidates);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /*/Lethe/packs/lethe/source/core/../../include/dem/dem_container_manager.h:29,
from /*/Lethe/packs/lethe/source/dem/dem_container_manager.cc:19:
/*/Lethe/packs/lethe/source/core/../../include/dem/particle_wall_broad_search.h:103:44: note: initializing argument 1 of ‘void ParticleWallBroadSearch<dim>::find_particle_floating_wall_contact_pairs(const std::unordered_map<long unsigned int, std::set<typename dealii::Triangulation<dim>::active_cell_iterator> >&, const dealii::Particles::ParticleHandler<dim>&, const Parameters::Lagrangian::FloatingWalls<dim>&, double, typename DEM::dem_data_structures<dim>::particle_floating_wall_candidates&) [with int dim = 2; typename dealii::Triangulation<dim>::active_cell_iterator = dealii::TriaActiveIterator<dealii::CellAccessor<2, 2> >; typename DEM::dem_data_structures<dim>::particle_floating_wall_candidates = std::unordered_map<long unsigned int, std::unordered_map<unsigned int, dealii::Particles::ParticleIterator<2, 2>, std::hash<unsigned int>, std::equal_to<unsigned int>, std::allocator<std::pair<const unsigned int, dealii::Particles::ParticleIterator<2, 2> > > >, std::hash<long unsigned int>, std::equal_to<long unsigned int>, std::allocator<std::pair<const long unsigned int, std::unordered_map<unsigned int, dealii::Particles::ParticleIterator<2, 2>, std::hash<unsigned int>, std::equal_to<unsigned int>, std::allocator<std::pair<const unsigned int, dealii::Particles::ParticleIterator<2, 2> > > > > > >]’
100 | const std::unordered_map<
| ~~~~~~~~~~~~~~~~~~~~~~~~~
101 | types::particle_index,
| ~~~~~~~~~~~~~~~~~~~~~~
102 | std::set<typename Triangulation<dim>::active_cell_iterator>>
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
103 | & boundary_cells_for_floating_walls,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/*/Lethe/packs/lethe/source/dem/dem_container_manager.cc: In instantiation of ‘void DEMContainerManager<dim>::execute_particle_wall_broad_search(const dealii::Particles::ParticleHandler<dim>&, BoundaryCellsInformation<dim>&, const Parameters::Lagrangian::FloatingWalls<dim>&, double, bool) [with int dim = 3]’:
/*/Lethe/packs/lethe/source/dem/dem_container_manager.cc:411:16: required from here
/*/Lethe/packs/lethe/source/dem/dem_container_manager.cc:272:51: error: cannot convert ‘std::unordered_map<unsigned int, std::set<dealii::TriaActiveIterator<dealii::CellAccessor<3, 3> >, std::less<dealii::TriaActiveIterator<dealii::CellAccessor<3, 3> > >, std::allocator<dealii::TriaActiveIterator<dealii::CellAccessor<3, 3> > > >, std::hash<unsigned int>, std::equal_to<unsigned int>, std::allocator<std::pair<const unsigned int, std::set<dealii::TriaActiveIterator<dealii::CellAccessor<3, 3> >, std::less<dealii::TriaActiveIterator<dealii::CellAccessor<3, 3> > >, std::allocator<dealii::TriaActiveIterator<dealii::CellAccessor<3, 3> > > > > > >’ to ‘const std::unordered_map<long unsigned int, std::set<dealii::TriaActiveIterator<dealii::CellAccessor<3, 3> >, std::less<dealii::TriaActiveIterator<dealii::CellAccessor<3, 3> > >, std::allocator<dealii::TriaActiveIterator<dealii::CellAccessor<3, 3> > > >, std::hash<long unsigned int>, std::equal_to<long unsigned int>, std::allocator<std::pair<const long unsigned int, std::set<dealii::TriaActiveIterator<dealii::CellAccessor<3, 3> >, std::less<dealii::TriaActiveIterator<dealii::CellAccessor<3, 3> > >, std::allocator<dealii::TriaActiveIterator<dealii::CellAccessor<3, 3> > > > > > >&’
271 | particle_wall_broad_search_object
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
272 | .find_particle_floating_wall_contact_pairs(
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
273 | boundary_cell_object.get_boundary_cells_with_floating_walls(),
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
274 | particle_handler,
| ~~~~~~~~~~~~~~~~~
275 | floating_walls,
| ~~~~~~~~~~~~~~~
276 | simulation_time,
| ~~~~~~~~~~~~~~~~
277 | particle_floating_wall_candidates);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /*/Lethe/packs/lethe/source/core/../../include/dem/dem_container_manager.h:29,
from /*/Lethe/packs/lethe/source/dem/dem_container_manager.cc:19:
/*/Lethe/packs/lethe/source/core/../../include/dem/particle_wall_broad_search.h:103:44: note: initializing argument 1 of ‘void ParticleWallBroadSearch<dim>::find_particle_floating_wall_contact_pairs(const std::unordered_map<long unsigned int, std::set<typename dealii::Triangulation<dim>::active_cell_iterator> >&, const dealii::Particles::ParticleHandler<dim>&, const Parameters::Lagrangian::FloatingWalls<dim>&, double, typename DEM::dem_data_structures<dim>::particle_floating_wall_candidates&) [with int dim = 3; typename dealii::Triangulation<dim>::active_cell_iterator = dealii::TriaActiveIterator<dealii::CellAccessor<3, 3> >; typename DEM::dem_data_structures<dim>::particle_floating_wall_candidates = std::unordered_map<long unsigned int, std::unordered_map<unsigned int, dealii::Particles::ParticleIterator<3, 3>, std::hash<unsigned int>, std::equal_to<unsigned int>, std::allocator<std::pair<const unsigned int, dealii::Particles::ParticleIterator<3, 3> > > >, std::hash<long unsigned int>, std::equal_to<long unsigned int>, std::allocator<std::pair<const long unsigned int, std::unordered_map<unsigned int, dealii::Particles::ParticleIterator<3, 3>, std::hash<unsigned int>, std::equal_to<unsigned int>, std::allocator<std::pair<const unsigned int, dealii::Particles::ParticleIterator<3, 3> > > > > > >]’
100 | const std::unordered_map<
| ~~~~~~~~~~~~~~~~~~~~~~~~~
101 | types::particle_index,
| ~~~~~~~~~~~~~~~~~~~~~~
102 | std::set<typename Triangulation<dim>::active_cell_iterator>>
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
103 | & boundary_cells_for_floating_walls,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[2]: *** [source/dem/CMakeFiles/lethe-dem.dir/build.make:104: source/dem/CMakeFiles/lethe-dem.dir/dem_container_manager.cc.o] Error 1
make[2]: *** Waiting for unfinished jobs....
[ 25%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/gls_navier_stokes.cc.o
make[1]: *** [CMakeFiles/Makefile2:1333: source/dem/CMakeFiles/lethe-dem.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[ 25%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/gls_nitsche_navier_stokes.cc.o
[ 25%] Linking CXX static library liblethe-rpt.a
[ 25%] Built target lethe-rpt
[ 25%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/heat_transfer.cc.o
[ 25%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/heat_transfer_assemblers.cc.o
[ 25%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/heat_transfer_scratch_data.cc.o
[ 25%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/initial_conditions.cc.o
[ 31%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/multiphysics_interface.cc.o
[ 31%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/navier_stokes_assemblers.cc.o
[ 31%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/navier_stokes_base.cc.o
[ 31%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/navier_stokes_scratch_data.cc.o
[ 31%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/navier_stokes_vof_assemblers.cc.o
[ 31%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/physical_properties_manager.cc.o
[ 31%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/post_processors_smoothing.cc.o
[ 31%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/postprocessing_cfd.cc.o
[ 31%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/postprocessing_velocities.cc.o
[ 37%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/simulation_parameters.cc.o
[ 37%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/source_terms.cc.o
[ 37%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/tracer.cc.o
[ 37%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/tracer_assemblers.cc.o
[ 37%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/tracer_scratch_data.cc.o
[ 37%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/vof.cc.o
[ 37%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/vof_assemblers.cc.o
[ 37%] Building CXX object source/solvers/CMakeFiles/lethe-solvers.dir/vof_scratch_data.cc.o
[ 37%] Linking CXX static library liblethe-solvers.a
[ 37%] Built target lethe-solvers
make: *** [Makefile:146: all] Error 2
May I know if I missed anything? Many thanks.
Best Regards
Wendi
There is a compilation issue for lethe; while making it shows that several header files and member functions used are not found in dealii. May be the dealii version have changed these files. Is this an issue I only face.
If void fraction of cell is greater than 1, the Koch and Hill Drag Model do not work.
This is because of the log(1 - cell_void_fraction)
in this part in the VANS Assembler :
if ((1 - cell_void_fraction) < 0.4)
{
f0 = (1 + 3 * sqrt((1 - cell_void_fraction) / 2) +
(135.0 / 64) * (1 - cell_void_fraction) *
log(1 - cell_void_fraction) +
16.14 * (1 - cell_void_fraction)) /
(1 + 0.681 * (1 - cell_void_fraction) -
8.48 * pow(1 - cell_void_fraction, 2) +
8.16 * pow(1 - cell_void_fraction, 3));
}
This results in -nan values in the RHS that crashes the solver.
EDIT: Even if not crashing the simulation, all interpolated void fraction value should be bounded to 1 before usage in any drag/lift models, as suggested in the comments of this issue.
Using the extrapolation of the refinement zone for geometry in rotation or with imposed motion does not work correctly at the moment. It leads to significant errors in the level set evaluation and position of the object.
This is not a priority to fix and, as such, may take some time to fix, as quick fixes didn't seem to work.
The tests break on my machine at home and break regularly on the CI
(see https://github.com/lethe-cfd/lethe/runs/6641090352?check_suite_focus=true)
Until the test is fixed and made stable, I have disabled it.
@jeannejoachim I think you were the one that wrote it? There seems to be something highly non-reproducible with that test indicating either a bug with the feature or a non-robust test.
I suggest running them through valgrind to see if they are sane
The pvd handler for the IB particle visualization is not reloaded correctly after a restart. This led to an incomplete pvd file.
The sedimentation_1_particle example is broken and the documentation for resolved CFD-DEM is out of date.
The exception thrown is related to the DEM coupling frequency parameter which is "not declared". I suspect the name of the parameter was changed, but not the documentation and the example...
Seen during read_checkpoint
implementation for gls_nitsche_navier_stokes
.
For now, load_triangulation
method in solid_base.cc
calls solid_tria->load(filename_tria.c_str());
, which does not allow to load all needed member variables of the triangulation (see classTriangulation documentation of deal.ii), resulting in a segmentation fault
error. To avoid this error, the triangulation can be initialized with the setup_triangulation
method, but then only the refinement is loaded, so that the Nitsche solid geometry and position are not correctly loaded for restart simulations.
A fix could be to define a load function for the triangulation which would enable to fully load a given solid triangulation file. The changes to apply in the code would then be :
solid_base.cc
:load_triangulation
, use the defined "full load triangulation" and update the TODO commentsetup_triangulation
, remove passed boolean parameter restart
, the loop-condition if (!restart)
and the NB comment just abovesolid_base.h
:setup_triangulation
method definition to remove the parameter restart
gls_nitsche_navier_stokes.cc
, in the method read_checkpoint()
:setup_triangulation
load_triangulation
pcout
lines stating "Warning - the solid triangulation cannot be properly loaded..."(known issue)
and commented for now
While installing on a new machine, I realized that the tests we have do not appear to be portable from p4est 2.2 to p4est 2.3.2. This means that once the P4est version changes on the docker image of deal.II master, all tests which have a restart will break. This is not a major issue, but until the CI is changed, it means that we should only expect the restart tests to work with p4est 2.2.
Until then, we can prepare for the CI change by adding the prm files that are used to generate the restart files.
We should split this task into four.
@blaisb will take care of the gls_navier_stokes, gd_navier_stokes and nitsche restart files
@Luckabarbeau will take care of the sharp edge restart
@tonielgeitani will take care of the cfd-dem restart
@shahabgol will take care of the dem restarts
As long as we can prepare for that, things should be good :). Let's try to include this in seperate PR as we go during the following months.
The VOF example for Rayleigh Taylor and breaking dam are not set-up optimally (they don't use adaptive initial refinement) and there are some small missing elements in the documentations. This should be fixed.
The boundary mesh files are not high-order, so we can't visualize it as a smooth mesh in Paraview.
This is also the case when we use the subdivision parameter value as the highest order for FEM.
It would also be nice to have a parameter to only output one boundary mesh for a simulation since most of them don't have moving mesh. Actually, maybe it should be the default setting.
Function read_mesh()
in dem/read_mesh.cc is very similar to attach_grid_to_triangulation()
in core/grids.cc.
It would be great to move the grid handling for DEM into the same file or rearrange functions in core/grids.cc to make it works for CFD and DEM meshes.
The installation instructions of Narval must then be used on Niagara.
The installation page will need updating to take this into account.
Two additional modules are needed:
module load CCEnv
module load StdEnv/2020
The DEM set of parameters (including the number of output files generated) in the Unresolved CFD-DEM is not optimal. It generates a lot of files and it takes a lot of time to create the packing.
I will try to improve this over next week.
When non-linear solver tolerance is not reached after max iterations, torques and/or forces are still generated as .dat (if their output is enabled in the prm file).
It would be interesting to add an error/warning message that tells the user of the failed simulation and a parameter that allows (or not) to output the data even if the convergence was not reached.
Hello! We are looking into using lethe here at UNC and a postdoc is installing it right now.
I happen to know that you can do sudo apt-get install libdeal.ii-dev
but he did not, and the instructions for WSL are only for candi. It would be great to mention that it's possible to get deal.II via apt
here instead of using candi in the WSL docs.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.