[petsc-dev] Problem with unnamed side sets in DMPlexCreateExodus

[Matthew Knepley]

On Sun, Jun 26, 2022 at 8:31 AM David Andrs <andrsd at gmail.com> wrote:

> Hi Jed!
>
> I have been thinking about this and I think more correct would be not to
> create the label with an empty name. It is not all or nothing kind of a
> deal. Some side sets may have a name, some may not.
>
> What I sent is probably more convenient, since after loading the mesh
> there is either a label with a name or with an ID which can be easily
> grabbed and passed into `PetscDSAddBoundary`. However, I agree that
> assigning the name with an ID like this is specific to an application.
>
> I can send a patch that will prevent the creation of a label with an empty
> name if you think this is what should be happening instead.
>

I think what Jed is suggesting is to use "Face Sets" if the name is empty.
I currently prefer this solution. Would this screw up your current workflow?

I would also like to have a consistent policy for everything, but it is
hard for me to see what this would be right now.

  Thanks,

      Matt


> —
> David
>
>
> > On Jun 25, 2022, at 22:54, Jed Brown <jed at jedbrown.org> wrote:
> >
> > Do you think this is more correct than just using "Face Sets", which
> gives you a numbered index?
> >
> > There is curently some inconsistency between file formats in whether
> various sets show up as stand-alone labels or values under Face Sets. And
> there's this lingering issue to have a way to name Face Sets (and Cell
> Sets).
> >
> > https://gitlab.com/petsc/petsc/-/issues/689
> >
> > The issue is that if we just make named labels, there's no good way to
> do structured traversal (handle all Face Sets) and one also has to be
> careful to avoid namespace collisions between application sets and sets
> created by the mesh.
> >
> > David Andrs <andrsd at gmail.com> writes:
> >
> >> Hello!
> >>
> >> The current behavior in DMPlexCreateExodus is assuming that side sets
> are always named. However, that is not always true. If there are unnamed
> side sets in an ExodusII file, the created DM will contain a label with an
> empty name (“”) with as many stratas as there are side sets. See the sample
> output from DMView below:
> >>
> >> Labels:
> >>  celltype: 3 strata with value/size (0 (138900), 4 (125514), 1 (265620))
> >>  depth: 3 strata with value/size (0 (138900), 1 (265620), 2 (125514))
> >>  Cell Sets: 4 strata with value/size (1 (57888), 2 (57888), 4 (1824), 5
> (7914))
> >>  Face Sets: 6 strata with value/size (1000 (28944), 1001 (28944), 1003
> (28944), 1005 (15144), 1100 (120), 1200 (120))
> >>  : 6 strata with value/size (1000 (28944), 1001 (28944), 1003 (28944),
> 1005 (15144), 1100 (120), 1200 (120))
> >>
> >> The attached patch fixes the behavior and names the side sets according
> to their IDs if there is no name associated with it in the ExodusII file.
> See the modified behavior below:
> >>
> >> Labels:
> >>  celltype: 3 strata with value/size (0 (138900), 4 (125514), 1 (265620))
> >>  depth: 3 strata with value/size (0 (138900), 1 (265620), 2 (125514))
> >>  Cell Sets: 4 strata with value/size (1 (57888), 2 (57888), 4 (1824), 5
> (7914))
> >>  Face Sets: 6 strata with value/size (1000 (28944), 1001 (28944), 1003
> (28944), 1005 (15144), 1100 (120), 1200 (120))
> >>  1000: 1 strata with value/size (1000 (28944))
> >>  1001: 1 strata with value/size (1001 (28944))
> >>  1003: 1 strata with value/size (1003 (28944))
> >>  1005: 1 strata with value/size (1005 (15144))
> >>  1100: 1 strata with value/size (1100 (120))
> >>  1200: 1 strata with value/size (1200 (120))
> >>
> >> The patch is against 3.17.0, but is seems it should apply cleanly on
> 3.17.2.
> >>
> >> With regards,
> >>
> >> David Andrs
>
>

-- 
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

https://www.cse.buffalo.edu/~knepley/ <http://www.cse.buffalo.edu/~knepley/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20220626/cdd7c958/attachment.html>