search

libMesh / libmesh

libMesh github repository
http://libmesh.github.io
GNU Lesser General Public License v2.1
649 stars 285 forks source link

Higher order curved mesh supported #727

Open lw4992 opened 8 years ago

lw4992 commented 8 years ago

Right now, libmesh supported p2 curved mesh. Is it possible to add higher order mesh, like p3, p4, p5 from gmsh..

The main steps as follows:

Any other suggestion?

jwpeterson commented 8 years ago

On Nov 17, 2015, at 9:07 AM, LIU Wei notifications@github.com wrote:

Right now, libmesh supported p2 curved mesh. Is it possible to add higher order mesh, like p3, p4, p5 from gmsh..

The main steps as follows:

Modifier mesh/gmesh_IO.C. In GmshIO::ElementMaps GmshIO::build_element_maps(), define new element type and node order.

Add new TRI15 inhert from TRI, for example, in geom directory.

Modify FE<2,LAGRANGE>::shape in fe/ fe_lagrange_shape_XD.C to compute the new element type's JxW and normals

I think JxW and normals, etc. will simply fall through once the shape functions, gradients, and second derivatives are in place. Any other suggestion?

I think you've touched on the main requirements, another important one is to compute the embedding matrix so that we can refine/coarsen the new element. There will also need to be some work put into supporting the output of such elements in the various formats we have for visualization purposes...

BTW is Tri15 really the next thing after Tri6, or is there a Tri10?

roystgnr commented 8 years ago

On Tue, 17 Nov 2015, LIU Wei wrote:

Right now, libmesh supported p2 curved mesh. Is it possible to add higher order mesh, like p3, p4, p5 from gmsh..

"Anything's possible" - but it might be quite difficult to do properly. Your suggestion would only work for Lagrange elements, for example, since the other FE types would each have to have TRI10, TRI15 etc. support added manually. There's dozens of other bits of the code that would need those entries added to the TRI3/TRI6 case of switch statements, too.

However, I don't want to discourage you. A Lagrange-only solution for higher order geometry would still be a big step forward over our current status of no solution for cubics and higher.

Any other suggestion?

We could make use of first_order_equivalent_type() in all the switch statements that depend on element type but not order; that way you could add as many new triangle types as you wanted and only have to change a fraction as many files.

Between that and our policy of numbering nodes hierarchically, we could probably get all the other FE types to properly support higher order geometries without much modification. They'd just return n_dofs_on_node==0 for nodes whose number is higher than they recognize.

You know, the more I think about this the better it's sounding. In my head I'd always imagined adding additional basis type options for mapping functions - if we could optionally use hierarchic FE for mapping then p would be limited by nothing more than floating point error.

But we could actually go pretty far with just Lagrange mapping if someone like you was willing to do the tedious work. ;-) Please keep

me in the loop if you have questions or get stuck.

Roy

friedmud commented 8 years ago

Just wanted to toss this in: I would LOVE higher order Lagrange mapped elements! For some of the work I'm doing right now they would be truly awesome.

Unfortunately: that's all I had to add. But I thought some encouragement would still be good ;-)

Derek

On Tue, Nov 17, 2015 at 11:02 AM roystgnr notifications@github.com wrote:

On Tue, 17 Nov 2015, LIU Wei wrote:

Right now, libmesh supported p2 curved mesh. Is it possible to add higher order mesh, like p3, p4, p5 from gmsh..

"Anything's possible" - but it might be quite difficult to do properly. Your suggestion would only work for Lagrange elements, for example, since the other FE types would each have to have TRI10, TRI15 etc. support added manually. There's dozens of other bits of the code that would need those entries added to the TRI3/TRI6 case of switch statements, too.

However, I don't want to discourage you. A Lagrange-only solution for higher order geometry would still be a big step forward over our current status of no solution for cubics and higher.

Any other suggestion?

We could make use of first_order_equivalent_type() in all the switch statements that depend on element type but not order; that way you could add as many new triangle types as you wanted and only have to change a fraction as many files.

Between that and our policy of numbering nodes hierarchically, we could probably get all the other FE types to properly support higher order geometries without much modification. They'd just return n_dofs_on_node==0 for nodes whose number is higher than they recognize.

You know, the more I think about this the better it's sounding. In my head I'd always imagined adding additional basis type options for mapping functions - if we could optionally use hierarchic FE for mapping then p would be limited by nothing more than floating point error.

But we could actually go pretty far with just Lagrange mapping if someone like you was willing to do the tedious work. ;-) Please keep

me in the loop if you have questions or get stuck.

Roy

— Reply to this email directly or view it on GitHub https://github.com/libMesh/libmesh/issues/727#issuecomment-157414104.

roystgnr commented 8 years ago

Is it possible to support cubic and higher elements in any of our vis formats? I'd imagined that people using high-p mapping bases would be stuck with xdr/xda for restarts and decimation for vis, like people using high-p FE bases are now.

(In theory we could support restarts from lower-order-but-h-refined vis files; in practice I'm not writing that code. ;-) )

friedmud commented 8 years ago

No: no viz formats that I know of can handle it. So we'll need to decimate.

Derek On Tue, Nov 17, 2015 at 11:06 AM roystgnr notifications@github.com wrote:

Is it possible to support cubic and higher elements in any of our vis formats? I'd imagined that people using high-p mapping bases would be stuck with xdr/xda for restarts and decimation for vis, like people using high-p FE bases are now.

(In theory we could support restarts from lower-order-but-h-refined vis files; in practice I'm not writing that code. ;-) )

— Reply to this email directly or view it on GitHub https://github.com/libMesh/libmesh/issues/727#issuecomment-157415157.

lw4992 commented 8 years ago

@jwpeterson, as gmsh format, should be TRI3-->TRI6-->TRI9-->TRI10-->TRI12->TRI15