[MOAB-dev] Representation of spectral meshes, opinions wanted

[Lorenzo Alessio Botti]

> What is the restriction? Do you start from the geometry of the coarse element ? Are you referring to the shape of spectral element (agglomerated) or to smaller, finer elements?
> I am not sure I understand :(. Will your agglomerated element correspond to a spectral element?

Let's consider the 2D case. The restriction is that the fine elements are quadrilaterals and the resulting spectral element must have four sides. 
In general I start from fine elements and then cluster them together to obtain very general polygonal cells. The goal is to create a coarse enough grid with a suitable domain representation, provided by the fine elements faces located at the domain boundaries. The resulting elements have not an an high order geometry representation but their faces are composed by many low order segments. The order can be increased increasing the order of the fine elements, as you know second order is fully supported by MOAB.
Using modal basis functions defined in the physical frame, not in the reference frame, the degree of the dG discretization (this is my choice but also a restriction of this approach) can be chosen independently from the geometry representation and the element shape. If you are interested in some computations with agglomerated elements you can take a look at this paper http://dx.doi.org/10.1016/j.compfluid.2011.11.002.
This approach is flexible but the traditional spectral approach is more efficient. One issue with elements of general shape is integration, on the other hand the generation of spectral meshes is not an easy task and higher than second order grid generators are not widespread. 

One thing that we do to create spectral meshes in the common sense is to start from a block structured grid and then agglomerate the fine elements in each block to create spectral quads and hexs. Here the structured organization of the blocks is mandatory... The number of nodes in each block, the number of elements nodes and the number of elements in each block must be carefully chosen. The nodes of the elements we obtain are not in specific locations and they are not suitable for integration. We usually discard nodes in the interior of the elements and optimize surface nodes on the domain boundaries to obtain a good geometry representation. Since we don't need nodes for the FE discretization we consider serendipity elements having all nodes on the sides (true up to degree 4 in 3D). Then we can define reference to physical frame mappings and get the integration points in the interior of the element, we usually use gauss integration not gauss-lobatto.
This procedure is fully "nodal" but I guess in the long term something based on some kind of spline would be more convenient and flexible. We already need splines to optimize nodes positions on sides.
It would be great to implement such a procedure based on the SCD interface!

Lorenzo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/moab-dev/attachments/20121101/aa78b420/attachment.html>