how to get 3D structured mesh from rotated 2D mesh in dealii

[Marek Čapek]

Hello,
I have problems creating reasonable structured mesh for l-shaped domain in gmsh in 3D.
I  created the 2d l-shaped mesh in dealii by hand, see the attachment-lshape.eps and lshape.msh. The 2D mesh looks
nicely. I would like to process it in dealii by rotating it around y-axis, to get 3D grid.
Is it possible in dealii?
 I have tried the same procedure in gmsh, however I have not been able to generate
structured mes (I have meshed the file l_shaped.geo)
I have experimented with meshes defined in gmsh .geo files, where I have meshed the geometries
originating from rotation of l-shaped 2D domain, however I have not been able to get structured
mesh.
My objective is the mesh in the file the attached file perf_chamber.png, which was obtained by merging
the inner cylinder and outer cylinder shell. The mesh seems however to have some "double" vertices at
the interface between the merged entities, which possibly cause, that the computation fails, see image
velocity.png


Thank You

Marek

[Marek Čapek]

I show just another image - it appear that the velocity field has opposite directions
at the interface of two merged entities - cylinder and cylinder shell.
In other geometries my code runs reasonably without such phenomenons.

M



Dne neděle 25. září 2016 12:38:12 UTC+2 Marek Čapek napsal(a):

[Daniel Arndt]

Marek,

[...] I would like to process it in dealii by rotating it around y-axis, to get 3D grid.

Is it possible in dealii?

No, there is no such function yet.
 

[...]

My objective is the mesh in the file the attached file perf_chamber.png, which was obtained by merging
the inner cylinder and outer cylinder shell. The mesh seems however to have some "double" vertices at
the interface between the merged entities, which possibly cause, that the computation fails, see image
velocity.png

This is the approach I would have taken for creating the desired geometry. The problem here seems to be
that the faces at the interface don't match as the inner cylinder has more cells. This is the reason why
GridGenerator::merge_triangulations doesn't work as expected.
How do you create the cylinder and the cylinder shell and how do they actually look like at the interface?

Best,
Daniel

[Vinetou Incucuna]

Hi Daniel,

thank You for Your answer.

1)In my first attempt I merged (in gmsh) the geometries in files inner.msh,outer.msh, which, on meshing, gave me

the file result.msh

2)in my second shot I merged extruded (in dealii)

 the cylinder_shell geometry from dealii function hyper_shell() and extrusion of my hand written mesh (on meshing hand_written.msh)for 2D "circle"

and obtained the mesh in the file chamber_coarse.msh

I have tried to have the complying numbers n_slices and height in the call of the function
void GridGenerator::extrude_triangulation ( const Triangulation< 2, 2 > &  input, const unsigned int  n_slices, const double  height, ...]

Computation with both meshes resulted in the strange behaviour on the interface between inner cylinder and outer cylinder shell mentione

above.

Could You help me, please, to find the error

Thank You

P.S.: Maybe a viable path would be to implement my own version of

oid GridGenerator::cylinder ( Triangulation< dim > &  tria, const double  radius = 1., const double  half_length = 1.  )

to be from y=0 to y=2*half_lenght

However, can I suppose, that the resulting triangulation will be compatible?  I would need a hint for this case.

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Arndt]

Marek,

the attached file should be close to what you want to do.
Basically, you need to create two geometries: One for the cylinder shell and one for the cylinder.
Here, we take advantage of the fact that GridGenerator::cylinder always creates four subdivisions w.r.t height.
Furthermore, the cylinder needs to be refined once to match the vertices of the cylinder shell. Since we can only merge
coarse triangulations, we need to flatten the resulting triangulation.
If you want to create a gemoetry with a different height, you can delete cells in the cylinder triangulation using GridGenerator::create_triangulation_with_removed_cells
or add more cells by merging another cylinder.

Best,
Daniel

[Vinetou Incucuna]

Hello Daniel,

I have fixed the problem using Your proposed algorithm of mesh creation.

The strange behaviour of velocity-pressure field was really caused by the

bad quality of the mesh (possibly doubled vertices at the boundary between

merged entities).

I want to ask a question, which could be interesting for other users of dealii-

do we have some bulletproof procedure, how to produce (not so simple) geometries,

meshes in gmsh and then merge them "safely" in the dealii? Safely meaning- without

the creation of the doubled vertices at the boundary between merged geoetries, meshes?

Is there some procedure in dealii to cope with this problem?

The function merge_triangulation requieres "matching" triangulation, could it be possible

to define a function, which would somehow merge vertices at the boundary of two not-so-nice

matching trianguations (possibly within some toleration, i.e. if two vertices are less then \eps

away from each other, than merge them....)

Does my idea make sense?

Thank You

Marek

--

[Daniel Arndt]

Marek,

[...] 

I want to ask a question, which could be interesting for other users of dealii-

do we have some bulletproof procedure, how to produce (not so simple) geometries,

meshes in gmsh and then merge them "safely" in the dealii? Safely meaning- without

the creation of the doubled vertices at the boundary between merged geoetries, meshes?

Is there some procedure in dealii to cope with this problem?

The function merge_triangulation requieres "matching" triangulation, could it be possible

to define a function, which would somehow merge vertices at the boundary of two not-so-nice

matching trianguations (possibly within some toleration, i.e. if two vertices are less then \eps

away from each other, than merge them....)

Does my idea make sense?

This is already done in GridTools::delete_duplicated_vertices [1]. The problem you experienced results from the fact that a coarse mesh cannot contain any hanging nodes in deal.II. Therefore, the faces at the interface have to match, i.e. there is 1-1 correspondence. This is something you have ensure when creating the meshes you want to merge

and I don't see an easy way to work around this automatically.

Best,

Daniel

[1] https://www.dealii.org/8.4.1/doxygen/deal.II/namespaceGridTools.html#a79820d66b08b06e94541817ba78d6213 

[Vinetou Incucuna]

Hello Daniel,

thank you for the answer.

I have read in the documention only

This function is called by some GridIn::read_* functions.

fully forgetting the following

Only the vertices with indices in considered_vertices are tested for equality. This speeds up the algorithm, which is quadratic and thus quite slow to begin with. However, if you wish to consider all vertices, simply pass an empty vector.

i.e. I have assumed it is called by default for all vertices.

Best

Marek

--

[Daniel Arndt]

Marek,

Only the vertices with indices in considered_vertices are tested for equality. This speeds up the algorithm, which is quadratic and thus quite slow to begin with. However, if you wish to consider all vertices, simply pass an empty vector.

i.e. I have assumed it is called by default for all vertices.

Even if it is called for all vertices, this would not help you with your problem. You would still have the problem with creating hanging nodes in your coarse mesh.

Best,
Daniel