← Back to team overview

ffc team mailing list archive

Re: iso-parametric mappings

 

Actually, the reason I am even considering this, is that I have a project that requires 2nd order polynomial mappings for triangles with a face on the boundary. It is actually critical to the stability and accuracy of the method because there is an interaction between the velocity field on the boundary and the computation of curvature (because of a semi-implicit time discretization). In my method, 2nd order polynomials are used for the velocity field, so I NEED a 2nd order piecewise parameterization of the boundary.

Furthermore, the problem is a two-phase free-boundary problem. I.e. the geometry is NOT known a priori. So, I am not sure how one would use the iso-geometric stuff; it may be overkill or problematic. Any thoughts? Also, I have already implemented my problem in MATLAB and it works quite well. Of course, I could just not worry about it, but I was trying to think ahead. And I wouldn't mind having my problem implemented in DOLFIN. And, no, I don't want to develop another method that would fit with dolfin. I think that is the wrong attitude. :)

I think for free boundary problems (with smooth boundaries), assuming a polynomial curve is not bad at all. Anyway, this could be an option in the code. I would envision FFC working like this:

1. You specify whether the incoming meshes will be straight, polynomial curved, or iso-geometric curved.

2. You then run the compiler.

3. When you use it in a code, there will be check 'somewhere' to check for compatibility of the mesh with the finite element implementation. A message will be output indicating any discrepancy.

- Shawn

On Wed, 13 Aug 2008, Matthew Knepley wrote:

Before spending time implementing isoparametric stuff, I would at least look
at the NURB elements from Tom Hughes' group. They actually capture the
geometry (whereas polynomials rarely to a good job), although they are
currently computationally expensive. If I wer ecoding something new, this is
what I would do.

 Matt

On Wed, Aug 13, 2008 at 3:36 PM, Shawn Walker <walker@xxxxxxxxxxxxxxx> wrote:
ok, but I have a couple other questions/comments?

1. Has there been a decision on what kinds of curved meshes will be
allowed?  And what would the mesh format be?  This seems to be the first
decision.  It would seem natural to only allow polynomial based maps
(for now), i.e. a quadratic triangle would require a 2nd order polynomial
mapping (instead of a 1st order map).  You could also have higher degrees
if you wanted.  I think the 'curved' mesh feature could be implemented
first.  And the assembly could just IGNORE the extra curvy info for each
triangle (for now).

2. For the assembly, I think it is still possible to compute the matrices
exactly in SOME cases.  For example, a mass matrix could be computed
exactly, as well as \int_{\Omega} q div(u), because the det(J) would
cancel the 1/det(J) part of the inverse of the gradient map.  Of course,
the stiffness matrix cannot be computed exactly.  For this, I think
quadrature is the only way.  Or one could maybe take advantage of doing an
asymptotic expansion (taylor series) of the algebraic expression and
compute that using enough terms based on the desired number of digits of
accuracy.  I don't know.

3. One could add another boolean property to each triangle called:

Is_Straight

This could give a switch between computing exactly, and using quadrature.
Most meshes will have straight interior elements; you don't really need
them inside so much.  only the triangles with a face on the boundary
would be curved.  So this would help prevent possible performance hit of
doing high order quadrature.

4. How hard would it be to understand UFC~FFC for someone who knows just a
little Python and a decent amount of C++?

If there is anything written up on how FENICS wants to do this (i.e.
desired mesh format, etc...) please tell me.

- Shawn

On Wed, 13 Aug 2008, Anders Logg wrote:

On Wed, Aug 13, 2008 at 11:56:11AM -0400, Shawn Walker wrote:
Hello.  I know this isn't very critical on the list of things to do, but
is there any document somewhere saying how they propose to implement
curved meshes with the UFC/FFC code?

- Shawn

No, I guess they have no idea how to do this. ;-)

It would require an extension of UFC and it would require someone
willing to spend the time on making it work. It's not on the top of my
TODO list, but anyone wishing to investigate is welcome.

--
Anders

_______________________________________________
FFC-dev mailing list
FFC-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/ffc-dev




--
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



Follow ups

References