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

[Blaise A Bourdin]

Hi,
Do you have a link for the MED format description and implementation?
The problem with FE file format is that unless they are supported by mesh generators and visualization software, they are just nice toys...

Blaise


> On Jun 2, 2017, at 11:21 PM, Vijay S. Mahadevan <vijay.m at gmail.com> wrote:
> 
>>> 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/

-- 
Department of Mathematics and Center for Computation & Technology
Louisiana State University, Baton Rouge, LA 70803, USA
Tel. +1 (225) 578 1612, Fax  +1 (225) 578 4276 http://www.math.lsu.edu/~bourdin