### [deal.II] Bug in sparse_matrix.templates.h

Dear all, Matrix multiplication requires resulting matrix to be initialized. Even if rebuild_sparsity_C = true . template template void SparseMatrix::mmult (SparseMatrix , const SparseMatrix , const Vector,

### [deal.II] Bug in FEEvaluationAccess::get_symmetric_gradient with Number =float

Dear all, In following line: line 4545 of /include/deal.II/matrix_free/fe_evaluation.h: VectorizedArray half = make_vectorized_array (0.5); 0.5 is interpreted as double and it leads to using make_vectorized_array. That is OK if Number=double but for any other type (eg. float) it results is

### Re: [deal.II] Matrix-Free framework for vector problems: no assertion for components

W dniu niedziela, 8 października 2017 12:55:02 UTC+2 użytkownik Martin Kronbichler napisał: > > Dear Michal, > > Could you please be a bit more specific? What was the error that you > obtained? What vector did you pass into > FEEvaluation::read_dof_values/distribute_local_to_global? I guess

### Re: [deal.II] Bug in FEEvaluationAccess::get_symmetric_gradient with Number =float

I've tried to create pull request, but I've got error message: mwichro@Preludio:~/lib/dealii$ git push origin fix_feevaluation_float_inst Username for 'https://github.com': mwichro Password for 'https://mwic...@github.com': remote: Permission to dealii/dealii.git denied to mwichro. fatal:

### [deal.II] Block problem +MatrixFree

on one block? For example I would like to compute approximation of A^-1 using multigrid. Michał Wichrowski -- 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

### Re: [deal.II] Block problem +MatrixFree

W dniu wtorek, 26 września 2017 18:42:33 UTC+2 użytkownik Wolfgang Bangerth napisał: > > On 09/26/2017 09:42 AM, Michał Wichrowski wrote: > > > > 3) Is there a way to use multigrid on one block? For example I would > > like to compute approximation of A^-1 using mu

### [deal.II] Re: Block problem +MatrixFree

> > > I've started working on new version MGTransferBlockMatrixFree and I now > see the problem. MGTransferBlockMatrixFree is easy to rewrite using vector > of dof handres etc, but PreconditionMG requires MGTransfer that have > copy_to_mg and copy_from_mg that work on single dof handre. I am

### [deal.II] Re: Block problem +MatrixFree

W dniu wtorek, 26 września 2017 20:37:59 UTC+2 użytkownik Daniel Arndt napisał: > > Michael, > > Adding to Wolfgang's response: > > Am Dienstag, 26. September 2017 17:42:41 UTC+2 schrieb Michał Wichrowski: >> >> Dear all, >> I'm dealing with Stokes problem th

### [deal.II] Selective use of blocks in MatrixFree

operator (B from Stokes). However, vmult checks requires src and dst to have same size and throws an error. I'm not sure if pre and post processing of constraints will work on non-square matrix. Michał Wichrowski The Divergence operator is defined as follows: template class DivergenceOperator

### [deal.II] Re: Block problem +MatrixFree

W dniu niedziela, 1 października 2017 21:20:06 UTC+2 użytkownik Daniel Arndt napisał: > > Michael, > > I implemented something similar to what you proposed. You might want to > have a look at https://github.com/dealii/dealii/pull/5175 > > Best, > Daniel > > Thanks, for now I'm using mine

### [deal.II] Matrix-free: Computing coefficient involving material ID

