Oded Yaakobi
Dear all,
I am trying to solve a 3D problem with moving boundaries that exhibit very large deformations. During my runs, the grid, which is represented by a MappingQEulerian object, becomes highly distorted. For instance, some of the cells are pinched.
Following Wolfgang’s useful suggestion, I am trying to improve my mesh quality during the runs by calling Mesquite from within my application, (see https://groups.google.com/forum/#!searchin/dealii/CUBIT%7Csort:relevance/dealii/f3jWQ7DPeYA/Dt8jXd-HAQAJ).
Attached is Mesquite’s User Guide. Sec. 4.2 - “Accessing Mesh In Arrays” on pages 26-27 describes the format in which the mesh has to be saved in a calling application in order to call Mesquite.
I have wondered – Does deal.ii have built-in functions to create the required “coords” and “quads” arrays that are described there?
Please note that the User Guide’s example is 2D, but my case may be slight more general since it is 3D and uses a MappingQEulerian object.
Thanks for your advice,
Oded
Wolfgang Bangerth
Oded,
> I am trying to solve a 3D problem with moving boundaries that exhibit very
> large deformations. During my runs, the grid, which is represented by a
> MappingQEulerian object, becomes highly distorted. For instance, some of the
> cells are pinched.
>
> Following Wolfgang’s useful suggestion, I am trying to improve my mesh quality
> during the runs by calling Mesquite from within my application, (see
> https://groups.google.com/forum/#!searchin/dealii/CUBIT%7Csort:relevance/dealii/f3jWQ7DPeYA/Dt8jXd-HAQAJ
> Attached is Mesquite’s User Guide. Sec. 4.2 - “Accessing Mesh In Arrays” on
> pages 26-27 describes the format in which the mesh has to be saved in a
> calling application in order to call Mesquite.
>
> I have wondered – Does deal.ii have built-in functions to create the required
> “coords” and “quads” arrays that are described there?
Triangulation::get_vertices(). For the vertex indices in the quads array, you
can just do
std::vector<long> quads;
for (cell=...)
for (v=0..4)
quads.push_back (cell->vertex_index(v));
Cheers
W.
--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@math.tamu.edu
www: http://www.math.tamu.edu/~bangerth/
Oded Yaakobi
Wolfgang Bangerth
>
> Doesn’t Triangulation::get_vertices() give the coordinates of the original
> location of vertices and not their current displaced coordinates as
> represented by MappingQEulerian?
over all cells, get the mapped vertices, and enter them into an array of your
own. You will have to use MappingQEulerian and an FEValues object initialized
with QTrapez (which has quadrature points on the vertices).
> Since my problem is 3D and I work with hexahedral elements (I would state this
> fact in the creation of the ArrayMesh object that passes the mesh into
> Mesquite), I guess that the vertex indices should be retrieved by the following:
>
> std::vector<long> hexahedra;
> for (cell=...)
> for (v=0..7)
> hexahedra.push_back (cell->vertex_index(v));
>
> Anyway, one has to be sure that the convention of vertices numbering within
> each cell is the same in deal.ii and in Mesquite. If not, a minor modification
> in the inner “for” loop has to be made.
thomas stephens
I am working on an evolving codimension-1 surface, representing deformations through the MappingQEulerian object, and running into what I presume is a similar problem as you have - tangential mesh distortion.
How has your experience with Mesquite turned out? Specifically, how has the support and documentation been in your opinion? And have you been satisfied with the results that have been returned from Mesquite's built in algorithms?
I'm trying to gauge how much time would need to be invested in integrating this into my simulations, any thoughts would be appreciated.
Tom
Oded Yaakobi
Hi Tom,
I have seen your user group correspondence in the past week, and considered whether to describe my experience with Mesquite. It wasn't good, and I didn't want to discourage you, so I didn't comment about it. Anyway, now that you have asked me, I will do it.
In my opinion, Mesquite's documentation is not good. As far as I could understand from searching online, it was a small project, and most of its developers are not working on it anymore. I don't think that they have any user support.
I had many problems with Mesquite's installation, and later on with its use. It was hard to understand how to install it and how to use its functions. For instance, one of the header files was missing, so I couldn't use some of the functionality that I wanted.
I tried to use several of Mesquite's mesh smoothing algorithms, and as far as I remember, only one of them run successfully. Eventually, I abandoned Mesquite. Instead of Mesquite, I began to use Cubit, which has built-in into it some of the functionality of Mesquite, as well as many other features. See:
From my limited experience, Cubit has excellent documentation, trainings, and its interface is friendly to the user. It is free and limited for US government users, but has a similar (not free) product for academic and commercial users called Trelis. See:
I would definitely recommend the use of Cubit/Trelis.
I will be happy to answer further questions, if you have any.
Best,
Oded
thomas stephens
Thank you for your assessment. Mediocre documentation combined with a stalled development is certainly a recipe for frustration. I have recently obtained a license for cubit - I would like to ask you about that but it will have to wait until the middle of next week, I'm a little busy right now.
If you don't mind, I'll get back to you on this thread in a few days. Thanks again,
Tom
thomas stephens
https://groups.google.com/d/msg/dealii/tZK3R79j9d4/BW9WUrWVAAAJ