[petsc-dev] higher-order coordiate fields in DMPlex
Vijay S. Mahadevan
vijay.m at gmail.com
Fri Jun 2 23:21:02 CDT 2017
>> 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.
Cubit does not support MED out of the box (as of 15.0). They may have
a plugin, not sure.
> Gmsh can convert anything it can read to MED I believe.
I have not used meshes in MED format but I think it doesn't
handle/represent solid geometries.
GMsh uses OpenCascade primarily under the hood. AFAIK, they've been
using it for a while. So they should be able to load step/brep/iges
format through the OCC interface. But if we are talking about meshes,
then they may have a MED format writer that preserves second-order
accuracy in meshes. In which case, their native "msh" format may
support this too.
Vijay
On Fri, Jun 2, 2017 at 9:56 PM, Matthew Knepley <knepley at gmail.com> wrote:
> 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/
More information about the petsc-dev
mailing list