On Fri, Jun 2, 2017 at 9:45 PM, Jed Brown <[email protected]> wrote: > 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? >
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/
