[deal.II] Re: Installation error, unable to configure with p4est

2019-10-05 Thread vachan potluri 

>
> Yes, you can likely ignore the error. If you really want to run this 
> quicktest, you can change
> make_quicktest("p4est" ${_mybuild} 10)
> to
> make_quicktest("p4est" ${_mybuild} 4)
> in tests/quick_tests/CMakeLists.txt.


This works. 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/f352cf6d-7f40-457d-9e5a-8ce9e5a5ef1f%40googlegroups.com.

Re: [deal.II] Merging meshes and empty triangulation

2019-10-05 Thread Daniel Arndt 
Erik,

Can you share your code and your mesh with us?

Best,
Daniel

Am Sa., 5. Okt. 2019 um 20:30 Uhr schrieb Erik Fujiyama <
erikfujiy...@gmail.com>:

> Hello, I think I'm having a similar problem to the OP. I searched a lot,
> but that's the closest that I could find. I'm trying to work with some
> meshes from gmsh, so I used the gridin functions to read them.
>
>   Triangulation triangulation;
>   GridIn gridin;
>   gridin.attach_triangulation(triangulation);
>   std::ifstream f("plate4");
>   gridin.read_msh(f);
>
> The mesh was generated with the physical lines and physical surfaces as
> mentioned in step 49.
>
> I even tested if it was actually reading by printing the number of active
> elements, and it is.
>
> However, when I'm going to distribute the dofs, it gives this message
>
> An error occurred in line <999> of file
>  in function
> void dealii::DoFHandler::distribute_dofs(const
> dealii::FiniteElement&) [with int dim = 2; int spacedim = 2]
> The violated condition was:
> tria->n_levels() > 0
> Additional information:
> The Triangulation you are using is empty!
>
>
> There's some problem that for some reason the information is lost in the
> next function when I call
>
>   dof_handler.distribute_dofs (fe);
>
> I double checked, and the DoF_handler is already associated with the
> triangulation
>
> fe (FE_Q(order), dim),
>   dof_handler (triangulation),
>
> It is specially confusing to me, because if I generate a grid with the
> grid generator, it works perfectly fine.
>
> Respectfully
> E.
>
> Em sábado, 31 de agosto de 2013 07:16:10 UTC-3, Wolfgang Bangerth escreveu:
>>
>>
>> > void CellProb::make_grid ()
>> > {
>> >   Triangulation<2> tria1;
>> >   GridGenerator::hyper_cube_with_cylindrical_hole (tria1, 0.25, 1.0);
>> >
>> >  Triangulation<2> tria3;
>> >   GridGenerator::hyper_cube_with_cylindrical_hole (tria3, 0.25, 1.0);
>> >GridTools::shift (Point<2>(0,-2), tria3);
>> >   Triangulation<2> triangulation2;
>> >   GridGenerator::merge_triangulations (tria1, tria3, triangulation2);
>> >
>> >   mesh_info(triangulation2, "grid-2.eps");
>> >   std::cout << "Number of active cells: "
>> >  << triangulation.n_active_cells()
>> >  << std::endl;
>> >  std::cout << "Total number of cells: "
>> >  << triangulation.n_cells()
>> >  << std::endl;
>> >
>> > }
>> > but I get the following report:
>> >  Remaking Makefile.dep
>> > ==debug= cell.cc  ->  cell.g.o
>> >  Linking cell
>> >  Running cell
>> > terminate called after throwing an instance of
>> > 'dealii::internal::Triangulation::ExcGridHasInvalidCell'
>> >what():  
>> > An error occurred in line <1672> of file
>> >  in
>> function
>> >  static void
>> >
>> dealii::internal::Triangulation::Implementation::create_triangulation(const
>> > std::vector,
>> > std::allocator>> &, const
>> > std::vector, std::allocator>>
>> &, const
>> > dealii::SubCellData &, dealii::Triangulation<2, spacedim> &) [with
>> spacedim = 2]
>> > The violated condition was:
>> >  needed_lines.find(std::make_pair(line_vertices.second,
>> > line_vertices.first)) == needed_lines.end()
>> > The name and call sequence of the exception was:
>> >  ExcGridHasInvalidCell(cell)
>> > Additional Information:
>> > Something went wrong when making cell 9. Read the docs and the source
>> code for
>> > more information.
>> > 
>>
>> I can reproduce this. Can you please open a bug report with the issue
>> tracker,
>> including your small testcase that shows the problem?
>>
>>
>> > My second question:
>> > I tried grid_2 (from tutorial 49) with the simple version of Poisson's
>> > equation and I get the following:
>> >  Remaking Makefile.dep
>> > ==debug= cell.cc  ->  cell.g.o
>> >  Linking cell
>> >  Running cell
>> > Mesh info:
>> >   dimension: 2
>> >   no. of cells: 224
>> >   boundary indicators: 0(88 times)
>> >   written to grid-2.eps
>> > Number of active cells: 224
>> > Total number of cells: 294
>> > 
>> > An error occurred in line <230> of file
>> >
>> 
>>
>> > in function
>> >  static unsigned int
>> >
>> dealii::internal::DoFHandler::Policy::Implementation::distribute_dofs(unsigned
>>
>> > int, unsigned int, dealii::DoFHandler &) [with dim = 2,
>> > spacedim = 2]
>> > The violated condition was:
>> >  tria.n_levels() > 0
>> > The name and call sequence of the exception was:
>> >  ExcMessage("Empty triangulation")
>> > Additional Information:
>> > Empty triangulation
>> > Stacktrace:
>> > ---
>> > #0  /usr/local_rwth/sw/deal.II/deal.II-7.3.0/lib/libdeal_II.g.so.7.3.0:
>> > unsigned int
>> >
>> dealii::i

