[petsc-dev] higher-order coordiate fields in DMPlex

[Matthew Knepley]

On Fri, Jun 2, 2017 at 8:38 PM, Jed Brown <jed at jedbrown.org> wrote:

> Matthew Knepley <knepley at gmail.com> writes:
>
> > On Fri, Jun 2, 2017 at 7:55 PM, Jed Brown <jed at jedbrown.org> wrote:
> >
> >> Matthew Knepley <knepley at gmail.com> writes:
> >>
> >> > On Fri, Jun 2, 2017 at 5:04 PM, Alberto Paganini <
> >> > Alberto.Paganini at maths.ox.ac.uk> wrote:
> >> >
> >> >> Dear PETSc developers,
> >> >>
> >> >> I'm Alberto and I'm a user of the finite element library Firedrake,
> >> >> which relies on DMPlex to import meshes.
> >> >>
> >> >
> >> > Great.
> >> >
> >> >
> >> >> In order to use higher-order FEs, it is desirable to import
> higher-order
> >> >> meshes.
> >> >>
> >> >
> >> > I really do not like that term. Let me try and convince you that it is
> >> > wrong. The topology of the
> >> > mesh is unchanged. You are only talking about the order of the
> >> > representation of the geometry
> >> > field. Thus, it is not the mesh that is "higher order", but the
> geometry.
> >> >
> >> >
> >> >> I've been told that DMPlex does not offer this future (at present).
> >> >>
> >> >
> >> > Toby just merged this to master, so I think we can say that we have
> alpha
> >> > support for this. How
> >> > does it work? We already have a coordinateDM and coordinates Vec, so
> you
> >> > just choose a
> >> > higher order discretization for the DS inside the coordinateDM. Does
> that
> >> > make sense?
> >>
> >> Can it load quadratic geometry from a file (ExodusII or otherwise)?
> >>
> >
> > If someone requests a given file format, we can do it. That's how we
> always
> > proceed.
>
> Okay.  When people ask about higher order geometry for unstructured
> finite elements, I think that about 90% of the time they're really
> asking whether it can read quadratic geometry from a file.  I hate that
> ExodusII is a cumbersome dependency, but it might be the most useful to
> add.  This wouldn't be just cosmetically checking a box because this can
> make a big accuracy difference -- quadratic elements have a really hard
> time paying off for engineering problems if you don't also have
> quadratic geometry.
>

ExodusII is perhaps the shittiest mesh format in existence. For example, if
we
start reading ExodusII files with high order geometry, that fucks up their
definition
of the topology because now they only report C, the number of cells, and
V+E+F,
the number of vertices and edges and faces. We could get lucky and have
vertices
contiguous, but I cannot find anything in the manual that mandates this. So
we would
overallocate, then reduce down to the right topology, screwing up our
fairly straightforward
code right now.

I would recommend the only non-stupid format I can name right now, the MED
format
from the French CAD guys. Gmsh has switched over to using it since their
own format
sucked worse than ExodusII. That is the only one that it makes sense to
write new code for.

    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

http://www.caam.rice.edu/~mk51/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20170602/bf4cc76a/attachment.html>