Code Monkey home page Code Monkey logo

lethe's People

Contributors

acdaigneault avatar amishgaalphonius avatar bangerth avatar bibeauv avatar blaisb avatar caroleannedaunais avatar cenr20 avatar charles-lp avatar cleodeletre avatar emilebergeron avatar ghazalemir avatar hepap avatar jeannejoachim avatar lpsaavedra avatar luckabarbeau avatar maxl-1 avatar mivaia avatar ogaboriault avatar oguevremont avatar orestemarquis avatar paulapatience avatar peterrum avatar pierrelaurentincs avatar sgauvin avatar shahabgol avatar technophil98 avatar tonielgeitani avatar voferreira avatar wendi-l avatar yashuuzi avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

lethe's Issues

Not an issue, but a discussion | Robustness of the incompressible lethe solvers

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.

Refinement of simplex meshes

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

uvwp delcare parameters n_components argument

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.

Messy sharp ib parameter section

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.

dem find_full_cell_neighbors is not robust

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.

Resolved CFD-DEM and unresolved CFD-DEM examples should be grouped into seperate folder

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.

Nitsche solid simulation with simplex

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.

Steady_BDF exit when initial CFL=0

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.

Time-averaged velocity calculation

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

Handling of Dummy DOF in sharp solver

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.

Missing .msh file in many examples

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:

  • 3d_flow_around_sphere
  • 3d_ribbon_mixer_srf
    @AmishgaAlphonius do you think you could make a small PR to address that?

Moving geometries in DEM/CFD-DEM

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

Some tables are not checkpointed

Tables appearing in the finish_simulation() function are not checkpointed.
The tables in their respective physics that need to be checkpointed are listed below.

  1. FD:

    • Forces
    • Torques
    • Errors
  2. Heat Transfert:

    • Errors
    • Heat flux (postprocessing)
    • Statistics table (postprocessing)
  3. Tracer:

    • Errors
    • Statistics table (postprocessing)
  4. VOF:

    • Conservation monitoring
    • Errors
    • Barycenter (postprocessing)
  5. Cahn Hilliard:

    • Errors
    • Statistics table (postprocessing)
  • Update restart tests with the new serialized tables

Nitsche model restart does not work with simplices

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 :)

Docker image not working

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.

Stacktrace:

#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

Restarting overwrites Nitsche particle forces and torques

Hello, and thank you for developing this very high quality code.

Problem Description

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

Boundary conditions for glsNS3d

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.

Single thread force evaluation on sharp IB using Q1Q1

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.

Reading particle file in sharp solver

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:

particles.zip

Cheers,

Dan

Nitsche IB model crashes when restarting and then load balancing

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.

Hard coded IB particle limit

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?

Error during building

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

lethe compilation issue

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.

Interpolated Void Fraction should be bounded to 1 for usage in drag and lift models

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.

gls_free-surface_drop-wetting_inverted gls_free-surface_drop-peeling are broken

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

sedimentation_1_particle example is broken

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...

compile error of lethe

I am been following the guide
image
but when I start building use make in step2, I get the error
image

Nitsche solid triangulation is not properly loaded

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 :

  • in solid_base.cc:
  • in load_triangulation, use the defined "full load triangulation" and update the TODO comment
  • in setup_triangulation, remove passed boolean parameter restart, the loop-condition if (!restart) and the NB comment just above
  • in solid_base.h :
  • update the setup_triangulation method definition to remove the parameter restart
  • in gls_nitsche_navier_stokes.cc, in the method read_checkpoint() :
  • remove the call to setup_triangulation
  • uncomment the call to load_triangulation
  • remove the pcout lines stating "Warning - the solid triangulation cannot be properly loaded..."
  • clean-up comments with (known issue) and commented for now

Test with restart files break down if p4est 2.3.2 is used

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.

Improve VOF documentation

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.

Boundary mesh generated is not high-order

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.

Move mesh reading in DEM to the core grid utilities

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.

DEM loading part in unresolved CFD-DEM example is slow

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.

Output of simulation should throw an error/warning when convergence is not reached

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.

WSL instructions should mention apt-get install

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.