Re: [deal.II] installation fails with intel/19.0.5

2019-10-05 Thread Timo Heister 
Victor,

this might a bit too specific for the mailing list, but I detail my
installation steps for deal.II+ASPECT on Frontera here:
https://github.com/geodynamics/aspect/wiki/Installation-on-Frontera
(Trilinos and p4est, I don't need PETSc right now)

On Sat, Oct 5, 2019 at 7:09 PM Victor Eijkhout  wrote:
>
>
>
> On Oct 5, 2019, at 4:13 PM, Timo Heister  wrote:
>
> -D DEAL_II_WITH_MPI=ON \
> -D DEAL_II_CXX_FLAGS="-march=native" \
> -D DEAL_II_WITH_CXX17=OFF \
> -D DEAL_II_WITH_64BIT_INDICES=ON \
> -D DEAL_II_COMPONENT_EXAMPLES=OFF \
> -D CMAKE_INSTALL_PREFIX=`pwd`/install  \
> ../../deal-git
>
>
> So this is a build without petsc, trilinos, and what not?
>
> Victor.
>
> --
> 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/17802784-5ECC-4FF6-97BE-7232DCA4AAAF%40tacc.utexas.edu.



-- 
Timo Heister
http://www.math.clemson.edu/~heister/

-- 
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/CAMRj59F7afCbsSmZY8jdZa8yNO54YYfrc0StKjxXSNpNu7W6Jg%40mail.gmail.com.

Re: [deal.II] Merging meshes and empty triangulation

2019-10-05 Thread Erik Fujiyama 
Hello, I think I'm having a similar problem to the OP. I searched a lot, 
but that's the closest that I could find. I'm trying to work with some 
meshes from gmsh, so I used the gridin functions to read them. 

  Triangulation triangulation;
  GridIn gridin;
  gridin.attach_triangulation(triangulation);
  std::ifstream f("plate4");
  gridin.read_msh(f);

The mesh was generated with the physical lines and physical surfaces as 
mentioned in step 49.

I even tested if it was actually reading by printing the number of active 
elements, and it is.

However, when I'm going to distribute the dofs, it gives this message

An error occurred in line <999> of file 
 in function
void dealii::DoFHandler::distribute_dofs(const 
dealii::FiniteElement&) [with int dim = 2; int spacedim = 2]
The violated condition was: 
tria->n_levels() > 0
Additional information: 
The Triangulation you are using is empty!


There's some problem that for some reason the information is lost in the 
next function when I call

  dof_handler.distribute_dofs (fe);

I double checked, and the DoF_handler is already associated with the 
triangulation

fe (FE_Q(order), dim),
  dof_handler (triangulation),

It is specially confusing to me, because if I generate a grid with the grid 
generator, it works perfectly fine. 

Respectfully
E.

Em sábado, 31 de agosto de 2013 07:16:10 UTC-3, Wolfgang Bangerth escreveu:
>
>
> > void CellProb::make_grid () 
> > { 
> >   Triangulation<2> tria1; 
> >   GridGenerator::hyper_cube_with_cylindrical_hole (tria1, 0.25, 1.0); 
> > 
> >  Triangulation<2> tria3; 
> >   GridGenerator::hyper_cube_with_cylindrical_hole (tria3, 0.25, 1.0); 
> >GridTools::shift (Point<2>(0,-2), tria3); 
> >   Triangulation<2> triangulation2; 
> >   GridGenerator::merge_triangulations (tria1, tria3, triangulation2); 
> > 
> >   mesh_info(triangulation2, "grid-2.eps"); 
> >   std::cout << "Number of active cells: " 
> >  << triangulation.n_active_cells() 
> >  << std::endl; 
> >  std::cout << "Total number of cells: " 
> >  << triangulation.n_cells() 
> >  << std::endl; 
> > 
> > } 
> > but I get the following report: 
> >  Remaking Makefile.dep 
> > ==debug= cell.cc  ->  cell.g.o 
> >  Linking cell 
> >  Running cell 
> > terminate called after throwing an instance of 
> > 'dealii::internal::Triangulation::ExcGridHasInvalidCell' 
> >what():   
> > An error occurred in line <1672> of file 
> >  in 
> function 
> >  static void 
> > 
> dealii::internal::Triangulation::Implementation::create_triangulation(const 
> > std::vector, 
> > std::allocator>> &, const 
> > std::vector, std::allocator>> &, 
> const 
> > dealii::SubCellData &, dealii::Triangulation<2, spacedim> &) [with 
> spacedim = 2] 
> > The violated condition was: 
> >  needed_lines.find(std::make_pair(line_vertices.second, 
> > line_vertices.first)) == needed_lines.end() 
> > The name and call sequence of the exception was: 
> >  ExcGridHasInvalidCell(cell) 
> > Additional Information: 
> > Something went wrong when making cell 9. Read the docs and the source 
> code for 
> > more information. 
> >  
>
> I can reproduce this. Can you please open a bug report with the issue 
> tracker, 
> including your small testcase that shows the problem? 
>
>
> > My second question: 
> > I tried grid_2 (from tutorial 49) with the simple version of Poisson's 
> > equation and I get the following: 
> >  Remaking Makefile.dep 
> > ==debug= cell.cc  ->  cell.g.o 
> >  Linking cell 
> >  Running cell 
> > Mesh info: 
> >   dimension: 2 
> >   no. of cells: 224 
> >   boundary indicators: 0(88 times) 
> >   written to grid-2.eps 
> > Number of active cells: 224 
> > Total number of cells: 294 
> >  
> > An error occurred in line <230> of file 
> > 
>  
>
> > in function 
> >  static unsigned int 
> > 
> dealii::internal::DoFHandler::Policy::Implementation::distribute_dofs(unsigned
>  
>
> > int, unsigned int, dealii::DoFHandler &) [with dim = 2, 
> > spacedim = 2] 
> > The violated condition was: 
> >  tria.n_levels() > 0 
> > The name and call sequence of the exception was: 
> >  ExcMessage("Empty triangulation") 
> > Additional Information: 
> > Empty triangulation 
> > Stacktrace: 
> > --- 
> > #0  /usr/local_rwth/sw/deal.II/deal.II-7.3.0/lib/libdeal_II.g.so.7.3.0: 
> > unsigned int 
> > dealii::internal::DoFHandler::Policy::Implementation::distribute_dofs<2, 
> > 2>(unsigned int, unsigned int, dealii::DoFHandler<2, 2>&) 
> > #1  /usr/local_rwth/sw/deal.II/deal.II-7.3.0/lib/libdeal_II.g.so.7.3.0: 
> > dealii::internal::

Re: [deal.II] installation fails with intel/19.0.5

2019-10-05 Thread Victor Eijkhout 


On Oct 5, 2019, at 4:13 PM, Timo Heister 
mailto:timo.heis...@gmail.com>> wrote:

-D DEAL_II_WITH_MPI=ON \
-D DEAL_II_CXX_FLAGS="-march=native" \
-D DEAL_II_WITH_CXX17=OFF \
-D DEAL_II_WITH_64BIT_INDICES=ON \
-D DEAL_II_COMPONENT_EXAMPLES=OFF \
-D CMAKE_INSTALL_PREFIX=`pwd`/install  \
../../deal-git

So this is a build without petsc, trilinos, and what not?

Victor.

-- 
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/17802784-5ECC-4FF6-97BE-7232DCA4AAAF%40tacc.utexas.edu.

Re: [deal.II] installation fails with intel/19.0.5

2019-10-05 Thread Timo Heister 
CC=mpicc CXX=mpicxx cmake \
 -D DEAL_II_WITH_MPI=ON \
 -D DEAL_II_CXX_FLAGS="-march=native" \
 -D DEAL_II_WITH_CXX17=OFF \
 -D DEAL_II_WITH_64BIT_INDICES=ON \
 -D DEAL_II_COMPONENT_EXAMPLES=OFF \
 -D CMAKE_INSTALL_PREFIX=`pwd`/install  \
 ../../deal-git

This is with Intel 19.0.5 and intel MPI. You can also run without
64bit indices, but I need it to be able to do large runs with more
than 4 billion DoFs.

On Sat, Oct 5, 2019 at 11:10 AM Victor Eijkhout
 wrote:
>
>
>
> On Oct 5, 2019, at 9:27 AM, Timo Heister  wrote:
>
> Otherwise I have no
> problem running with 19.0.5 on Frontera.
>
>
> Dictate me you cmake line?
>
> Victor.
>
> --
> 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/CA0DCDFA-0246-4300-9C44-1355958D61F2%40tacc.utexas.edu.

-- 
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/CAMRj59GKF%2BP-ijjTczf-r_jk3WCKQd%3DkDiLzDBzd%3DEVurGWq7Q%40mail.gmail.com.

Re: [deal.II] Error during refinement of a parallel distibuted quarter hyperball

2019-10-05 Thread Daniel Arndt 
Stefan,

I am getting

Abort: Expected '(int) edge_trees - (int) ta->elem_count':
'p8est_find_edge_transform_internal (conn, itree, iedge, ei,
conn->edge_to_tree + ettae, conn->edge_to_edge + ettae, edge_trees)'
Abort: /home/darndt/Sources/p4est-2.2/src/p8est_connectivity.c:
Abort
[lap115343:18334] *** Process received signal ***
[lap115343:18334] Signal: Aborted (6)
[lap115343:18334] Signal code:  (-6)
[lap115343:18334] [ 0]
/lib/x86_64-linux-gnu/libc.so.6(+0x3ef20)[0x7ff7d31b2f20]
[lap115343:18334] [ 1]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xc7)[0x7ff7d31b2e97]
[lap115343:18334] [ 2]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x141)[0x7ff7d31b4801]
[lap115343:18334] [ 3] /home/darndt/p4est-2.2/DEBUG/lib/libsc-2.2.so
(sc_abort_verbose+0x0)[0x7ff7da6a1070]
[lap115343:18334] [ 4] /home/darndt/p4est-2.2/DEBUG/lib/libsc-2.2.so
(sc_abort+0xd)[0x7ff7da6a0e5b]
[lap115343:18334] [ 5] /home/darndt/p4est-2.2/DEBUG/lib/libsc-2.2.so
(sc_abort_verbosef+0x0)[0x7ff7da6a1104]
[lap115343:18334] [ 6] /home/darndt/p4est-2.2/DEBUG/lib/libp4est-2.2.so
(p8est_find_edge_transform+0x1f4)[0x7ff7da9604b9]
[lap115343:18334] [ 7] /home/darndt/p4est-2.2/DEBUG/lib/libp4est-2.2.so
(p8est_connectivity_is_valid+0x6a0)[0x7ff7da9547ed]
[lap115343:18334] [ 8]
/home/darndt/dealii/build/lib/libdeal_II.g.so.9.2.0-pre(_ZN6dealii8parallel11distributed13TriangulationILi3ELi3EE31copy_new_triangulation_to_p4estESt17integral_constantIiLi3EE+0x3db)[0x7ff7e57cf53b]
[lap115343:18334] [ 9]
/home/darndt/dealii/build/lib/libdeal_II.g.so.9.2.0-pre(_ZN6dealii8parallel11distributed13TriangulationILi3ELi3EE20create_triangulationERKSt6vectorINS_5PointILi3EdEESaIS6_EERKS4_INS_8CellDataILi3EEESaISC_EERKNS_11SubCellDataE+0x27)[0x7ff7e57edad7]
[lap115343:18334] [10]
/home/darndt/dealii/build/lib/libdeal_II.g.so.9.2.0-pre(_ZN6dealii13GridGenerator18quarter_hyper_ballILi3EEEvRNS_13TriangulationIXT_EXT_EEERKNS_5PointIXT_EdEEd+0x647)[0x7ff7e4e20f47]
[lap115343:18334] [11] ./mwe(main+0x6c)[0x406ecc]
[lap115343:18334] [12]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7ff7d3195b97]
[lap115343:18334] [13] ./mwe(_start+0x2a)[0x406d9a]
[lap115343:18334] *** End of error message ***

