Matthew Knepley <[email protected]> writes: > On Fri, Jun 2, 2017 at 8:38 PM, Jed Brown <[email protected]> wrote: > >> Matthew Knepley <[email protected]> writes: >> >> > On Fri, Jun 2, 2017 at 7:55 PM, Jed Brown <[email protected]> wrote: >> > >> >> Matthew Knepley <[email protected]> writes: >> >> >> >> > On Fri, Jun 2, 2017 at 5:04 PM, Alberto Paganini < >> >> > [email protected]> 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.
signature.asc
Description: PGP signature
