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

[Matthew Knepley]

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

> Matthew Knepley <knepley at gmail.com> writes:
>
> > 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.
>
> NASTRAN, ABAQUS, and the like are a pleasure by comparison?
>

It seems there is room at the top of the mountain of shit.


> > 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.
>
> Can Cubit produce MED or be converted to MED?  I haven't used it, but it
> sounds like there is some mesh generation software available for it.
>

Gmsh can convert anything it can read to MED I believe.

   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/6bdd5751/attachment.html>