when running your code. This might be related to
https://github.com/dealii/dealii/issues/7428. Would you mind opening an
issue for this at https://github.com/dealii/dealii/issues?

Best,
Daniel

Am Fr., 4. Okt. 2019 um 13:12 Uhr schrieb Stefan Käßmair <
stefan.kaessm...@gmail.com>:

> Dear all,
>
> during the refinement of a quarter hyper ball in 3D in debug mode, I
> receive the following error when running on a single core (mpirun -np 1):
>
>
>
>
> *An error occurred in line <2764> of file
>  in functionvoid
> dealii::parallel::distributed::Triangulation spacedim>::copy_local_forest_to_triangulation() [with int dim = 3; int
> spacedim = 3]The violated condition was: static_cast int>(parallel_forest->local_num_quadrants) == total_local_cells*
>
> When running on multiple cores I hit another error message (probably
> because there are no ghosts when using only one core):
>
>
>
>
> *An error occurred in line <2670> of file
>  in functionvoid
> dealii::parallel::distributed::Triangulation spacedim>::copy_local_forest_to_triangulation() [with int dim = 3; int
> spacedim = 3]The violated condition was: num_ghosts ==
> parallel_ghost->ghosts.elem_cou*nt
>
> Currently I am using deal.II 9.0.1.
> This is the relevant part of the code (a full MWE is attached):
>
> const unsigned int dim = 3;
>
> parallel::distributed::Triangulation tria (
>   mpi_communicator,
>   typename
> Triangulation::MeshSmoothing(Triangulation::smoothing_on_refinement),
>
> parallel::distributed::Triangulation::default_setting);
>
> GridGenerator::quarter_hyper_ball(tria);
>
> for (unsigned int i_refinement = 0; i_refinement < 6;
> ++i_refinement)
> {
> auto cell = tria.begin_active();
> auto endc = tria.end();
>
> for (; cell!=endc; ++cell)
> if(cell->is_locally_owned() && cell->at_boundary())
> cell->set_refine_flag ();
>
> tria.prepare_coarsening_and_refinement ();
> tria.execute_coarsening_and_refinement ();
> }
>
> Is there something wrong with my code? Or maybe with my installation (can
> anyone confirm the error)?
> The code works in 2D but crashes in 3D. When the number of refinement
> cycles is reduced to 4 instead of 6, it also works.
> Out of curiosity, I've tried using GridGenerator::hyper_cube instead of
> the hyper_ball, there the code works just fine in 2D and 3D.
>
> I would really appreciate if anyone can help me with this.
>
> Kind regards,
> Stefan
>
> --
> 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 Us

