Extra layer around mesh

86 views
Skip to first unread message

Joel Davidsson

unread,
Aug 4, 2016, 9:33:29 AM8/4/16
to deal.II User Group
Dear all,

Is there some way that one can refine the mesh in the following way, see attached file: I looking for a way to increase the size of the grid but keeping the original nodes fixed. If you look in the attached file, you see that an extra "layer" has formed around the original mesh marked in green. In this way, the size of the individual element does not change.

Another way of looking at it. If I specify a volume and a size of the smallest element, can I fill this volume with these elements?

Best,
Joel
refine.pdf

Jean-Paul Pelteret

unread,
Aug 4, 2016, 3:14:18 PM8/4/16
to deal.II User Group
Dear Joel,

The way I interpret what you've written here, you're asking two different questions. In the first statement, it sounds like you have a mesh that you wish to increase the size of at some arbitrary time, and the second you know the final bounds a priori.

Let me start with your second viewpoint, which is easiest. You could use GridGenerator::subdivided_hyper_cube or GridGenerator::subdivided_hyper_rectangle to specify any regular discretisation of a Cartesian-aligned volume. So, yes, given that you know the edge length and the size of the elements, you could compute the necessary number of elements in each dimension. If this doesn't give you the exact dimensions of the green box, then you can just move the vertices around as necessary.

Achieving your goal from the first viewpoint requires more work. To "increase" the size of the grid entails joining triangulations of zero refinement levels (i.e. no mesh refinement). So you would need to first create a coarse grid (1 for the green box (which I interpret as being something that you have initially) and then 4 more that share the edges and another 4 that share its vertices, then join them. Since you have to join equally coarse meshes, all of these meshes probably need to created as "discretised" GridGenerator::subdivided_hyper_rectangles in the first place.

A third option would be to use a hp::DoFHandler and use FE_Nothing elements in the region outside the green box. You could then "grow" the mesh by activating these elements at any time.

I hope that this has been useful to you. Apologies in advance if I don't respond to any further messages - from tomorrow I'll be away from my PC for a while.

Regards,
J-P

Joel Davidsson

unread,
Aug 11, 2016, 11:29:35 AM8/11/16
to deal.II User Group
Thank you for a great answer,

The subdivided grid generator approach worked fine for me. 

I just had a question about the third option. If one used FE_Nothing, what is the boundary that is used when doing calculations? Is it the boundary of the big box or the green box? Is this handle automatically or does one need to mark the green box with boundary indicator for example.

Thanks,
Joel

Bruno Turcksin

unread,
Aug 11, 2016, 12:05:41 PM8/11/16
to deal.II User Group
Joel,


On Thursday, August 11, 2016 at 11:29:35 AM UTC-4, Joel Davidsson wrote:

I just had a question about the third option. If one used FE_Nothing, what is the boundary that is used when doing calculations? Is it the boundary of the big box or the green box? Is this handle automatically or does one need to mark the green box with boundary indicator for example.
It will be the boundary on the big box and you can't use boundary indicator because you are not on the boundary. The boundary is a geometric "quantity", it doesn't care about the type of finite elements you are using. So if you want to use Dirichlet "boundary" condition on the green box, you need to build the ConstraintMatrix yourself.

Best,

Bruno

Joel Davidsson

unread,
Aug 12, 2016, 3:35:23 AM8/12/16
to deal.II User Group
Ok

Thanks,

Joel

Joel Davidsson

unread,
Nov 1, 2016, 3:57:04 AM11/1/16
to deal.II User Group
Dear all,

I have code that runs fine with periodic boundary condition for a GridGenerator::parallelepiped. Also when I change the mesh to a GridGenerator::subdivided_parallelepiped and has only 1 as n_subdivisions, it also works. But when I change it to 2, I get the following error:

An error occurred in line <2686> of file </home/joel/Downloads/dealii-8.2.1/source/grid/grid_tools.cc> in function
    void dealii::GridTools::collect_periodic_faces(const CONTAINER&, dealii::types::boundary_id, dealii::types::boundary_id, int, std::vector<dealii::GridTools::PeriodicFacePair<typename CONTAINER::cell_iterator> >&, const dealii::Tensor<1, CONTAINER:: space_dimension>&, const dealii::FullMatrix<double>&, const std::vector<unsigned int>&) [with CONTAINER = dealii::DoFHandler<3>; dealii::types::boundary_id = unsigned char; typename CONTAINER::cell_iterator = dealii::TriaIterator<dealii::DoFCellAccessor<dealii::DoFHandler<3>, false> >]
The violated condition was: 
    pairs1.size() == pairs2.size()
The name and call sequence of the exception was:
    ExcMessage ("Unmatched faces on periodic boundaries")
Additional Information: 
Unmatched faces on periodic boundaries

How can I fix it?

Best,
Joel

Daniel Arndt

unread,
Nov 1, 2016, 6:44:48 AM11/1/16
to deal.II User Group
Joel,

I have code that runs fine with periodic boundary condition for a GridGenerator::parallelepiped. Also when I change the mesh to a GridGenerator::subdivided_parallelepiped and has only 1 as n_subdivisions, it also works. But when I change it to 2, I get the following error:
[...]
GridTools::collect_periodic_faces[1] tries to match the faces on the boundaries specified by the two boundary_ids on the coarsest level and here finds a face that can't be matched. 
Can you give us a minimal example just creating that mesh and trying to compute periodic boundary conditions?
From just your description, it is hard to say what the problem is, but I would not expect that subdividing should be an issue.

Best,
Daniel

Joel Davidsson

unread,
Nov 1, 2016, 10:06:23 AM11/1/16
to deal.II User Group
Dear Daniel,

Here is the small example you asked for. If you run it as it is, it will work. If you can 1 to 2 in line 107, it crashes. Im run dealii-8.2.1, if that is needed.

Best,
Joel
test.cc

Daniel Arndt

unread,
Nov 1, 2016, 12:25:44 PM11/1/16
to deal.II User Group
Joel,

I don't get any errors running a recent developer version. Try to replace the deprecated version of DoFTools::make_periodicity_constraints!
Exemplarily, this would be 

  std::vector<GridTools::PeriodicFacePair< typename DoFHandler<dim>::cell_iterator > > periodic_faces;
  GridTools::collect_periodic_faces(dof_handler,0,1,0,periodic_faces,offset);
  DoFTools::make_periodicity_constraints<DoFHandler<dim> > (periodic_faces, constraints);

for the first occurrence in your code. Does this help?

Best,
Daniel

Joel Davidsson

unread,
Nov 2, 2016, 6:07:03 AM11/2/16
to deal.II User Group
Dear Daniel,

Same error with your changes. I searched for subdivided in http://www.dealii.org/developer/doxygen/deal.II/changes_between_8_3_and_8_4.html and found under specific improvements, that subdivided_parallelepiped produced the wrong boundary indicators. Could this be the reason, why it doesnt work? Perhaps I need to update the version Im running.

Best,
Joel

Daniel Arndt

unread,
Nov 2, 2016, 1:18:14 PM11/2/16
to deal.II User Group
Joel,


Same error with your changes. I searched for subdivided in http://www.dealii.org/developer/doxygen/deal.II/changes_between_8_3_and_8_4.html and found under specific improvements, that subdivided_parallelepiped produced the wrong boundary indicators. Could this be the reason, why it doesnt work? Perhaps I need to update the version Im running.
Yes, this makes perfect sense. Either you update or you set the boundary indicators correctly yourself.

Best,
Daniel
Reply all
Reply to author
Forward
0 new messages