[MOAB-dev] MOAB question

[Suzanne Shontz]

Jason & Tim,

Actually, on closer inspection of the resulting meshes, I see that mbskin 
did *not* yield the desired result.  mbconvert yielded hex meshes (but 
without boundary information), whereas mbskin (when called as indicated 
below) yielded the desired boundary information, but it returned hybrid 
meshes with tet and hex elements.  Any idea why this is happening?  The 
meshes are definitely hex meshes I'm trying to convert.  Any suggestions
would be appreciated.

Thanks,
Suzanne



On Tue, 2 Dec 2008, Suzanne Shontz wrote:

> Dear Jason & Tim,
>
> Thanks for your very helpful responses.  The solution suggested in the "short 
> answer" section did the trick.  All I needed was the 0's and 1's to mark 
> vertices as fixed/free for Mesquite.  (Although you'd be happy to know that I 
> read the long answer solution, too.)
>
> -- Suzanne
>
>
> On Tue, 2 Dec 2008, Jason Kraftcheck wrote:
>
>> Tim Tautges wrote:
>>> Only have time for a quick answer just now, but you should use mbtagprop 
>>> to propagate sets (which are used to represent cubit 
>>> blocks/nodesets/sidesets) to tags (variables on indiv mesh entities 
>>> representing same thing).
>>> 
>>> - tim
>>> 
>>> Suzanne Shontz wrote:
>>>> Dear Tim:
>>>> 
>>>> I've been using MOAB to convert some hex meshes from the Exodus II file 
>>>> format (they're meshes generated with CUBIT) to the VTK file format.
>>>> The outputted VTK files contain information on the vertex coordinates and 
>>>> the hex elements.  However, they do not contain information as to
>>>> which vertices are/are not part of the surface (i.e., boundary).  Is 
>>>> there
>>>> an option within MOAB to write out this additional information?  Note
>>>> that I'm calling mbconvert as follows:  mbconvert file.g file.vtk.
>>>> 
>>>> Thanks in advance for your help,
>>>> Suzanne
>>>> 
>>> 
>> 
>> Short answer:
>> 
>> If all you want is to mark the boundary vertices as fixed so that they can 
>> be used as input to Mesquite, use the mbskin utility:
>>  mbskin -t -w file.g file.vtk
>> 
>> Long answer:
>> 
>> ExodusII files do not directly contain any information about which vertices 
>> are part of a geometric surface or which are on the skin of the mesh.  To 
>> embed this information in an ExodusII file using Cubit you will need to 
>> create sidesets or nodesets containing the boundary of the mesh.  Cubit 
>> will write those to the ExodusII file.
>> 
>> Alternately, you could write a 'cub' file from Cubit, which will contain 
>> the grouping of mesh entities according to which geometric entities they 
>> lie on (surfaces, curves, etc.)
>> 
>> VTK files have no mechanism by which to represent groups of entities. The 
>> best that can be done is to 'tag' (e.g. store an integer value on) each 
>> entity indicating the group it belongs to.  The mbtagprop utility Tim 
>> mentioned can do such things.  E.g. it can be used to write the ID of each 
>> geometric surface as a tag on each vertex that is constrained to lie on 
>> that surface.
>> 
>> If you have an ExodusII file containing nodesets (dirichlet sets) and you 
>> want to store on each node the ID of the nodeset it is contained in, I 
>> think the following will work:
>>  mbtagprop -t DIRCHLET_SET -n file.g file.vtk
>> 
>> If instead you want to write a '1' to a tag named 'fixed' for every node 
>> contained in a nodeset, then I think the following syntax will work:
>>  mbtagprop -t DIRICHLET_SET -c fixed=integer:1=1 -n file.g file.vtk
>> 
>> - jason
>

-- 
Suzanne Shontz
Assistant Professor
Department of Computer Science and Engineering
College of Engineering
343J Information Sciences & Technology Building
The Pennsylvania State University
University Park, PA  16802 USA
phone:   814-865-0193
fax:     814-865-3176
e-mail:  shontz at cse.psu.edu
web:     http://www.cse.psu.edu/~shontz