[deal.II] Re: Different solution with different software
Felix, the usual approach for verifying your code is the method of manufactured solution. Choose functions that are elements of your ansatz space for all solution variables (possibly chaningyour grid to a cartesian one) and compute the corresponding right-hand side. Check that the error vanishes. If that works, choose smooth functions not part of your ansatz space and check the rate of convergence when refining your mesh. You may also want to have a look at https://www.dealii.org/8.5.0/doxygen/deal.II/step_7.html for this. Best, Daniel -- 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/eca2f947-b72f-4385-bba4-1c7e7b7baede%40googlegroups.com.
Re: [deal.II] Create a LinearOperator with a function instead of a matrix
> Would that work together with the GMG-preconditioner? You mean you want to use the linear operator as a smoother for the GMG? Or where in the GMG do you want to use it? > Will test it there as > soon as my problem in my second question could be solved. > There I have the following code: > | > SolverControl coarse_solver_control(1000,1e-10,false,false); > SolverGMRES coarse_solver(coarse_solver_control); > PreconditionIdentityid; > MGCoarseGridIterativeSolver SolverGMRES, > matrix_t, > PreconditionIdentity> > coarse_grid_solver(coarse_solver,coarse_matrix,id); > > usingSmoother=LA::MPI::PreconditionJacobi; > MGSmootherPreconditionmg_smoother; > mg_smoother.initialize(mg_matrices,Smoother::AdditionalData(0.5)); > mg_smoother.set_steps(2); > > mg::Matrixmg_matrix(mg_matrices); > mg::Matrixmg_interface_up(mg_interface_matrices); > mg::Matrixmg_interface_down(mg_interface_matrices); > > Multigridmg(mg_matrix,coarse_grid_solver,mg_transfer,mg_smoother,mg_smoother); > mg.set_edge_matrices(mg_interface_down,mg_interface_up); > > PreconditionMG>preconditioner(dof_handler, > > > mg, > > > mg_transfer); > | > > and here I intent to replace all occurences of matrix_t with my custom > LinearOperator (if that makes sense). I don't know the multigrid well enough, but I would expect that it really only wants something that has a vmult. My recommendation would be, if you don't know whether something would work, to just try it out. 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/6c2358d2-c9b6-1ca3-8212-8973a4aca5a4%40colostate.edu.
Re: [deal.II] Create a LinearOperator with a function instead of a matrix
Would that work together with the GMG-preconditioner? Will test it there as soon as my problem in my second question could be solved. There I have the following code: SolverControlcoarse_solver_control(1000, 1e-10, false, false); SolverGMRES coarse_solver(coarse_solver_control); PreconditionIdentity id; MGCoarseGridIterativeSolver, matrix_t, PreconditionIdentity> coarse_grid_solver(coarse_solver, coarse_matrix, id); using Smoother = LA::MPI::PreconditionJacobi; MGSmootherPrecondition mg_smoother; mg_smoother.initialize(mg_matrices, Smoother::AdditionalData(0.5)); mg_smoother.set_steps(2); mg::Matrix mg_matrix(mg_matrices); mg::Matrix mg_interface_up(mg_interface_matrices); mg::Matrix mg_interface_down(mg_interface_matrices); Multigrid mg(mg_matrix, coarse_grid_solver, mg_transfer, mg_smoother, mg_smoother); mg.set_edge_matrices(mg_interface_down, mg_interface_up); PreconditionMG> preconditioner(dof_handler, mg, mg_transfer); and here I intent to replace all occurences of matrix_t with my custom LinearOperator (if that makes sense). Am Freitag, 19. Juli 2019 17:51:10 UTC+2 schrieb Wolfgang Bangerth: > > On 7/19/19 9:47 AM, 'Maxi Miller' via deal.II User Group wrote: > > What I did was the replacement of system_matrix with a function, > providing a > > vmult()-function. Now I would like to add a preconditioner based on that > > function to reduce the necessary GMRES-iterations. But until now most of > the > > preconditioners require a matrix for initialization. Thus I wanted to > replace > > that matrix with my LinearOperator, if that is possible? > > Yes, as I already said, this is possible. Have you tried? > > I think you should also be able to look at step-20 (and maybe 22) for > examples. > > Best > W. > > -- > > Wolfgang Bangerth email: bang...@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/0c8f71f7-8d29-4a4f-abb1-65afbcc72669%40googlegroups.com.
Re: [deal.II] Code tries to access DoF indices on artificial cells, even though those cells should not be artificial
On 7/19/19 9:59 AM, 'Maxi Miller' via deal.II User Group wrote: > What do the parallel multigrid functions do? Could you just have your if() > inside that function -- i.e., it is called on all cells, but does nothing > if > the cell doesn't allow you to do anything? > > > That's exactly what my if()-conditions should do (but is not doing)... Then put a breakpoint on it and see why it isn't doing what you think it is doing :-) 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/8c84416e-5950-c50e-5cc4-c61b497e2c7a%40colostate.edu.
Re: [deal.II] Code tries to access DoF indices on artificial cells, even though those cells should not be artificial
> > What do the parallel multigrid functions do? Could you just have your if() > inside that function -- i.e., it is called on all cells, but does nothing > if > the cell doesn't allow you to do anything? > That's exactly what my if()-conditions should do (but is not doing)... Am Freitag, 19. Juli 2019 17:53:05 UTC+2 schrieb Wolfgang Bangerth: > > On 7/19/19 9:49 AM, 'Maxi Miller' via deal.II User Group wrote: > > I can not use that function, else I will get > > An error occurred in line <3543> of file > > in function > > bool dealii::CellAccessor::is_locally_owned() const > [with > > int dim = 2; int spacedim = 2] > > The violated condition was: > > this->active() > > Additional information: > > is_locally_owned() can only be called on active cells! > > Ah, I see. I missed that part. > > > > In my multigrid-assembly-function I have to loop over all cells, not > only the > > currently active cells (as it is stated in example 50: /we don't just > loop > > over all active cells, but in fact all cells, active or not/). Thus I > end up > > in that function. > > Hm, that's a question for the parallel multigrid folks then. > > What do the parallel multigrid functions do? Could you just have your if() > inside that function -- i.e., it is called on all cells, but does nothing > if > the cell doesn't allow you to do anything? > > Best > W. > > -- > > Wolfgang Bangerth email: bang...@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/3a65f070-a3b5-479b-acf7-f41272771b0f%40googlegroups.com.
Re: [deal.II] Code tries to access DoF indices on artificial cells, even though those cells should not be artificial
On 7/19/19 9:49 AM, 'Maxi Miller' via deal.II User Group wrote: > I can not use that function, else I will get > An error occurred in line <3543> of file > in function > bool dealii::CellAccessor::is_locally_owned() const [with > int dim = 2; int spacedim = 2] > The violated condition was: > this->active() > Additional information: > is_locally_owned() can only be called on active cells! Ah, I see. I missed that part. > In my multigrid-assembly-function I have to loop over all cells, not only the > currently active cells (as it is stated in example 50: /we don't just loop > over all active cells, but in fact all cells, active or not/). Thus I end up > in that function. Hm, that's a question for the parallel multigrid folks then. What do the parallel multigrid functions do? Could you just have your if() inside that function -- i.e., it is called on all cells, but does nothing if the cell doesn't allow you to do anything? 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/1a96dbbc-ae23-505a-9f66-6473d0ddf586%40colostate.edu.
Re: [deal.II] Create a LinearOperator with a function instead of a matrix
On 7/19/19 9:47 AM, 'Maxi Miller' via deal.II User Group wrote: > What I did was the replacement of system_matrix with a function, providing a > vmult()-function. Now I would like to add a preconditioner based on that > function to reduce the necessary GMRES-iterations. But until now most of the > preconditioners require a matrix for initialization. Thus I wanted to replace > that matrix with my LinearOperator, if that is possible? Yes, as I already said, this is possible. Have you tried? I think you should also be able to look at step-20 (and maybe 22) for examples. 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/9a9c4ce7-dbda-12e0-ceb6-325019686981%40colostate.edu.
Re: [deal.II] Some problems with Eclipse IDE
On 7/18/19 8:22 AM, Pawan Kumar wrote: > > I have recently updated my Ubuntu, deal.II and eclipse, I am getting some > warnings (red colored underlined as in attached screenshot). The eclipse > project was made using cmake and the paths are also seem correct(another > screenshot attached). These are not causing any error but bit irritating to > see red lines everywhere. > > I could not find any solution for this. Could someone please guide me how to > remove these warnings. Pawan, I don't think anyone here really understands how Eclipse parses things. It seems to work for most of us, but not because we know how to set things up, but because something in the internals of cmake and eclipse seem to have magically gotten stuff right. Out of curiosity, is the directory that eclipse shows for includes the *source* or the *installed* directory? It seems to know where to find the header files (or they would be underlined as well), so it knows *something*. If you open the first of the header files you include, does it seem to know about everything in there correctly? 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/a8d2af01-ffe5-9d51-6b6d-2a7fe95bd0d2%40colostate.edu.
Re: [deal.II] Code tries to access DoF indices on artificial cells, even though those cells should not be artificial
I can not use that function, else I will get An error occurred in line <3543> of file in function bool dealii::CellAccessor::is_locally_owned() const [with int dim = 2; int spacedim = 2] The violated condition was: this->active() Additional information: is_locally_owned() can only be called on active cells! In my multigrid-assembly-function I have to loop over all cells, not only the currently active cells (as it is stated in example 50: *we don't just loop over all active cells, but in fact all cells, active or not*). Thus I end up in that function. Am Freitag, 19. Juli 2019 17:37:01 UTC+2 schrieb Wolfgang Bangerth: > > On 7/19/19 9:31 AM, 'Maxi Miller' via deal.II User Group wrote: > > Based on the stacktrace the problematic access happens within > mg_cell_worker(): > > ... > > which is guarded by the if-condition. > > Then we have a miracle :-) You'll have to check in a debugger how you got > into > this place. If you go up to frame #8 (assemble_multigrid) you should be > able > why the function mg_cell_worker() was called and what the condition is > that > you checked/wanted to check. > > BTW, I typically use >cell->is_locally_owned() > in place of the more complicated condition you use. > > Best > W. > > -- > > Wolfgang Bangerth email: bang...@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/d78faba2-5bf4-4c49-a40b-a46eb7d1eb76%40googlegroups.com.
Re: [deal.II] Create a LinearOperator with a function instead of a matrix
What I did was the replacement of system_matrix with a function, providing a vmult()-function. Now I would like to add a preconditioner based on that function to reduce the necessary GMRES-iterations. But until now most of the preconditioners require a matrix for initialization. Thus I wanted to replace that matrix with my LinearOperator, if that is possible? -- 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/953da0b8-eb40-4ac1-8316-042c382f2978%40googlegroups.com.
Re: [deal.II] Create a LinearOperator with a function instead of a matrix
On 7/19/19 9:34 AM, 'Maxi Miller' via deal.II User Group wrote: > I.e. (based on step-37) I can write something like > | > LinearOperator jacobian_operator; > //vmult-operation is added later > > using SystemMatrixType = jacobian_operator; > SystemMatrixType system_matrix; > | > > and follow the example accordingly? No. `jacobian_operator` here is the name of a local variable, but in a `using` statement, the right hand side needs to be a *type*. What I'm saying is that you should be able to write something of the sort SolverCG<...> solver_cg; solver_cg.solve (system_matrix, solution, rhs, jacobian_operator); where the last argument is any kind of type that provides a vmult something -- whether it's a matrix, a class with a vmult function, or a linear operator. 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/73877be0-e337-bf85-2792-ba31837a91b1%40colostate.edu.
Re: [deal.II] Code tries to access DoF indices on artificial cells, even though those cells should not be artificial
On 7/19/19 9:31 AM, 'Maxi Miller' via deal.II User Group wrote: > Based on the stacktrace the problematic access happens within > mg_cell_worker(): > ... > which is guarded by the if-condition. Then we have a miracle :-) You'll have to check in a debugger how you got into this place. If you go up to frame #8 (assemble_multigrid) you should be able why the function mg_cell_worker() was called and what the condition is that you checked/wanted to check. BTW, I typically use cell->is_locally_owned() in place of the more complicated condition you use. 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/a2fbdc50-fa1c-5d00-abbc-ac2c681bb71f%40colostate.edu.
Re: [deal.II] Create a LinearOperator with a function instead of a matrix
I.e. (based on step-37) I can write something like LinearOperator jacobian_operator; //vmult-operation is added later using SystemMatrixType = jacobian_operator; SystemMatrixType system_matrix; and follow the example accordingly? Am Freitag, 19. Juli 2019 17:26:31 UTC+2 schrieb Wolfgang Bangerth: > > On 7/19/19 9:18 AM, 'Maxi Miller' via deal.II User Group wrote: > > Is it then possible to use this LinearOperator in a preconditioner? The > code > > works without one (i.e. PreconditionIdentity()), but the Iterations are > > increasing quite fast, thus negating all speedup gained from the > LinearOperator. > > I tried to find something in the examples, but only found data about > using > > matrices as input for preconditioners, not pure LinearOperators > containing > > only a vmult-function. > > Yes, this is supposed to work! > Best > W. > > -- > > Wolfgang Bangerth email: bang...@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/a77e57c0-c126-4b81-a41b-f95b45342897%40googlegroups.com.
Re: [deal.II] running the "The 'Goal-oriented mesh adaptivity in elastoplasticity problems' code gallery program "
Muhammad, > Hi! I am successful in running the code and it > is without a doubt a nice addition to deal.ii code gallery. It reproduces the > expected result for 3d Beam case now. Great. Can you say what you had to change to make things run? We should apply these changes to the version that is available on the web so that others don't have to figure this out like you had. > Since I did not find any thermomechanical coupled example so far in deal.ii > therefore I want to contribute in the development and widening the scope of > this code by coupling it with heat equation of step-26. > For this purpose , taking your lectures as a reference, Initially for testing > purpose (i.e. before importing temperature solution from step-26) , I have > added the thermal load in the /*cell_rhs*/ as following: > [...] > In the result the displacement result is qualitatively as per the expectation > i.e. the plate is expanding from other three ends but the System residuals in > Newton iterations are of the order of 1e+4 or even more. > I do not have much experience in under concentration mathematical approach or > I might be mistaking in writing the code for thermal loading force term as > per > deal.ii standards (because the /*rhs_values_body_force */term already present > in code is even bigger in numerical quantity than the thermal loading term > which is added by me but still it lets system converge for small residuals of > 1e-5 during solution) therefore I would be grateful to you for any guiding > response in my this course of development. Thank you! I'm not quite sure what your question is, but for sure step-26 is not using any physical units, so the solution there is not usable to define what the right order of magnitude is. In general, 1e+4 is not in itself a large number. You need to say what your units are, and compare that with the typical size of what you are considering. For example, if you consider the deformation of a bridge as you drive a truck over it, and you choose to express the deformation in micrometers, then 1e4 is not a large number. On the other hand, if you express the deformation in lightyears, then 1e4 *is* a large number. So the question you need to ask yourself is whether the residual is large *compared to what you would expect*. 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/42b31a35-a395-62a4-76cf-131bb90f86fd%40colostate.edu.
Re: [deal.II] Code tries to access DoF indices on artificial cells, even though those cells should not be artificial
Based on the stacktrace the problematic access happens within
mg_cell_worker():
Stacktrace:
---
#0 /opt/dealii/lib/libdeal_II.g.so.9.2.0-pre: void
dealii::DoFCellAccessor,
true>::get_dof_values(dealii::TrilinosWrappers::MPI::Vector const&, double*, double*)
const
#1 /opt/dealii/lib/libdeal_II.g.so.9.2.0-pre: void
dealii::DoFCellAccessor,
true>::get_dof_values(dealii::TrilinosWrappers::MPI::Vector const&,
dealii::Vector&) const
#2 /opt/dealii/lib/libdeal_II.g.so.9.2.0-pre: void
dealii::DoFCellAccessor,
true>::get_interpolated_dof_values(dealii::TrilinosWrappers::MPI::Vector const&,
dealii::Vector&, unsigned int) const
#3 /opt/dealii/lib/libdeal_II.g.so.9.2.0-pre: void
dealii::DoFCellAccessor,
true>::get_interpolated_dof_values(dealii::TrilinosWrappers::MPI::Vector const&,
dealii::Vector&, unsigned int) const
#4 /opt/dealii/lib/libdeal_II.g.so.9.2.0-pre: void
dealii::DoFCellAccessor,
true>::get_interpolated_dof_values(dealii::TrilinosWrappers::MPI::Vector const&,
dealii::Vector&, unsigned int) const
#5 /opt/dealii/lib/libdeal_II.g.so.9.2.0-pre: dealii::FEValuesBase<2,
2>::CellIterator, true> >
>::get_interpolated_dof_values(dealii::TrilinosWrappers::MPI::Vector
const&, dealii::Vector&) const
#6 /opt/dealii/lib/libdeal_II.g.so.9.2.0-pre: void dealii::FEValuesBase<2,
2>::get_function_gradients(dealii::TrilinosWrappers::MPI::Vector
const&, std::vector,
std::allocator > >&) const
#7 ./MG_test: void
Step15::MinimalSurfaceProblem<2>::mg_cell_worker, true> >
>(dealii::TriaIterator,
true> > const&, Step15::ScratchData<2>&, Step15::CopyData&)
#8 ./MG_test:
Step15::MinimalSurfaceProblem<2>::assemble_multigrid()::{lambda(dealii::TriaIterator, true> > const&, Step15::ScratchData<2>&,
Step15::CopyData&)#1}::operator()(dealii::TriaIterator, true> > const&, Step15::ScratchData<2>&, Step15::CopyData&) const
#9 ./MG_test: std::_Function_handler,
true> > const&, Step15::ScratchData<2>&, Step15::CopyData&),
Step15::MinimalSurfaceProblem<2>::assemble_multigrid()::{lambda(dealii::TriaIterator, true> > const&, Step15::ScratchData<2>&,
Step15::CopyData&)#1}>::_M_invoke(std::_Any_data const&,
dealii::TriaIterator,
true> > const&, Step15::ScratchData<2>&, Step15::CopyData&)
#10 ./MG_test: std::function,
true> > const&, Step15::ScratchData<2>&,
Step15::CopyData&)>::operator()(dealii::TriaIterator, true> > const&, Step15::ScratchData<2>&, Step15::CopyData&) const
#11 ./MG_test:
dealii::MeshWorker::mesh_loop, true> >, Step15::ScratchData<2>, Step15::CopyData,
dealii::TriaIterator,
true> >
>(dealii::TriaIterator,
true> > const&,
dealii::identity, true> > >::type const&, dealii::identity,
true> > const&, Step15::ScratchData<2>&, Step15::CopyData&)> >::type
const&, dealii::identity
>::type const&, Step15::ScratchData<2> const&, Step15::CopyData const&,
dealii::MeshWorker::AssembleFlags, dealii::identity,
true> > const&, unsigned int, Step15::ScratchData<2>&, Step15::CopyData&)>
>::type const&, dealii::identity,
true> > const&, unsigned int, unsigned int,
dealii::TriaIterator,
true> > const&, unsigned int, unsigned int, Step15::ScratchData<2>&,
Step15::CopyData&)> >::type const&, unsigned int, unsigned
int)::{lambda(dealii::TriaIterator, true> > const&, Step15::ScratchData<2>&,
Step15::CopyData&)#1}::operator()(dealii::TriaIterator, true> > const&, Step15::ScratchData<2>&, Step15::CopyData&) const
#12 ./MG_test: void
dealii::WorkStream::run, true> >, Step15::ScratchData<2>, Step15::CopyData,
dealii::TriaIterator,
true> >
>(dealii::TriaIterator,
true> > const&,
dealii::identity, true> > >::type const&, dealii::identity,
true> > const&, Step15::ScratchData<2>&, Step15::CopyData&)> >::type
const&, dealii::identity
>::type const&, Step15::ScratchData<2> const&, Step15::CopyData const&,
dealii::MeshWorker::AssembleFlags, dealii::identity,
true> > const&, unsigned int, Step15::ScratchData<2>&, Step15::CopyData&)>
>::type const&, dealii::identity,
true> > const&, unsigned int, unsigned int,
dealii::TriaIterator,
true> > const&, unsigned int, unsigned int, Step15::ScratchData<2>&,
Step15::CopyData&)> >::type const&, unsigned int, unsigned
int)::{lambda(dealii::TriaIterator, true> > const&, Step15::ScratchData<2>&, Step15::CopyData&)#1},
std::function,
dealii::TriaIterator,
true> >, Step15::ScratchData<2>,
Step15::CopyData>(dealii::TriaIterator, true> > const&,
dealii::identity, true> > >::type const&,
dealii::MeshWorker::mesh_loop, true> >, Step15::ScratchData<2>, Step15::CopyData,
dealii::TriaIterator,
true> >
>(dealii::TriaIterator,
true> > const&,
dealii::identity, true> > >::type const&, dealii::identity,
true> > const&, Step15::ScratchData<2>&, Step15::CopyData&)> >::type
const&, dealii::identity
>::type const&, Step15::ScratchData<2> const&, Step15::CopyData const&,
dealii::MeshWorker::AssembleFlags, dealii::identity,
true> > const&, unsigned int, Step15::ScratchData<2>&, Step15::CopyData&)>
>::type const&, dealii::identity,
true> >
Re: [deal.II] Create a LinearOperator with a function instead of a matrix
On 7/19/19 9:18 AM, 'Maxi Miller' via deal.II User Group wrote: > Is it then possible to use this LinearOperator in a preconditioner? The code > works without one (i.e. PreconditionIdentity()), but the Iterations are > increasing quite fast, thus negating all speedup gained from the > LinearOperator. > I tried to find something in the examples, but only found data about using > matrices as input for preconditioners, not pure LinearOperators containing > only a vmult-function. Yes, this is supposed to work! 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/8ff18c35-5f31-c35f-b79e-1eb3d3fde1a6%40colostate.edu.
Re: [deal.II] Code tries to access DoF indices on artificial cells, even though those cells should not be artificial
On 7/19/19 9:15 AM, 'Maxi Miller' via deal.II User Group wrote: > I am trying to port example 15 to a MPI-supported version, using the > geometric > multigrid method as preconditioner (to get more familiar with the > implementation). I followed example 50 while doing that, but currently I get > the error > An error occurred in line <3866> of file > <~/Downloads/git-files/dealii/include/deal.II/dofs/dof_accessor.templates.h> > in function > void dealii::DoFCellAccessor::get_dof_values(const > InputVector&, ForwardIterator, ForwardIterator) const [with InputVector = > dealii::TrilinosWrappers::MPI::Vector; ForwardIterator = double*; > DoFHandlerType = dealii::DoFHandler<2, 2>; bool level_dof_access = true] > The violated condition was: > this->is_artificial() == false > Additional information: > Can't ask for DoF indices on artificial cells. > as soon as I try to run my program using several MPI threads. I tried to > guard > that part using if (cell->level_subdomain_id() == > triangulation.locally_owned_subdomain()) as suggested in step-50, but that > did > not help. Why am I still trying to request data from artificial cells, even > though I guarded that code part (at least I assume it guards it accordingly). Are you sure you guarded the right place? Have you checked with a debugger where the problem actually happens? Best WB -- 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/c12c4887-a6ee-a3ad-d19e-5ca53d448afc%40colostate.edu.
Re: [deal.II] Create a LinearOperator with a function instead of a matrix
Is it then possible to use this LinearOperator in a preconditioner? The
code works without one (i.e. PreconditionIdentity()), but the Iterations
are increasing quite fast, thus negating all speedup gained from the
LinearOperator.
I tried to find something in the examples, but only found data about using
matrices as input for preconditioners, not pure LinearOperators containing
only a vmult-function.
Am Dienstag, 16. Juli 2019 18:21:28 UTC+2 schrieb Matthias Maier:
>
> A short comment:
>
> On Tue, Jul 16, 2019, at 11:18 CDT, Matthias Maier > wrote:
>
> > struct LeftVector {
> > };
>
> > struct RightVector {
> > };
>
> These two classes are of course just decoration (showing the minimal
> interface a vector has to possess). There is usually no need to define
> custom Vector clases.
>
--
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/c7bc4fb5-1cf7-46ce-af94-2bd5a796715d%40googlegroups.com.
[deal.II] Code tries to access DoF indices on artificial cells, even though those cells should not be artificial
I am trying to port example 15 to a MPI-supported version, using the
geometric multigrid method as preconditioner (to get more familiar with the
implementation). I followed example 50 while doing that, but currently I
get the error
An error occurred in line <3866> of file
<~/Downloads/git-files/dealii/include/deal.II/dofs/dof_accessor.templates.h>
in function
void dealii::DoFCellAccessor::get_dof_values(const
InputVector&, ForwardIterator, ForwardIterator) const [with InputVector =
dealii::TrilinosWrappers::MPI::Vector; ForwardIterator = double*;
DoFHandlerType = dealii::DoFHandler<2, 2>; bool level_dof_access = true]
The violated condition was:
this->is_artificial() == false
Additional information:
Can't ask for DoF indices on artificial cells.
as soon as I try to run my program using several MPI threads. I tried to
guard that part using if (cell->level_subdomain_id() ==
triangulation.locally_owned_subdomain()) as suggested in step-50, but that
did not help. Why am I still trying to request data from artificial cells,
even though I guarded that code part (at least I assume it guards it
accordingly).
Thanks!
--
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/d7eecf00-5fce-46c7-a191-a6d6261dac35%40googlegroups.com.
/* -
*
* Copyright (C) 2012 - 2019 by the deal.II authors
*
* This file is part of the deal.II library.
*
* The deal.II library is free software; you can use it, redistribute
* it, and/or modify it under the terms of the GNU Lesser General
* Public License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
* The full text of the license can be found in the file LICENSE.md at
* the top level directory of deal.II.
*
* -
*
* Author: Sven Wetterauer, University of Heidelberg, 2012
*/
// @sect3{Include files}
// The first few files have already been covered in previous examples and will
// thus not be further commented on.
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
// We will use adaptive mesh refinement between Newton iterations. To do so,
// we need to be able to work with a solution on the new mesh, although it was
// computed on the old one. The SolutionTransfer class transfers the solution
// from the old to the new mesh:
#include
// We then open a namespace for this program and import everything from the
// dealii namespace into it, as in previous programs:
namespace Step15
{
using namespace dealii;
namespace LA{
using namespace dealii::LinearAlgebraTrilinos;
}
template
struct ScratchData
{
ScratchData(const Mapping & mapping,
const FiniteElement ,
const unsigned intquadrature_degree,
const UpdateFlags update_flags)
: fe_values(mapping, fe, QGauss(quadrature_degree), update_flags)
{}
ScratchData(const ScratchData _data)
: fe_values(scratch_data.fe_values.get_mapping(),
scratch_data.fe_values.get_fe(),
scratch_data.fe_values.get_quadrature(),
scratch_data.fe_values.get_update_flags())
{}
FEValues fe_values;
};
struct CopyData
{
unsigned int level;
FullMatrix cell_matrix;
Vector cell_rhs;
std::vector local_dof_indices;
template
void reinit(const Iterator , unsigned int dofs_per_cell)
{
cell_matrix.reinit(dofs_per_cell, dofs_per_cell);
cell_rhs.reinit(dofs_per_cell);
local_dof_indices.resize(dofs_per_cell);
cell->get_active_or_mg_dof_indices(local_dof_indices);
level = cell->level();
}
};
// @sect3{The MinimalSurfaceProblem class template}
// The class template is basically the same as in step-6. Three additions
// are made:
// - There are two solution vectors, one for the Newton update
// $\delta u^n$, and one for the current iterate $u^n$.
// - The setup_system function takes an argument that denotes
// whether this is the first time it is called or not. The difference is
// that the first time around we need to distribute the degrees of freedom
// and set the solution vector for
Re: [deal.II] Re: Porting tutorials to PETSc from Trilinos
Franco Le ven. 19 juil. 2019 à 10:04, Franco Milicchio a écrit : > Is there a small documentation that I can read? For instance, I see there are > several namespaces like LinearAlgebra, PETSc/Epetra/Trilinos/CUDAWrappers, > LinearAlgebraDealii and so on, that might be restructured without > compromising old codes, adding some uniformity to classes. No unfortunately we don't have such things. However, most of the new effort on linear algebra is in the LinearAlgebra namespace. > > An error occurred in line <3781> of file > > in function > void dealii::AffineConstraints::distribute_local_to_global(const > FullMatrix &, const Vector &, const std::vector &, > MatrixType &, VectorType &, bool, std::integral_constant) const > [number = double, MatrixType = dealii::BlockSparseMatrix, VectorType > = dealii::BlockVector] > The violated condition was: > static_cast std::common_type decltype(global_vector.size())>::type)>::type>(global_matrix.m()) == > static_cast std::common_type decltype(global_vector.size())>::type)>::type>(global_vector.size()) > Additional information: I don't know why this error is so unreadable but if you look at line 3781 in include/deal.II/lac/affine_constraints.templates.h you will see that the assert checks that the global matrix has as many rows has the global vector. To me it looks like the problem is that the global vector as a size of zero. If you forget about the static_cast in the error message just above you can actually see what happens: The violated condition was: global_matrix.m() == global_vector.size() Best, Bruno -- 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/CAGVt9eM%2Bg5HhuJOyQ3%3D-D__EbUyf7tZS5ZqyTu32rxVN1S-vXw%40mail.gmail.com.
Re: [deal.II] Re: Porting tutorials to PETSc from Trilinos
> > Thanks for your answer. By the way, would a wrapper for the Eigen > library be appealing to anyone? > I am sure it would be useful! > > Good to know, Bruno. I will start looking into those wrappers and I hope some student of mine will be helping (fingers crossed). Is there a small documentation that I can read? For instance, I see there are several namespaces like LinearAlgebra, PETSc/Epetra/Trilinos/CUDAWrappers, LinearAlgebraDealii and so on, that might be restructured without compromising old codes, adding some uniformity to classes. > > It looks like the sparsity pattern does not exist anymore. The matrix > object does not keep a copy of the sparsity pattern, so the sparsity > pattern needs to exist as long as the matrix that uses it is alive. > > Thanks, that did the trick! The problem now moved to the AffineConstraints (which I didn't touch) complaining about dimensions: An error occurred in line <3781> of file in function void dealii::AffineConstraints::distribute_local_to_global(const FullMatrix &, const Vector &, const std::vector &, MatrixType &, VectorType &, bool, std::integral_constant) const [number = double, MatrixType = dealii::BlockSparseMatrix, VectorType = dealii::BlockVector] The violated condition was: static_cast::type)>::type>(global_matrix.m()) == static_cast::type)>::type>(global_vector.size()) Additional information: Dimension 2467 not equal to 0. Stacktrace: --- #0 2 libdeal_II.g.9.1.0.dylib0x0001164eb3a2 _ZNK6dealii17AffineConstraintsIdE26distribute_local_to_globalINS_17BlockSparseMatrixIdEENS_11BlockVectorIdvRKNS_10FullMatrixIdEERKNS_6VectorIdEERKNSt3__16vectorIjNSF_9allocatorIjRT_RT0_bNSF_17integral_constantIbLb1EEE + 1570: 2 libdeal_II.g.9.1.0.dylib0x0001164eb3a2 _ZNK6dealii17AffineConstraintsIdE26distribute_local_to_globalINS_17BlockSparseMatrixIdEENS_11BlockVectorIdvRKNS_10FullMatrixIdEERKNS_6VectorIdEERKNSt3__16vectorIjNSF_9allocatorIjRT_RT0_bNSF_17integral_constantIbLb1EEE #1 3 step-31 0x000108d5b641 _ZN6Step3121BoussinesqFlowProblemILi2EE22assemble_stokes_systemEv + 1953: 3 step-31 0x000108d5b641 _ZN6Step3121BoussinesqFlowProblemILi2EE22assemble_stokes_systemEv #2 4 step-31 0x000108d4e468 _ZN6Step3121BoussinesqFlowProblemILi2EE3runEv + 504: 4 step-31 0x000108d4e468 _ZN6Step3121BoussinesqFlowProblemILi2EE3runEv #3 5 step-31 0x000108d4de6d main + 125: 5 step-31 0x000108d4de6d main #4 6 libdyld.dylib 0x7fff6bbd93d5 start + 1: 6 libdyld.dylib 0x7fff6bbd93d5 start #5 7 ??? 0x0001 0x0 + 1: 7 ??? 0x0001 0x0 Signal: SIGABRT (signal SIGABRT) on this line (initial timestep): if (rebuild_stokes_matrix == true) stokes_constraints.distribute_local_to_global(local_matrix, local_rhs, local_dof_indices, stokes_matrix, stokes_rhs); The stokes_constraints.distribute_local_to_global apparently doesn't like how I implemented the sparsity patterns to build the matrices. All I did here is to add two sparsity patterns, one for the Stokes matrix, and one for the temperature: stokes_matrix_sp.reinit(2, 2); // probably unnecessary stokes_matrix_sp.copy_from(dsp); stokes_matrix.reinit(stokes_matrix_sp); //stokes_matrix.reinit(dsp); BlockSparsityPattern stokes_matrix_sp; // the definition I am probably doing something terribly stupid here... Thanks for any help! Franco -- 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/a7e083cb-8448-4840-aa0d-acb73e1207df%40googlegroups.com.
Re: [deal.II] Re: Porting tutorials to PETSc from Trilinos
> > Thanks for your answer. By the way, would a wrapper for the Eigen > library be appealing to anyone? > I am sure it would be useful! > > Good to know, Bruno. I will start looking into those wrappers and I hope some student of mine will be helping (fingers crossed). Is there a small documentation that I can read? For instance, I see there are several namespaces like LinearAlgebra, PETSc/Epetra/Trilinos/CUDAWrappers, LinearAlgebraDealii and so on, that might be restructured without compromising old codes, adding some uniformity to classes. > > It looks like the sparsity pattern does not exist anymore. The matrix > object does not keep a copy of the sparsity pattern, so the sparsity > pattern needs to exist as long as the matrix that uses it is alive. > > Thanks, that did the trick! The problem now moved to the AffineConstraints (which I didn't touch) complaining about dimensions: An error occurred in line <3781> of file in function void dealii::AffineConstraints::distribute_local_to_global(const FullMatrix &, const Vector &, const std::vector &, MatrixType &, VectorType &, bool, std::integral_constant) const [number = double, MatrixType = dealii::BlockSparseMatrix, VectorType = dealii::BlockVector] The violated condition was: static_cast::type)>::type>(global_matrix.m()) == static_cast::type)>::type>(global_vector.size()) Additional information: Dimension 2467 not equal to 0. Stacktrace: --- #0 2 libdeal_II.g.9.1.0.dylib0x0001164eb3a2 _ZNK6dealii17AffineConstraintsIdE26distribute_local_to_globalINS_17BlockSparseMatrixIdEENS_11BlockVectorIdvRKNS_10FullMatrixIdEERKNS_6VectorIdEERKNSt3__16vectorIjNSF_9allocatorIjRT_RT0_bNSF_17integral_constantIbLb1EEE + 1570: 2 libdeal_II.g.9.1.0.dylib0x0001164eb3a2 _ZNK6dealii17AffineConstraintsIdE26distribute_local_to_globalINS_17BlockSparseMatrixIdEENS_11BlockVectorIdvRKNS_10FullMatrixIdEERKNS_6VectorIdEERKNSt3__16vectorIjNSF_9allocatorIjRT_RT0_bNSF_17integral_constantIbLb1EEE #1 3 step-31 0x000108d5b641 _ZN6Step3121BoussinesqFlowProblemILi2EE22assemble_stokes_systemEv + 1953: 3 step-31 0x000108d5b641 _ZN6Step3121BoussinesqFlowProblemILi2EE22assemble_stokes_systemEv #2 4 step-31 0x000108d4e468 _ZN6Step3121BoussinesqFlowProblemILi2EE3runEv + 504: 4 step-31 0x000108d4e468 _ZN6Step3121BoussinesqFlowProblemILi2EE3runEv #3 5 step-31 0x000108d4de6d main + 125: 5 step-31 0x000108d4de6d main #4 6 libdyld.dylib 0x7fff6bbd93d5 start + 1: 6 libdyld.dylib 0x7fff6bbd93d5 start #5 7 ??? 0x0001 0x0 + 1: 7 ??? 0x0001 0x0 Signal: SIGABRT (signal SIGABRT) on this line (initial timestep): if (rebuild_stokes_matrix == true) stokes_constraints.distribute_local_to_global(local_matrix, local_rhs, local_dof_indices, stokes_matrix, stokes_rhs); The stokes_constraints.distribute_local_to_global apparently doesn't like how I implemented the sparsity patterns to build the matrices. All I did here is to add two sparsity patterns, one for the Stokes matrix, and one for the temperature: stokes_matrix_sp.reinit(2, 2); // probably unnecessary stokes_matrix_sp.copy_from(dsp); stokes_matrix.reinit(stokes_matrix_sp); //stokes_matrix.reinit(dsp); BlockSparsityPattern stokes_matrix_sp; // the definition stokes_matrix_sp.copy_from(dsp); stokes_matrix.reinit(stokes_matrix_sp); //stokes_matrix.reinit(dsp); I am probably doing something terribly stupid here... Thanks for any help! Franco -- 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/3bbde225-e547-43ab-abf3-2ef53dd09559%40googlegroups.com.
Re: [deal.II] Re: Compatibility of Petsc with step 18
Hi Daniel, The problem is now solved. The issue was that, the bash rc did not have the location of PETSc. This line in the bash file solved the problem "export PETSC_DIR=/path/to/petsc-x-y-z"" Regards, Ramprasad On Wed, Jul 17, 2019 at 5:31 PM Bruno Turcksin wrote: > Ramprasad, > > Le mer. 17 juil. 2019 à 11:24, Ramprasad R > a écrit : > > Yes I did recompile it. The details of the config files are in the > attachment. > There is something strange in you installation: detailed.log says that > you are using PETSc but config.h says that you are not. It looks like > you compiled deal.II without PETSc and then in the same directory > recompiled deal.II with PETSc supports. This can cause the strange > behavior that you are seeing. Remove your build directory and > reinstall deal.II from scratch. > > Best, > > Bruno > > -- > 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/CAGVt9eP5bqzDKi5CHFW0%3DeMF1bv%3DALRVJg2z61T2bZZEUronjA%40mail.gmail.com > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAKS2Wq5OCjHG3m39AsTsVyz8hBC%3DNV-ddZfhz-%3DHZ0DKew0XhQ%40mail.gmail.com.