Re: [deal.II] Re: Installation error, unable to configure with p4est

2019-10-05 Thread Daniel Arndt 
Vachan,

[...]
> However,
> make test
> for p4est failed with the following message
> There are not enough slots available in the system to satisfy the 10 slots
> that were requested by the application:
>   ./p4est.debug
>
> Either request fewer slots for your application, or make more slots
> available
> for use.
> It is true that my PC has only 4 slots (8 with hyper threading). So can I
> ignore this error?
>

Yes, you can likely ignore the error. If you really want to run this
quicktest, you can change
make_quicktest("p4est" ${_mybuild} 10)
to
make_quicktest("p4est" ${_mybuild} 4)
in tests/quick_tests/CMakeLists.txt.

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/CAOYDWbKQ%3DEJNnHEH8jg_bU9TWLR%3DPU2kJo5CsmJN9G%3DDRj%2BQVg%40mail.gmail.com.

Re: [deal.II] Re: Move vertices in P::D::Triangulation

2019-10-05 Thread Daniel Arndt 
huyanzhou,

in the documentation , it's said in the case of mesh with moved vertices is
> refined a few step later, should do as follows:
> 1. save the offset applied to every vertex,
> 2. call communicate_locally_moved_vertices function
> 3. apply the opposite offset
> 4. call communicate_local refining or coarsening the meshly_moved_vertices
> function
> 5.  refining or coarsening the mesh
>
> i don't quite understand the 5 step.
> 1. what's the meaning of offset here? is it the move vector for every
> vectices in this step, or the whole move vector which will make the mesh
> return to original mesh?
>

