[deal.II] Flux (cell interface) Value storage

For a particular project, I am facing a case where I would like to be able to store a single value for active cell interfaces, i.e. active cell boundaries stored in such a way that I would only need to touch each one once for actual computation. i would prefer not to use a matrix, since at

Re: [deal.II] configure deal.II with candi; UMFPCK switch not working

> Compiling my project went smoothly. However, running the executable gives me > the following error. > [...] > > The file > has > been deleted because it was the remnant of original build without candi. You are not using the newly built deal.II but your old installation. Remove your

Re: [deal.II] Triangulation neighbor information when using GridIn::read_vtk

I must admit that I don't really remember ... I think it was GridOut, since I specifically wanted to export only the grid and not some solution data. What dou you mean with "GridOut should work"? On Wednesday, July 26, 2017 at 9:04:16 PM UTC+2, Wolfgang Bangerth wrote: > > On 07/26/2017 12:55

Re: [deal.II] Triangulation neighbor information when using GridIn::read_vtk

On 07/26/2017 12:55 PM, sml.imf...@gmail.com wrote: Exactly, I generated it using GridOut. I see the problem now. I replaced all duplicate vertices in the vtk file, now it works as it should. Thanks for the clarification! Great. But just to clarify, you used GridOut or DataOut? The former

Re: [deal.II] Triangulation neighbor information when using GridIn::read_vtk

Exactly, I generated it using GridOut. I see the problem now. I replaced all duplicate vertices in the vtk file, now it works as it should. Thanks for the clarification! Best, Samuel On Wednesday, July 26, 2017 at 8:38:39 PM UTC+2, Wolfgang Bangerth wrote: > > On 07/26/2017 09:18 AM,

Re: [deal.II] Triangulation neighbor information when using GridIn::read_vtk

On 07/26/2017 09:18 AM, sml.imf...@gmail.com wrote: I am trying to read in a triangulation from a vtk file (generated by the dealii library). It works, but it seems like no information about neighboring cells is generated: iterating through the cells and calling cell->neighbor_index(face)

[deal.II] configure deal.II with candi; UMFPCK switch not working

*I first build deal II without candi, and realize lots of dependency packages are lacking. Then I switched to candi and modified candi.cfg file accordingly.* DEAL_CONFOPTS="\ -D DEAL_II_WITH_MPI:BOOL=ON \ -D DEAL_II_WITH_THREADS:BOOL=ON \ -D DEAL_II_FORCE_BUNDLED_THREADS:BOOL=OFF \ -D

[deal.II] Triangulation neighbor information when using GridIn::read_vtk

Hello all I am trying to read in a triangulation from a vtk file (generated by the dealii library). It works, but it seems like no information about neighboring cells is generated: iterating through the cells and calling cell->neighbor_index(face) always gives -1, indicating that the face is

[deal.II] Re: problem adding two blocks of BlockSparseMatrix

Dear Anna, > I am new to deal.ii > Welcome to the deal.II community! > when using LinearOperators I am not actually constructing the matrix, but > only know how such matrix would act on a vector. Am I correct? > Yes, thats exactly correct. > Could you please let me know whether I

[deal.II] Re: problem adding two blocks of BlockSparseMatrix

Dear Jean-Paul, I am new to deal.ii and C++ programming and never used Linear operators, so will have to study documentation. My understanding so far is that when using LinearOperators I am not actually constructing the matrix, but only know how such matrix would act on a vector. Am I correct?

[deal.II] Re: problem adding two blocks of BlockSparseMatrix

Dear Anna, You're welcome! I would say that LinearOperators would then be suitable to your application. It is possible to construct an inverse_operator , and the schur_complement

[deal.II] Re: problem adding two blocks of BlockSparseMatrix

Thank you for the prompt reply. The inverse of the matrix addition will be used to construct a preconditioner for the solution of the original system with FGMRES. On Wednesday, July 26, 2017 at 3:15:51 PM UTC+9, Jean-Paul Pelteret wrote: > > Dear Anna, > > So it appears that you're hitting this

[deal.II] Re: problem adding two blocks of BlockSparseMatrix

Dear Anna, So it appears that you're hitting this assertion , which is not checking that the sparsity pattern looks the same but rather that both blocks reference the same sparsity pattern object

[deal.II] Re: problem adding two blocks of BlockSparseMatrix

I have managed to subtract the two blocks by declaring SparseMatrixEZ tmp1; Is there a more efficient way? -- 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