[petsc-users] Multi-physics meshes with PETSc DM?

Andrew Ho andrewh0 at uw.edu
Sat Jul 30 13:35:41 CDT 2016


Is there a reason the physical groups aren't sufficient for handling this?
As far as I can tell, this is the only way in GMsh to have any kind of
grouping of elements.

The Gmsh file format can be found here (happens to be the ASCII version,
but binary version is below that):
http://gmsh.info/doc/texinfo/gmsh.html#MSH-ASCII-file-format

All tags are attributed to elements; there may be multiple element types
(points, lines, triangles, etc.), but at the end of the day each element
just has a list of indices indicating which physical group(s) each element
belongs to.

>From the documentation for ASCII formatted mesh files:

number-of-tags

gives the number of integer tags that follow for the n-th element. By
> default, the first tag is the number of the physical entity to which the
> element belongs; the second is the number of the elementary geometrical
> entity to which the element belongs; the third is the number of mesh
> partitions to which the element belongs, followed by the partition ids
> (negative partition ids indicate ghost cells). A zero tag is equivalent to
> no tag. Gmsh and most codes using the MSH 2 format require at least the
> first two tags (physical and elementary tags).


My understanding is to support markers you only need to add a 4th stratum
level which has one node per physical group. It would be helpful (though
not necessary) if this subdomain marker stratum level had the physical tag
name labels properly associated with the corresponding nodes on the graph,
but this is not necessary since it's just as easy to refer to them by node
number as long as the node numbering matches or is a simple transform of
the numbering scheme in the original physical group id's.


On Sat, Jul 30, 2016 at 11:11 AM, Matthew Knepley <knepley at gmail.com> wrote:

> On Sat, Jul 30, 2016 at 1:06 PM, Andrew Ho <andrewh0 at uw.edu> wrote:
>
>> 1) I don't use Physical Groups from GMsh since its unclear how this would
>>> be reflected in the discretization
>>
>>
>> If I'm not using physical groups in GMsh, how do I easily denote what
>> part of the domain should be handled with which physics? I would like to be
>> able to use the same code with similar but not identical meshes (for
>> example to do a convergence study), so manually iterating through a list of
>> vertices at the element height stratum in a chart doesn't provide any hints
>> on which subdomain an element is suppose to belong in.
>>
>
> I think the right way to handle all this is to just mark pieces of the
> mesh. Mesh formats should just have a generic marking
> ability which does not differentiate between vertices, edges, faces, and
> cells. Some formats come close (ExodusII) and some
> are just crazy (GMsh). If you can point me toward the documentation for
> the GMsh format, I will put in code to translate whatever
> part marks cells to a cell label, as we do for ExodusII.
>
>   Thanks,
>
>      Matt
>
> --
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which their
> experiments lead.
> -- Norbert Wiener
>



-- 
Andrew Ho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20160730/a6862a33/attachment.html>


More information about the petsc-users mailing list