The offset is the total move vector that will make the mesh return to its
original state. Only the mesh without any displacements has valid positions
for all the cells (including artificial ones).

2. we add the opposite offset , does this means we need apply the offset
> again after  refining or coarsening ?
>

Yes. The offset vector should be transferred to the new mesh via
SolutionTransfer. Then you can apply it again.

An alternative to moving the vertices is using MappingFEField or
MappingQEulerian.

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/CAOYDWbKVHdywuJOfhCKjHP3Tib8%3DX-tdgvCxt-75Q5UX0psXsQ%40mail.gmail.com.

[deal.II] Re: Move vertices in P::D::Triangulation

2019-10-05 Thread huyanzhuo 
hello!

in the documentation , it's said in the case of mesh with moved vertices is 
refined a few step later, should do as follows:
1. save the offset applied to every vertex,
2. call communicate_locally_moved_vertices function
3. apply the opposite offset
4. call communicate_local refining or coarsening the meshly_moved_vertices 
function
5.  refining or coarsening the mesh

i don't quite understand the 5 step. 
1. what's the meaning of offset here? is it the move vector for every 
vectices in this step, or the whole move vector which will make the mesh 
return to original mesh?
2. we add the opposite offset , does this means we need apply the offset 
again after  refining or coarsening ?
在 2016年11月17日星期四 UTC+8下午8:15:24，Daniel Arndt写道：
>
> Rajat,
>
> 1. After the p:d:triangulation is created and 
>> triangulation.global_refine(2) is used, the locally owned cells on each 
>> mesh will divide in 2^dim elements each but does that also mean that the 
>> ghost cells or artificial cells on each processor also gets  refined ?
>>
> All ghost cells look the same as on the owning processor while this is not 
> true for artificial cells. When the mesh is refined a new partitioning 
> between processors is used. Therefore, ghost cells and artificial are not 
> really refined but set accordingly after the mesh is refined.
>  
>
>> 2. To move the ghost cells on the domain as well, is it just sufficient 
>>> to replace the* if condition* above  with
>>
>> if (cell->is_locally_owned())  => if (cell->is_ghost())   ?
>> and the displacement is a ghosted vector.
>>
> You don't need to do this yourself. If you are using a 
> parallel::distributed Triangulation and move vertices that are in someone's 
> ghost layer, you should call 
> Triangulation::communicate_locally_moved_vertices [1] to have a consistent 
> mesh. You need to be careful if you want to refine the mesh
> after you have moved vertices as noted in the documentary of that function.
>
> Best,
> Daniel
>
> [1] 
> https://www.dealii.org/8.4.1/doxygen/deal.II/classparallel_1_1distributed_1_1Triangulation.html#a247598f1323a9f847832e60d6c840469
>  
>

