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

Thu Nov 1 00:00:48 CDT 2012

Hello Lorenzo, 

----- Original Message -----

Option 5 is very very close to what I consider an agglomerated element, with a strong restriction on the element shape in this case. 

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? 

<blockquote>

</blockquote>

<blockquote>
Actually I store agglomerated elements as entity sets. Some time ago I submitted a patch to partition such agglomerated elements meshes based on an arbitrary tag associated to each set. 
I can resubmit it if someone is interested. 

</blockquote>
I think we have the patch, it is also about fixing an issue with mbzoltan. (you sent it on May 4, 2012, mbzoltan.zip) It is not applied yet, as far as I can tell. 

About the entity sets, isn't it easier to create a coarse mesh on top of finer mesh, as Tim suggested as an improvement to option 5? (so, instead of entity sets, why not create elements, corresponding to the spectral, coarse mesh?) Then, you can even partition based on those coarser elements, you have adjacency between spectral elements naturally defined. Adjacency between sets of elements is not that natural, you will have to look at the entities in the sets 

<blockquote>

It would be interesting to have the ability to generate high order spectral elements starting from block structured meshes. Is it possible to do such a thing using the structured mesh MOAB interface? 

</blockquote>
I am not sure I understand. Should a structured block correspond to a spectral element, or do you need to have structured blocks of spectral elements? I assume the former. It is an interesting idea. There are many methods that could be useful, and the elements and nodes, are ordered basically in lexicographic order, for a SCD box. Also, in an SCD box, nodes are created explicitly, while elements, edges, faces have an implicit connectivity, which can be deduced based on number of nodes in each direction. With this, let's call it option 6, there are clear savings on the connectivity arrays, compared to option 5, but there could be some issues about adjacencies between boxes. It is, I think, similar to option 3. 

<blockquote>
Regarding the spectral meshes storage I have to say I use nodes only to define the domain discretization, then I use modal basis functions for the discrete spaces. 
</blockquote>
So, how do you compute, for example, the nodes corresponding to the gauss lobatto points in a spectral element? 
Assume you start from a hex27 tri-quadratic hexa. The GL points are well defined for any order inside a [-1,1]^3 domain. Do you simply map those using tri-quadratic map? So in that case, do you really need the GL points for domain discretization? Isn't the original hex27 map good enough for domain discretization? Or maybe you know that one side of the element is actually an arc of a circle, then maybe you map directly on the arc, not on the "quadratic" curve connecting end nodes and midnode on that edge? Nek5000 does something like this, in my understanding. 

I assume that when you say "modal basis functions" you are referring to the fact that basis functions are defined in the parametric fundamental element [-1, 1]^3, where all computations/projections take place. 

Another problem I am trying to understand: So you do not really need the position of those GL points, except maybe for visualization of results. Internally, once your element is defined, GL position does not really contribute anything to the solver (of course, weights associated to it are important for integration, position in parametric space; but the actual 3d mapped position is not really needed, is it?) 

<blockquote>
For lagrangian elements I don't need a tag for dofs storage since the dofs are the nodes coordinates themselves. 
</blockquote>
In your application, do you have dofs corresponding to temperature, or pressure, or even velocity? Then, they can't be the nodes coordinates themselves. You may need additional dofs. Or am I misunderstanding (again :( ) ? 

<blockquote>
I'm interested in considering other possibilities like splines, nurbs... 
</blockquote>
I assume you are talking about geometric boundary (like the arc example I gave above?) 

<blockquote>
In this context I think that the ability to easily obtain all (low and high order) nodes for each side is important, so option 2 I guess. This also allows to easily get the nodes required to define a high order serendipity element. 

</blockquote>
I think that as long as "finer" elements are defined/created consistently, ordered with a clear rule, we can imply all side nodes, edges, faces (in a similar way to a structured block) 

<blockquote>

Thanks for the opportunity to share ideas. 
</blockquote>
Thank you for your ideas, it is very helpful to understand how a spectral element is used. 

Best Regards, 
Iulian 

<blockquote>

Best regards. 
Lorenzo 

Tim Tautges <tautges at mcs.anl.gov> wrote: 

>Aha, right, forgot to mention the current solution, which is to construct fine mesh from GLL points in each element. 
>Your option 5 would be to do that then link those elements to coarse elements somehow. Would probably be easiest using 
>a tag with start/end of a coarse element's refined elements. This would also work for h-refined meshes. 
> 
>- tim 
> 
>On 10/31/2012 12:07 PM, Iulian Grindeanu wrote: 
>> 
>> 
>> ------------------------------------------------------------------------------------------------------------------------ 
>> 
>> Hi all, 
>> We're now supporting with MOAB two different applications that use spectral meshes (Nek5000, an ANL CFD code, and 
>> HOMME, an SNL/NCAR climate code). As is usually the case, we not only have to represent these meshes in MOAB, but 
>> support meshes of those types in tools working on MOAB (viz, partitioning, etc). Spectral meshes are challenging 
>> because there are many ways to represent and order them, with applications typically using a lexicographic ordering and 
>> mesh-based tools preferring something more akin to higher-order element ordering. 
>> I've written the attached document that describes the problem, along with a few possible options for representation 
>> of these meshes. I'd welcome comments if you have them. Thanks. 
>> 
>> - tim 
>> 
>> Hello, 
>> There is another option, which is actually close to what we do now in Homme meshes: store the "finer" mesh, formed by 
>> spectral points, in a 
>> very regular grid, on each "coarse" element. And maybe have a method to group the "finer elements" on each "coarse" 
>> (spectral ) element. 
>> 
>> It is much more expensive for 3d (homme is basically 2d manifold), so maybe it is not worth mentioning. The only 
>> advantage to this (5th) option is that is probably the easiest in terms of development, and we could even use the 
>> existing visu tools. (actually, there is a visit plugin to display nek meshes directly, using this concept) 
>> 
>> All other options will need some working on the visu side. 
>> 
>> Iulian 
>> 
>> -- 
>> ================================================================ 
>> "You will keep in perfect peace him whose mind is 
>> steadfast, because he trusts in you." Isaiah 26:3 
>> 
>> Tim Tautges Argonne National Laboratory 
>> (tautges at mcs.anl.gov) (telecommuting from UW-Madison) 
>> phone (gvoice): (608) 354-1459 1500 Engineering Dr. 
>> fax: (608) 263-4499 Madison, WI 53706 
>> 
>> 
> 
>-- 
>================================================================ 
>"You will keep in perfect peace him whose mind is 
> steadfast, because he trusts in you." Isaiah 26:3 
> 
> Tim Tautges Argonne National Laboratory 
> (tautges at mcs.anl.gov) (telecommuting from UW-Madison) 
> phone (gvoice): (608) 354-1459 1500 Engineering Dr. 
> fax: (608) 263-4499 Madison, WI 53706 
> 

</blockquote>

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