Dear all, How can I compute coefficient based on material ID? I tried: template template inline void SymGradMass::evaluate_coefficient( std::map& rho_map, std::map& miu_map) { return; const unsigned int n_cells = this->data->n_macro_cells(); rho.resize (n_cells);

### [deal.II] Matrix-Free framework for vector problems: no assertion for components

. The program worked and even covered in reasonable number of iterations. I think FEEvaluation is right place to put this assertion. Michał Wichrowski -- 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

### Re: [deal.II] Non-homogeneus boundary conditions with-matrix-free not working

W dniu sobota, 28 października 2017 18:52:57 UTC+2 użytkownik Martin Kronbichler napisał: > > Dear Michal, > > You mean because once you apply an inhomogeneous Dirichlet condition on > the velocity you also get a contribution because the divergence is not > zero? Exactly. > You could

### Re: [deal.II] Non-homogeneus boundary conditions with-matrix-free not working

That's very bad news for me. This workaround will work for Laplace problem but not for my case. I'm dealing with Stokes problem and my method requires that second block of right hand side is zero, otherwise MinRes crashes and GMRES have to be used (that is far less effective). Can You give me

### Re: [deal.II] Non-homogeneus boundary conditions with-matrix-free not working

I think that the problem can be avoided by splitting operator A into two parts: dirichlet nodes and other. The structure will be: A1 0 0I and the operator A1 applies matrix-vector product using fixed values on Dirichlet nodes. If I got it right, the problem is with this part of code: Line:

### Re: [deal.II] Non-homogeneus boundary conditions with-matrix-free not working

Dear Martin, I finally managed to make it work by following Your idea. Thanks! Michał -- 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

### [deal.II] LinearOperator -- inverse_operator : Payload for LinearAlgebra::distributed::Vector

Dear all, I'm trying to use iterative inverse with distributed deal.II vector. From following lines const auto S= linear_operator (mg_sc_matrices[level]); const auto Shat = inverse_operator(S,solver,SCPreconditionMGs[level]); I get compilation errors:

### Re: [deal.II] LinearOperator -- inverse_operator : Payload for LinearAlgebra::distributed::Vector

;). > The example should be as short as possible and doesn't need to be > functional / or do anything at all - we essentially only need to be able > to figure out the types you try to wrap into the linear_operator object. > > Best, > Matthias > > > On Tue, Feb 13, 201

### [deal.II] source/base/mpi.cc headers

Dear all, I had some trouble while compiling deal.II on my cluster: [ 70%] Building CXX object source/fe/CMakeFiles/obj_fe_release.dir/fe_tools.cc.o /home/mwichro/lib/dealii-9.0.0/source/base/mpi.cc: In function 'int dealii::Utilities::MPI::create_group(ompi_communicator_t* const&,

### [deal.II] Re: Computing min and max eigenvalues

W dniu czwartek, 18 października 2018 17:59:40 UTC+2 użytkownik Bruno Turcksin napisał: > > Michal, > > Have you tried to use ARPACK to get the smallest eigenvalues? That's what > we are doing in one of our code and it works pretty well. We have a patch > here >

### [deal.II] Computing min and max eigenvalues

Dear all, I need to compute the minimum and maximum eigenvalues of the matrix-free operator (vmult is only available ). For the largest eigenvalue, I'm using the power method, but I have some problems with minimal eigenvalue. The condition number of the operator is close to 1, so I tried using

### Re: [deal.II] Re: Computing min and max eigenvalues

Dear Bruno > > > 2) The largest eigenvalue is computed instead of the largest one, and, I > guess, the smallest eigenvalue is computed instead of the largest one. > If you use ARPACK through deal without patching it, then the only > method available is shift-inverse. The thing is that when

### Re: [deal.II] Re: Computing min and max eigenvalues

Earl, I am posing this question purely out of personal interest: what do you mean > by maximum and minimum eigenvalue? I am confused by this. > > The eigenvalues with largest and smallest magnitude. My problem is symmetric positive-definite, thus the spectrum is real and positive, so in my

### [deal.II] Re: Computing min and max eigenvalues

PS. I noticed that in some cases the "smallest" eigenvalue does not match maximum eigenvalue obtained from power method. -- 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

### [deal.II] Re: Computing min and max eigenvalues

Dear Bruno, I've used ARPACK and the computation time has dropped signifficantly. But I have some strange results, I have following code: IterationNumberControl arpack_control(30, 1e-8); typename ArpackSolver::AdditionalData arpack_data_smallest(30,

### [deal.II] Compilation error: use of deleted function

Dear all, I have errors when compiling my code with the devellpment version of deal.II . The same problems occurs also with 9.0.0, the code works well with 9.0.0-pre. I have no idea how to resolve these problems. Michał /home/mwichro/lib/deal.II/include/deal.II/multigrid/multigrid.h:137:7:

### Re: [deal.II] Compilation error: use of deleted function

> > Michal, > the error is in your code, but since I don't have it, I can't tell > where. I suspect that you are trying to copy an object of type > Multigrid, in StokeMatrixFree/StokesMatrixFree.cc:34 of your project. > This copy may happen implicitly if you call a function that takes a >

### Re: [deal.II] Compilation error: use of deleted function