-- 
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/f84f4519-e336-4632-a6fc-1ce94501e428%40googlegroups.com.

Re: [deal.II] some question about the move mesh function

2019-10-05 Thread Daniel Arndt 
huyanzhou,

I try to use the communicate_locally_moved_vertices, it fixes the departure
> of mesh belongs to different mesh . but there still remains some problem
>
[...]
> you can see that the mesh is consistent on the boundry, but not smooth in
> the inner mesh ,there are some shallow hole  on the surface
>
Can you explain more precisely what doesn't work as expected? Is this a
problem you only see when running with multiple MPI processes?
What is the "inner mesh" for you? Do you refer to faces with children? Can
you point out which vertices you think are set wrongly?


> my code is as follows
>
[...]
>

It seems that your idea is to first move vertices according to some
displacement function and then to "correct" hanging vertices to be placed
inside the neighboring face.
That looks OK for standard orientation but might be problematic otherwise.
You should be able to achieve the same effect when you only apply hanging
node constraints to your
displacement vector.

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/CAOYDWbJA%2BTTTMhPrFg6pomh9KS1rF85mbuHa-9GK%2B%3Dkpr8hOew%40mail.gmail.com.

Re: [deal.II] installation fails with intel/19.0.5

2019-10-05 Thread Victor Eijkhout 


