[deal.II] Re: Questions on parallel::distributed::GridRefinement::refine_and_coarsen_fixed_number in deal.II 9.0.1 released
> Dear Wolfgang Bangerth, > > Recently, I use your deal.II (Version 9.0.1) It's really not *my* program any more -- more than 250 people have contributed to it by now :-) > to solve a group of PDEs > (haveing a wave-like solution whose amplitude is modulated by another > smoother > field). However, I encounter a problem: Function > parallel::distributed::GridRefinement::refine_and_coarsen_fixed_number > (tria, criteria, top_fraction_of_cells, bottom_fraction_of_cells, > max_n_cells > ) cannot always refine my grid (in my case, it is actually coarsening my > grid) > even if bottom_fraction_of_cells = 0 and max_n_cells = > pow(2,dim)*Triangulation::n_active_cells() . What are the criteria you have? Does the vector have only zeros in it? What is top_fraction? > I check the manual of deal.II > and find that refine levels of adjecent cells cannot exceed one which maybe > the reason for my problem. No, that should really not be the issue. Best W. -- Wolfgang Bangerth email: bange...@colostate.edu www: http://www.math.colostate.edu/~bangerth/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/68c8ae3d-9a30-5147-d6a1-c0402dfbd937%40colostate.edu.
Re: [deal.II] Large Memory Consumption making BlockDynamicSparsityPattern
On 10/9/19 10:26 AM, Matteo Frigo wrote: > > I'm saying that making a DynamicSparsityPattern by using the procedure > described above is more expensive (from the memory point of view) respect > using TrilinosWrappers::BlockSparsityPattern. > I noted this trouble trying to run some test cases with a large number of > unknowns (100 millions of dofs). > In such cases, I get an out of memory error if I use DynamicSparsityPattern, > whereas it works fine using TrilinosWrappers::BlockSparsityPattern. > Investigating on smaller cases, I noted that a peak of memory usage occurs > during the call of the function: > DoFTools::make_sparsity_pattern(dof_handler, scratch_coupling, dsp, > constraints, false, this_mpi_process); > It means that the problem remains, even if the program runs until the end. > As far as the analysis of memory consumption is concerned, I used the Massif > tool from Valgrind. Matteo, thanks for clarifying. It would still be really nice if you could create a small program that really just builds a mesh, a DoFhandler, and then the sparsity pattern with both ways -- this would make it easier for us to figure out what is going on! Best W. -- Wolfgang Bangerth email: bange...@colostate.edu www: http://www.math.colostate.edu/~bangerth/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/9a02c6b1-3ce2-02b7-6db8-0c05e4102702%40colostate.edu.
Re: [deal.II] Arpack solver reports 4294967295 iterations before converging
On 10/9/19 7:47 AM, 'Maxi Miller' via deal.II User Group wrote: > This number already comes from solver_control, given as > > solver_control.last_step (); Hm, that's really quite unfortunate. It took me a couple minutes of looking into the code, but I *think* what is happening is that the ArpackSolver class simply doesn't use the solver control object at all, and that the -1 for the number of iterations is simply the (unchanged) initializer the SolverControl class uses for the number of iterations. So that would mean that it doesn't actually indicate an error. Can you check whether my interpretation is correct? If so, we should probably just remove the argument from the ArpackSolver class's constructor, as well as the corresponding member variable. Best W. -- Wolfgang Bangerth email: bange...@colostate.edu www: http://www.math.colostate.edu/~bangerth/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/24170177-20e2-ffe4-906e-4d1b2d9d549f%40colostate.edu.
[deal.II] Re: Query regarding DoFTools::dof_indices_with_subdomain_association()
Hello Vachan, Sounds like you're implementing nodal DG, hence why you only need values and gradients at the *quadrature* points from the neighbor. Something you might want to consider rather than communicating them at solution points, in case you ever decide to overintegrate. You could still ask for the unit support points and figure out which of >> them are geometrically on a given face. > > > This is definitely possible, but would probably be inefficient if I code > for it. Isn't there a function in DoFTools which does this? Because not > marking all dofs of ghost cells as relevant will give much savings in > communication, I was wondering if DoFTools already doesn't have an > implementation for this. > > I don't think there is currently an implementation. You should be able to mark your degrees of freedom on the subdomain interface using FE_DGQ::has_support_on_face(...). Basically, if you loop over the ghost elements, you can loop over the dof indices of the cell, and use that function to figure out if its on a face. Efficiency shouldn't be an issue, especially since this is pre-processing. > However, note that as soon as gradients are involved all the degrees of >> freedom contribute to values on faces. > > > I don't have much experience in parallel programming, but I think we can > circumvent this by computing gradients at all dof locations in a subdomain > and again only communicating data of dofs lying on subdomain interfaces. I > might need some correction on this :). > Yes, that works if you decide to first compute all your gradients and store them. Note that in 3D, you're doing 3x the communication for the face gradients, so your efficiency only shows up when using elements of order 4 or more. Depending on where you want to take your code in the future, I'd be careful with early code optimization like this. I would just stick with communicating all the neighbor's dofs and optimize the code if you really see a slowdown. Doug -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/da5650a9-9042-475b-8ce8-671d615ab9ab%40googlegroups.com.
Re: [deal.II] Convergence rate
Dear Felix, by any chance, did you take a look at step 10? https://www.dealii.org/current/doxygen/deal.II/step_10.html This step explains a little bit what to do when you want to solve on curved domains with high order finite elements. In particular, you need to ensure that the mapping you are using (from the reference element to the current element) is at least of the same order of your finite element method, if you want to achieve the correct convergence rates. In your case, you are using a MappingQ1 (the default mapping, if you don’t specify anything). With that, you won’t go beyond 2nd order in L2. If you use MappingQ2, you should see again the optimal convergence rates. Best, Luca. > On 10 Oct 2019, at 14:11, Félix Bunel wrote: > > Thanks for your answer ! > > I'm working in 2D on a disk ! > > This is my mesh on the 4 cycle of refinement (which I never use in practice > because it's not refined enough for what I want to do). > > > > I don't think I have a mapping object... > What i do to initalize my system on phi is : > //On génère le dofhandler > phi_dof_handler.distribute_dofs (phi_fe); > > //On génère les conditions aux bords > phi_constraints.clear(); > DoFTools::make_hanging_node_constraints(phi_dof_handler, phi_constraints); > VectorTools::interpolate_boundary_values(phi_dof_handler, > 0, > ZeroFunction<2>(1), > phi_constraints > ); > > //On créer le sparsity pattern > DynamicSparsityPattern dsp(phi_dof_handler.n_dofs()); > DoFTools::make_sparsity_pattern (phi_dof_handler, dsp); > phi_sparsity_pattern.copy_from(dsp); > > //On resize les objets à la bonne taille > phi_system_matrix.reinit (phi_sparsity_pattern); > phi_solution.reinit (phi_dof_handler.n_dofs()); > phi_old_solution.reinit (phi_dof_handler.n_dofs()); > phi_system_rhs.reinit (phi_dof_handler.n_dofs()); > > //On affiche les infos intéressantes > std::cout << YELLOW << " Nombre de degrés de liberté pour les angles > : " > << RESET << WHITE << phi_dof_handler.n_dofs() << RESET > << std::endl; > > > > Le jeudi 10 octobre 2019 14:00:23 UTC+2, Bruno Blais a écrit : > A quick question, since you are working on a sphere, are you specifying a > mapping of the same order as your phi? > > On Wednesday, 9 October 2019 08:57:45 UTC-4, Félix Bunel wrote: > Hello everyone. > > I'm having some trouble to understand the convergence rate i'm observing in > my code. > > Here is what i'm solving : > > - I'm in 2D on a round mesh. > - I'm solving a simple Poisson equation on this mesh for a variable named Phi > the solution is known for this and is 1-x^2-y^2 > - With this solution phi I'm then solving a Stokes equation that has special > terms that depends on phi. > > For the stokes problem i'm using the usual mixed fe element as such : > stokes_fe(FE_Q<2>(2), 2, > FE_Q<2>(1), 1), > So second order for the speeds and first order for the pressure (just like in > the boussinesq problem from the tutorials. > > For the poisson/phi problem, i'm using FE_Q<2> also > initialized as such : > phi_fe (2), > So second order. > > For a special case, I have a known solution which is u=v=0 and p of the form > 1-x^2-y^2 (just like phi) > And i have solved this on multiple refinement cycle which gives me different > number of dofs and cellsize. > > > The thing is, when I plot the error as a function of the maximum cell > diameter, I get a quadratic convergence rate for the speed, and a linear rate > for P and phi. > What surprises me is that I don't have a quadratic convergence rate for my > poisson/\phi problem even though I used > phi_fe (2), > > My norm is the L2 norm which is simply sqrt(sum(error**2))). I'm computing it > with python after exporting the solution as a gpl file. > Here are the graphs : > > > > I have also tried > phi_fe (1), > > But in this case I don't even have convergence for the speed. > > > > In my integration part, I have always used > QGauss<2> quadrature_formula(4); > which is equal to degree+2. > > So here are my questions : > > 1- Is this convergence rate the one i'm expecting for a poisson equation (phi > problem) ? > > 2- If no, any idea why I don't have the correct convergence rate ? > > 3- In the tutorial step 31, a degree of 2 is used for the temperature (which > is very similar to my phi), is there some reason for that choice (just like > using degree+1 for the speed and degree for the pressure in a stokes > problem...) > > Thanks in advance. > > -- > The deal.II project is located at http://www.dealii.org/ > For mailing list/forum options, see > https://groups.google.com/d/forum/dealii?hl=en > --- > You received this message because you are subscribed to the Google Groups
[deal.II] Re: Convergence rate
Thanks for your answer ! I'm working in 2D on a disk ! This is my mesh on the 4 cycle of refinement (which I never use in practice because it's not refined enough for what I want to do). I don't think I have a mapping object... What i do to initalize my system on phi is : //On génère le dofhandler phi_dof_handler.distribute_dofs (phi_fe); //On génère les conditions aux bords phi_constraints.clear(); DoFTools::make_hanging_node_constraints(phi_dof_handler, phi_constraints ); VectorTools::interpolate_boundary_values(phi_dof_handler, 0, ZeroFunction<2>(1), phi_constraints ); //On créer le sparsity pattern DynamicSparsityPattern dsp(phi_dof_handler.n_dofs()); DoFTools::make_sparsity_pattern (phi_dof_handler, dsp); phi_sparsity_pattern.copy_from(dsp); //On resize les objets à la bonne taille phi_system_matrix.reinit (phi_sparsity_pattern); phi_solution.reinit (phi_dof_handler.n_dofs()); phi_old_solution.reinit (phi_dof_handler.n_dofs()); phi_system_rhs.reinit (phi_dof_handler.n_dofs()); //On affiche les infos intéressantes std::cout << YELLOW << " Nombre de degrés de liberté pour les angles : " << RESET << WHITE << phi_dof_handler.n_dofs() << RESET << std::endl; Le jeudi 10 octobre 2019 14:00:23 UTC+2, Bruno Blais a écrit : > > A quick question, since you are working on a sphere, are you specifying a > mapping of the same order as your phi? > > On Wednesday, 9 October 2019 08:57:45 UTC-4, Félix Bunel wrote: >> >> Hello everyone. >> >> I'm having some trouble to understand the convergence rate i'm observing >> in my code. >> >> Here is what i'm solving : >> >> - I'm in 2D on a round mesh. >> - I'm solving a simple Poisson equation on this mesh for a variable named >> Phi the solution is known for this and is 1-x^2-y^2 >> - With this solution phi I'm then solving a Stokes equation that has >> special terms that depends on phi. >> >> For the stokes problem i'm using the usual mixed fe element as such : >> stokes_fe(FE_Q<2>(2), 2, >> FE_Q<2>(1), 1), >> So second order for the speeds and first order for the pressure (just >> like in the boussinesq problem from the tutorials. >> >> For the poisson/phi problem, i'm using FE_Q<2> also >> initialized as such : >> phi_fe (2), >> So second order. >> >> For a special case, I have a known solution which is u=v=0 and p of the >> form 1-x^2-y^2 (just like phi) >> And i have solved this on multiple refinement cycle which gives me >> different number of dofs and cellsize. >> >> The thing is, when I plot the error as a function of the maximum cell >> diameter, I get a quadratic convergence rate for the speed, and a linear >> rate for P and phi. >> What surprises me is that I don't have a quadratic convergence rate for >> my poisson/\phi problem even though I used >> phi_fe (2), >> >> My norm is the L2 norm which is simply sqrt(sum(error**2))). I'm >> computing it with python after exporting the solution as a gpl file. >> Here are the graphs : >> >> >> I have also tried >> phi_fe (1), >> >> But in this case I don't even have convergence for the speed. >> >> >> >> In my integration part, I have always used >> QGauss<2> quadrature_formula(4); >> which is equal to degree+2. >> >> So here are my questions : >> >> 1- Is this convergence rate the one i'm expecting for a poisson equation >> (phi problem) ? >> >> 2- If no, any idea why I don't have the correct convergence rate ? >> >> 3- In the tutorial step 31, a degree of 2 is used for the temperature >> (which is very similar to my phi), is there some reason for that choice >> (just like using degree+1 for the speed and degree for the pressure in a >> stokes problem...) >> >> Thanks in advance. >> > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/966a3637-8ca8-462a-bf7a-621746c9c6ad%40googlegroups.com.
[deal.II] Re: Convergence rate
A quick question, since you are working on a sphere, are you specifying a mapping of the same order as your phi? On Wednesday, 9 October 2019 08:57:45 UTC-4, Félix Bunel wrote: > > Hello everyone. > > I'm having some trouble to understand the convergence rate i'm observing > in my code. > > Here is what i'm solving : > > - I'm in 2D on a round mesh. > - I'm solving a simple Poisson equation on this mesh for a variable named > Phi the solution is known for this and is 1-x^2-y^2 > - With this solution phi I'm then solving a Stokes equation that has > special terms that depends on phi. > > For the stokes problem i'm using the usual mixed fe element as such : > stokes_fe(FE_Q<2>(2), 2, > FE_Q<2>(1), 1), > So second order for the speeds and first order for the pressure (just like > in the boussinesq problem from the tutorials. > > For the poisson/phi problem, i'm using FE_Q<2> also > initialized as such : > phi_fe (2), > So second order. > > For a special case, I have a known solution which is u=v=0 and p of the > form 1-x^2-y^2 (just like phi) > And i have solved this on multiple refinement cycle which gives me > different number of dofs and cellsize. > > The thing is, when I plot the error as a function of the maximum cell > diameter, I get a quadratic convergence rate for the speed, and a linear > rate for P and phi. > What surprises me is that I don't have a quadratic convergence rate for my > poisson/\phi problem even though I used > phi_fe (2), > > My norm is the L2 norm which is simply sqrt(sum(error**2))). I'm computing > it with python after exporting the solution as a gpl file. > Here are the graphs : > > > I have also tried > phi_fe (1), > > But in this case I don't even have convergence for the speed. > > > > In my integration part, I have always used > QGauss<2> quadrature_formula(4); > which is equal to degree+2. > > So here are my questions : > > 1- Is this convergence rate the one i'm expecting for a poisson equation > (phi problem) ? > > 2- If no, any idea why I don't have the correct convergence rate ? > > 3- In the tutorial step 31, a degree of 2 is used for the temperature > (which is very similar to my phi), is there some reason for that choice > (just like using degree+1 for the speed and degree for the pressure in a > stokes problem...) > > Thanks in advance. > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/bf2f032d-3aea-4149-a0b9-c91ecfe176b4%40googlegroups.com.