W dniu wtorek, 25 września 2018 15:30:06 UTC+2 użytkownik Wolfgang Bangerth napisał: > > On 09/25/2018 05:56 AM, Michał Wichrowski wrote: > > > > Yep, I am trying to copy Multigrid object on purpose, I found the line > > corresponding to the problem: > >

### Re: [deal.II] Compilation error: use of deleted function

> > On 09/25/2018 07:38 AM, Michał Wichrowski wrote: > > > > > > Yes, I need triangulation.n_global_levels() copies of multigrid. I > modify each > > of them in next line: > > > >std::vector > > > multigrids_sc(triangulation.n_

### [deal.II] Multigrid starting from other level than finest does not work with adaptive refinement

Dear all, I am able to reproduce the problem with modified step-37, I expect the similar problem in case of multigrid with sparse matrices. The problem occurs only if mesh is refined adaptively. I added refine_mesh() function and modified solve(): // //work on level 3, that is not the

### [deal.II] Re: copy_triangulation removes limit_level_difference_at_vertices flag

Done: https://github.com/dealii/dealii/issues/7581 W dniu wtorek, 8 stycznia 2019 23:42:06 UTC+1 użytkownik Daniel Arndt napisał: > > Michal, > > not setting `limit_level_difference_at_vertices` when copying a > parallel::distributed::Triangulation can be considered an oversight/bug. > Do you

### [deal.II] copy_triangulation removes limit_level_difference_at_vertices flag

Dear all, I noticed that if I do the following: parallel::distributed::Triangulation triangulation(MPI_COMM_WORLD, parallel::distributed::Triangulation::limit_level_difference_at_vertices, parallel::distributed::Triangulation::construct_multigrid_hierarchy); Triangulation

### Re: [deal.II] Compilation problem with Development sources

W dniu poniedziałek, 17 września 2018 16:10:32 UTC+2 użytkownik Jean-Paul Pelteret napisał: > > Dear Michał, > > I think that calling *git checkout* is insufficient. You probably want to > call* git pull *(or* git fetch && git rebase origin/master*) to fetch and > merge the most current state

### [deal.II] Compilation problem with Development sources

Dear all, I had a problem while compiling deal.II source code from the git repository: [ 72%] Building CXX object source/algorithms/CMakeFiles/obj_algorithms_debug.dir/operator.cc.o In file included from /home/mwichro/lib/dealii/include/deal.II/algorithms/any_data.h:21:0, from

### [deal.II] Re: Compilation problem with Development sources

I've just double checked, I'm using the latest version: mwichro@major:~/lib/dealii$ git checkout Your branch is up-to-date with 'origin/master'. mwichro@major:~/lib/dealii$ make [ 0%] Built target expand_instantiations_exe [ 0%] Built target doxygen_headers [ 3%] Built target

### [deal.II] Adding random filling functionality to vector classes

Dear all, It nothing big, but I thing adding method fill_random(const double& a=-1., const double =1.) to vector classes that will fill a vector with random values (from range [a,b]) would be useful. I'm using it in most of my programs, it's great for testing solvers, especially multigrid

### Re: [deal.II] MGTransferBlockMatrixFree< dim, Number > ::clear rrmoves number of blocks

> > > So you want to a separate function that calls the current interface with > default constructed MGConstraindedDoFs objects? > We are happy to have a look and discuss if you create a pull request for > this. > > Thanks, for reporting the problem with the default constructor. I will > have

### [deal.II] MGTransferBlockMatrixFree< dim, Number > ::clear rrmoves number of blocks

Dear all, I found out that calling MGTransferBlockMatrixFree< dim, Number > ::clear sets the number of blocks to 0/ It is followed directly by build(dofs); will thow an exeption: Additional information: Dimension 0 not equal to 2. There is no way to set number of block properly other than

### [deal.II] DG Matrix-free: getting face iterator form

Dear all, I'm trying to use matrix-free with discontinuous Galerkin elements for variable coefficient problem. The face integral require access to value of coefficient. For the cell I've done the following thing: //Vectors of values, stored in object: AlignedVector< VectorizedArray > mu;

### Re: [deal.II] DG Matrix-free: getting face iterator form

> Dear Martin > > We do not offer convenience access for all data structures on faces yet, > so feel free to suggest what you need. > 1) functions similar to get_cell_iterator for getting iterator to interior/exterior cell + face index: std::pair::cell_iterator, unstigned int>