On Oct 5, 2019, at 9:27 AM, Timo Heister 
mailto:heis...@clemson.edu>> wrote:

Otherwise I have no
problem running with 19.0.5 on Frontera.

Dictate me you cmake line?

Victor.

-- 
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/CA0DCDFA-0246-4300-9C44-1355958D61F2%40tacc.utexas.edu.

Re: [deal.II] installation fails with intel/19.0.5

2019-10-05 Thread Timo Heister 
Victor,

see https://github.com/dealii/dealii/issues/8755 that details that you
need to disable CXX17 with Intel 19.0.5 for now. Otherwise I have no
problem running with 19.0.5 on Frontera.

On Tue, Oct 1, 2019 at 1:13 AM Daniel Arndt  wrote:
>
> Victor,
>
>
>> But I’m still not finishing the cmake.
>>
>> So there is a ton of
>> ...
>> What do those mean? Are they fatal or is that only cmake discovering what’s 
>> available and what not?
>
>
> No, these are not fatal. We just check for the dependencies to enable.
> Again, what is the full output when running CMake? Does it create a Makefile 
> you can run via 'make'?
>
> 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/CAOYDWbJdQ8%2BEbCREUCJ8VXgCoZP3qYatkvg%3DQ%2BT5PU%3DufwYufg%40mail.gmail.com.



-- 
Timo Heister
http://www.math.clemson.edu/~heister/

-- 
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/CAMRj59Et0bqE-dTDt9%3Dxg3KBhyijzmQhNvTcjz2QBzU1-DjiVw%40mail.gmail.com.

Re: [deal.II] some question about the move mesh function

2019-10-05 Thread huyanzhuo 
thanks very much for your reply!

I try to use the communicate_locally_moved_vertices, it fixes the departure 
of mesh belongs to different mesh . but there still remains some problem 

[image: 789.png]



