[deal.II] Re: error encountered while using matrix free in GPU with periodic BCs

Hi Bruno, Thank you for your reply. Vishal and me are collaborating on implementing hybrid functionals in the DFT-FE code, with Vishal taking the lead on this project. Our exploration of the GPU ported matrix-free poisson solve in GPU is in that context. I did take a look at the

Re: [deal.II] Compilation error in dealii development version (9.1.0-pre, shortrev c6b7876) using gcc/7.2.0 compiler and cuda/9.2

Hi Daniel, The third issue is fixed in https://github.com/dealii/dealii/pull/7213 > > . Thank you for creating the fix. the first issue you observed is related to >

Re: [deal.II] Compilation error in dealii development version (9.1.0-pre, shortrev c6b7876) using gcc/7.2.0 compiler and cuda/9.2

It seems the issue is related to -DDEAL_II_WITH_64BIT_INDICES=ON. If I set -DDEAL_II_WITH_64BIT_INDICES=OFF, the compilation worked fine. Best, Sambit On Tuesday, September 18, 2018 at 11:17:43 PM UTC-5, Sambit Das wrote: > > Hi Bruno and Jean, > > Based on the discussion in (https:

Re: [deal.II] Compilation error in dealii development version (9.1.0-pre, shortrev c6b7876) using gcc/7.2.0 compiler and cuda/9.2

compilation error is related to the original issue in (https://github.com/dealii/dealii/issues/7204 <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fdealii%2Fdealii%2Fissues%2F7204=D=1=AFQjCNFWFhH2gmvYaboY3_Dm_fEIvD4wxQ> )? Thank you, Sambit On Tuesday, September 18, 2018 at 1

Re: [deal.II] Compilation error in dealii development version (9.1.0-pre, shortrev c6b7876) using gcc/7.2.0 compiler and cuda/9.2

; Best, > Jean-Paul > > On 18 Sep 2018, at 18:47, Sambit Das > > wrote: > > Hi Bruno, > > Thank you for your reply. Now I tried CMake 3.9.6 but got the following > compilation error > > [ 54%] Building CUDA object > source/base/CMakeFiles/obj_base_debug.dir/cud

[deal.II] Re: Compilation error in dealii development version (9.1.0-pre, shortrev c6b7876) using gcc/7.2.0 compiler and cuda/9.2

AM UTC-5, Bruno Turcksin wrote: > > Sambit, > > Can you try with a different version of CMake. We do not support CMake > 3.12 with CUDA at the moment. > > Best, > > Bruno > > On Monday, September 17, 2018 at 8:56:31 PM UTC-4, Sambit Das wrote: >> &g

[deal.II] Compilation error in dealii development version (9.1.0-pre, shortrev c6b7876) using gcc/7.2.0 compiler and cuda/9.2

Dear all, I am trying to compile the latest development version of dealii (9.1.0-pre, shortrev c6b7876) using gcc/7.2.0, openmpi/3.0.0/gcc/7.2.0, cuda/9.2 and cmake-3.12.2. During compilation I get the following error: [ 57%] Building CUDA object

[deal.II] Re: Compilation error in dealii development version (version 9.1.0-pre, shortrev 7537ea7) using intel/18.0.2 compiler

Dr. Arndt, Thank you for creating the patch. I am now able to compile and install the patched branch with intel/18.0.2 compiler. Best, Sambit On Friday, August 31, 2018 at 4:41:16 AM UTC-5, Daniel Arndt wrote: > > Sambit, > > Thanks for reporting! > Can you try if

[deal.II] Compilation error in dealii development version (version 9.1.0-pre, shortrev 7537ea7) using intel/18.0.2 compiler

Dear all, I am trying to compile the latest development version of dealii (version 9.1.0-pre, shortrev 7537ea7) using intel/18.0.2, intelmpi and cmake/3.10.2. During compilation I get the following error:

Re: [deal.II] Question on resolving chains of constraints containing both periodic and hanging node constraints

, 2018 at 12:01:07 AM UTC+2, Sambit Das wrote: >> >> Dear Prof. Bangerth, >> >> I have now reproduced the above issue in the attached minimal example. >> >> Below is the algorithm of the minimal example >> >> 1) Create a hypercube (-20,20) with

Re: [deal.II] Question on resolving chains of constraints containing both periodic and hanging node constraints

Thank you, Sambit On Friday, August 10, 2018 at 9:39:58 AM UTC-5, Sambit Das wrote: > > Dear Prof. Bangerth, > > Yes, they should really be the same. Or, more correctly, if two processors >> both store the constraints for a node, they better be the same. On the >> o

Re: [deal.II] Question on resolving chains of constraints containing both periodic and hanging node constraints

Dear Prof. Bangerth, Yes, they should really be the same. Or, more correctly, if two processors > both store the constraints for a node, they better be the same. On the > other > hand, of course not every processor will know every constraint. > Thanks you for clarifying this. Can you try

[deal.II] Question on resolving chains of constraints containing both periodic and hanging node constraints

Hi All, I have a question about resolving chains of constraints in a ConstraintMatrix class object after calling close() in a parallel distributed case: I created a ConstraintMatrix with both periodic and hanging node constraints, and called close(). Then I picked a constrained degree of

[deal.II] Re: multiply constrained dofs (hanging nodes+periodic) fails a simple test case

UTC-5, Sambit Das wrote: > > >>> true, but I don't see why you would have the same norms if you >> distribute with constraints from hanging nodes only or constraints from >> hanging nodes+ PBC. >> I think we can agree that the two ConstraintMatrix objects shoul

[deal.II] Re: multiply constrained dofs (hanging nodes+periodic) fails a simple test case

Hi Denis, > I don't think that's the case. The domain is indeed periodic, but this is > completely detached from location of support/nodal points. > Same applies to geometry, you will have different coordinates of vertices > across the PBC so > > I agree, the location of nodal points is

[deal.II] Re: Error in writing and reading cell based data for restart

> > > *An error occurred in line <3236> of file > > > in function* > *void dealii::parallel::distributed::Triangulation spacedim>::notify_ready_to_unpack(unsigned int, const std::function (const dealii::Triangulation::cell_iterator &, > dealii::Triangulation

[deal.II] Error in writing and reading cell based data for restart

Hi all, I have written the following failing minimal example (also attached) where I create a single element parallel distributed triangulation and try to write and read a double. *using namespace dealii;* *int main (int argc, char *argv[])* *{* * Utilities::MPI::MPI_InitFinalize

Re: [deal.II] TBB error inside FESystem constructor when using development version dealii (dealii-8.5.1 works fine) in debug mode

nesday, March 21, 2018 at 2:44:54 PM UTC-5, Sambit Das wrote: > > Hi Matthias, > > Thanks for your reply. > >> >> >> Out of curiosity, can you please attach the detailed.log file so that we >> can have a look at the full link interface? :-) I am curious wh

[deal.II] Re: Hanging node constraints and periodic constraints together causing an issue

e > for you. > > Best, > Daniel > > > Am Dienstag, 16. Januar 2018 22:06:55 UTC+1 schrieb Sambit Das: >> >> Thank you, Dr. Arndt. >> >> Best, >> Sambit >> >> On Tuesday, January 16, 2018 at 11:16:08 AM UTC-6, Daniel Arndt wrote: >

[deal.II] Re: Hanging node constraints and periodic constraints together causing an issue

Thank you, Dr. Arndt. Best, Sambit On Tuesday, January 16, 2018 at 11:16:08 AM UTC-6, Daniel Arndt wrote: > > Sambit, > > I created an issue at https://github.com/dealii/dealii/issues/5741 with a > modified version of your example. > > Best, > Daniel > -- The deal.II project is located at

[deal.II] Hanging node constraints and periodic constraints together causing an issue

Hello, I am facing an issue when I use hanging nodes with periodic boundary conditions. I have reproduced the error in the attached minimal example where I do the following steps: 1) Create a hypercube 2) Set appropriate boundary_ids on the faces of the hypercube for periodic boundary

Re: [deal.II] Re: Strange error in 9.0.0-pre version: the size of two component support points is not twice the single component support points

Hello Prof. Bangerth, Thank you for your reply. I have trimmed the minimal example to just reproduce the error in the debug mode and created a github issue. Thanks, Sambit On Sunday, December 17, 2017 at 4:02:21 PM UTC-6, Wolfgang Bangerth wrote: > > On 12/16/2017 06:40 PM, Sambit Das

[deal.II] Re: Moving vertices of parallel triangulation breaks periodic face pair match

Thanks a lot for providing the patch, Dr. Arndt. > Still, the check for orthogonal_equality doesn't need to suceed even if > the vertices were moved correctly. We are only updating vertices active > cells while the PeriodicFacePairs > store CellIterators for the coarsest level. Not all of the

Re: [deal.II] Re: DoFTools::make_hanging_node_constraints affecting DoFTools::make_periodicity_constraints for a single element triangulation with no hanging nodes

Dear Dr. Arndt, It seems I was accidentally running the minimal example in the non debug mode. After running in debug mode, I am indeed getting the error message. > An error occurred in line <1510> of file > <../include/deal.II/lac/constraint_matrix.h> in function > void

[deal.II] DoFTools::make_hanging_node_constraints affecting DoFTools::make_periodicity_constraints for a single element triangulation with no hanging nodes

Hi All, I am facing the following issue: I am setting periodic boundary conditions in all directions on a dofHandler object attached to a single element triangulation. When I print the ConstraintMatrix I observe that a trivial call to DoFTools::make_hanging_node_constraints(..) which I call

[deal.II] Re: Moving vertices of parallel triangulation breaks periodic face pair match

Dear Dr. Arndt, I am using the GridTools::collect_periodic_faces(..) as a sanity check after moving the triangulation. I donot again set periodicity constraints. The documentation also mentions "it is possible to call this function several times with different boundary ids to generate a vector

[deal.II] Re: Moving vertices of parallel triangulation breaks periodic face pair match

The approach which i discussed in the last post worked on 2 processors but didn't work for 16 processors- periodic face pair match failed, but I am no longer getting segfaults. I think the ghost values are still not being set correctly. The parallel distributed diplacement vector constructor

[deal.II] Re: Moving vertices of parallel triangulation breaks periodic face pair match

ange, const IndexSet <https://www.dealii.org/8.4.0/doxygen/deal.II/classIndexSet.html> & ghost_indices, const MPI_Comm communicator ) I no longer use triangulation.communicate_locally_moved_vertices(..). Best, Sambit On Monday, December 4, 2017 at 5:46:23 PM UTC-5, Sambit Das wrote: > >

[deal.II] Re: Moving vertices of parallel triangulation breaks periodic face pair match

thing wierd (Dont exactly remember what, Code was not doing > what I was expecting) happened with me. But Since then, I have avoided > using it. > > > > Thanks. > > On Monday, December 4, 2017 at 1:22:37 PM UTC-5, Sambit Das wrote: >> >> Hello Dr. Arndt, >>

[deal.II] Re: Moving vertices of parallel triangulation breaks periodic face pair match

Hello Dr. Arndt, Thank you for your reply. My apologies for not being clear on the " breaks the periodic face pairs match". Following is the error message I get when I run on parallel. *An error occurred in line <3699> of file in function* *void

[deal.II] Moving vertices of parallel triangulation breaks periodic face pair match

I forgot to add that this works on serial but fails for multiple processors -- 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

[deal.II] Moving vertices of parallel triangulation breaks periodic face pair match

Hi All, I am trying to move all parallel triangulation nodes by a constant displacement, but that breaks the periodic face pairs match when I call GridTools::collect_periodic_faces(...). I use the following code for the mesh movement. The dftPtr->triangulation has periodicity constraints

Re: [deal.II] Wrong result in use of FEEvaluation with different ConstraintMatrix objects

Dear Martin, Thank you for your quick reply. I understand my mistake now- the issue stems from "matrix_free_data.initialize_dof_vector(VECTOR_NAME, 1);" in the second case. I have used matrix_free_data.initialize_dof_vector(VECTOR_NAME, 0) in both cases which causes a mismatch with the

[deal.II] Re: Wrong result in use of FEEvaluation with different ConstraintMatrix objects

Just to clarify my observations on serial and parallel discrepancy- The value from case 1 remains same for serial and parallel, while case 2 gives different values for serial and parallel. On Friday, December 1, 2017 at 3:39:20 PM UTC-6, Sambit Das wrote: > > Hi All, > > I have re

[deal.II] Wrong result in use of FEEvaluation with different ConstraintMatrix objects

Hi All, I have reduced my bug to the following minimal example: I create a MatrixFree object for two different ConstraintMatrices (provided as vector of ConstraintMatrices to the reinit(..)). matrix_free_data.reinit(dofHandlerVector, d_constraintsVector, quadratureVector,