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

[Jed Brown]

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?

> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20170603/0261a0cb/attachment.sig>