[MOAB-dev] DMMoabGetMaterialBlock

[Tim Tautges]

On 12/09/2014 01:59 PM, Vijay S. Mahadevan wrote:
> Gerd,
>
> This question led to an interesting discussion, the outcome of which
> tells me that there isn't a clean way to get hold of the material id
> directly by giving the entity handle unless explicitly set before. It
> should be trivial if each element entity had a tag defined but if they
> are grouped together as sets and only these sparse sets have material
> tags defined, the current data structure does not provide a capability
> to find the sets a particular handle belongs to and then retrieve the
> material tag on it. At least not without couple of different calls.
>

There is actually a way, though a bit indirect: set the material sets to be tracking sets, which will mark contained 
entities with containing sets in those entities' adjacencies.  Then you query an entity for adjacent sets, and intersect 
that with all material set handles (which should probably be cached).  The cost between making a dense tag with material 
set number (with the appropriate default value) and the solution I describe is probably quite small, assuming all 
entities of a given type have non-default material set.

- tim

> The original motivation for designing it this way is to save on the
> memory needed since the materials are defined only on sets of
> entities. And applications would typically do their FEM assembly over
> the entities contained in each material set, but I can see why this is
> constrained and should not be imposed by MOAB on applications.
>
> loop over blocks
>    loop over elements
>       FEM assembly
>    end loop over elements
> end loop over blocks
>
> The easiest fix is for me to locally cache the material data for each
> local entity in DMMoab (during setup) and provide that back on calls
> to DMMoabGetMaterialBlock. But this code is not there yet and I will
> have to work on this, test and send you a patch.
>
> Thoughts ? I'll keep you updated as I prepare the necessary patch for DMMoab.
>
> Vijay
>
> On Tue, Dec 9, 2014 at 11:15 AM, Grindeanu, Iulian R.
> <iulian at mcs.anl.gov> wrote:
>> Hello,
>> So material tag is a sparse tag with default value -1. We usually define it on the sets, not on the entities.
>> If the mesh is from cubit or exodus, this tag is on the sets corresponding to "blocks".
>> (the logic behind it is that it uses less memory, we define the material tag value on the sets, and not on individual entities). being sparse, but with a default value of -1, if the user asks for the material tag directly on an entity, it will most likely return -1.
>>
>> The manual / documentation might be unclear about this
>> How to make this more clear in the manual?
>>
>> Iulian
>> ________________________________________
>> From: moab-dev-bounces at mcs.anl.gov [moab-dev-bounces at mcs.anl.gov] on behalf of Vijay S. Mahadevan [vijay.m at gmail.com]
>> Sent: Tuesday, December 09, 2014 10:15 AM
>> To: Gerd Heber
>> Cc: MOAB dev
>> Subject: Re: [MOAB-dev] DMMoabGetMaterialBlock
>>
>> DMMoabGetMaterialBlock is a simple call internally to directly access
>> the tag data for MATERIAL_SET defined on the entity requested. By
>> default, all entities could contain a value (-1) and so it is possible
>> that your mesh does not have a material value assigned for the
>> element. If you have a small enough mesh file (h5m/exo) where you can
>> replicate this, I can see what is going on.
>>
>>> "Thus, a materrial set in MOAB is unlikely to contain mesh entities directly; rather, that set
>>> contains other sets which contain mesh entities. In these cases, mesh entities can be retrieved by
>>> passing a "recursive" flag to the appropriate function (MOAB), or by calling the getEntitiesRec
>>> extension function (iMesh) provided by MOAB."
>>
>> This is partly true but not always the case. A set can contain other
>> sets or entities directly. This depends on how you created the mesh
>> (package/format) or if you created it yourself in memory and assigned
>> some data. Either way, it should find the data defined on the queried
>> entity. The recursive flag is required when you are trying to access
>> all entities in a set i.e., if you query a set containing other sets,
>> you will need recursive flag set or else you will not get all the
>> entities as expected.
>>
>> Iulian, do we need to update the documentation ?
>>
>> Vijay
>>
>> On Tue, Dec 9, 2014 at 7:42 AM, Gerd Heber <gheber at hdfgroup.org> wrote:
>>> I'm trying to use DMMoabGetMaterialBlock to read an element's material ID,
>>> however I'm getting -1 for all elements. I have a nice MATERIAL_SET tag in
>>> my MOAB file. Is this related to the following comment in the MOAB documentation?
>>>
>>> "Thus, a materrial set in MOAB is unlikely to contain mesh entities directly; rather, that set
>>> contains other sets which contain mesh entities. In these cases, mesh entities can be retrieved by
>>> passing a "recursive" flag to the appropriate function (MOAB), or by calling the getEntitiesRec
>>> extension function (iMesh) provided by MOAB."
>>>
>>> (http://ftp.mcs.anl.gov/pub/fathom/moab-docs/md-contents.html)
>>>
>>> If so, how do I enable the "recursive" flag from PETSc? Maybe I'm barking up the wrong tree...
>>>
>>> Thanks for your help.
>>> G.

-- 
Timothy J. Tautges
Manager, Directed Meshing, CD-adapco
Phone: (631) 629-3139 (internal: x29130)
Mobile/Gvoice: (608) 354-1459
timothy.tautges at cd-adapco.com