you can see that the mesh is consistent on the boundry, but not smooth in 
the inner mesh ,there are some shallow hole  on the surface
my code is as follows
template < int dim >
void step::move_mesh(const TrilinosWrappers::MPI::Vector 
&state_change) 
{
  pcout<<"moving the mesh ..." < vertex_touched(triangulation.n_vertices(), false);
  parallel::distributed::Triangulation< dim > 
*distributed_triangulation = &triangulation;

  const std::vector locally_owned_vertices = 
GridTools::get_locally_owned_vertices(triangulation);

  for (typename DoFHandler::active_cell_iterator cell 
=dof_handler.begin_active();cell != dof_handler.end(); ++cell)
if (cell->is_locally_owned())  
 
  for (unsigned int v = 0; v < 
GeometryInfo::vertices_per_cell; ++v) 
{
  if(vertex_touched[cell->vertex_index(v)] == false)
  {
vertex_touched[cell->vertex_index(v)] = true;

Point vertex_displacement;
for (unsigned int d = 0; d < dim; ++d)  
   
  vertex_displacement[d] = 
state_change(cell->vertex_dof_index(v, d));
cell->vertex(v) += vertex_displacement;
  }
}
  
distributed_triangulation->communicate_locally_moved_vertices(locally_owned_vertices);

  typename Triangulation::active_cell_iterator
  cell = triangulation.begin_active(),
  endc = triangulation.end();
  for (; cell!=endc; ++cell)
if (!cell->is_artificial())
  for (unsigned int face=0; face::faces_per_cell; 
++face)
if (cell->face(face)->has_children() && 
!cell->face(face)->at_boundary())
{
  // this face has hanging nodes
  if (dim==2)
cell->face(face)->child(0)->vertex(1) = 
(cell->face(face)->vertex(0) + cell->face(face)->vertex(1)) / 2;
  else if (dim==3)
  {
cell->face(face)->child(0)->vertex(1) = 
.5*(cell->face(face)->vertex(0) +cell->face(face)->vertex(1));
cell->face(face)->child(0)->vertex(2) = 
.5*(cell->face(face)->vertex(0) +cell->face(face)->vertex(2));
cell->face(face)->child(1)->vertex(3) = 
.5*(cell->face(face)->vertex(1) +cell->face(face)->vertex(3));
cell->face(face)->child(2)->vertex(3) = 
.5*(cell->face(face)->vertex(2) +cell->face(face)->vertex(3));
// center of the face
cell->face(face)->child(0)->vertex(3) = 
.25*(cell->face(face)->vertex(0)

 +cell->face(face)->vertex(1)

 +cell->face(face)->vertex(2)

 +cell->face(face)->vertex(3));
  }
}
}

i follow the example in  GridTools::distort_random() 


在 2019年10月5日星期六 UTC+8上午1:07:13，Daniel Arndt写道：
>
> huyanzhou,
>
> you might want to have a look at 
> parallel::distributed::Triangulation::communicate_locally_moved_vertices (
> https://www.dealii.org/current/doxygen/deal.II/classparallel_1_1distributed_1_1Triangulation.html#a247598f1323a9f847832e60d6c840469
> ).
>
> Best,
> Daniel
>
> Am Fr., 4. Okt. 2019 um 12:37 Uhr schrieb huyanzhuo  >:
>
>>
>> Dear All:
>> i use the move_mesh function just like step-42
>> template < int dim >
>> void step::move_mesh(const TrilinosWrappers::MPI::Vector 
>> &state_change) const
>> {
>>   pcout<<"moving the mesh ..." <>   std::vector vertex_touched(triangulation.n_vertices(), false);
>>
>>   for (typename DoFHandler::active_cell_iterator cell 
>> =dof_handler.begin_active();cell != dof_handler.end(); ++cell)
>> if (cell->is_locally_owned())
>>
>>   for (unsigned int v = 0; v < 
>> GeometryInfo::vertices_per_cell; ++v) 
>> {
>>   if(vertex_touched[cell->vertex_index(v)] == false)
>>   {
>> vertex_touched[cell->vertex_index(v)] = true;
>>
>> Point vertex_displacement;
>> for (unsigned int d = 0; d < dim; ++d)
>>  
>>   vertex_displacement[d] = 
>> state_change(cell->vertex_dof_index(v, d));
>> cell->vertex(v) += vertex_displacement;
>>   }
>> }
>> }
>>
>> it works well on my own computer. but when use the mpirun in a server, 
>> the result shows a departure on the boundry of mesh belongs to  different 
>> process
>>
>> [image: 456.png]
>>
>> [image: 123.png]
>> does anyone has the same problem?
>>
>> -- 
>> T