dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Mar 28, 2011 at 12:50:08PM +0100, Garth N. Wells wrote:
>
>
> On 28/03/11 12:11, Anders Logg wrote:
> > On Mon, Mar 28, 2011 at 10:37:10AM +0100, Garth N. Wells wrote:
> >>
> >>
> >> On 25/03/11 12:58, Anders Logg wrote:
> >>> On Fri, Mar 25, 2011 at 10:28:20AM +0000, Garth N. Wells wrote:
> >>>>
> >>>>
> >>>> On 24/03/11 19:10, walker@xxxxxxxxxxxx wrote:
> >>>>> On Thu, March 24, 2011 1:32 pm, Anders Logg wrote:
> >>>>>> On Thu, Mar 24, 2011 at 05:19:03PM +0000, Garth N. Wells wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> On 24/03/11 14:28, walker@xxxxxxxxxxxx wrote:
> >>>>>>>> On Thu, March 24, 2011 8:53 am, Peter Brune wrote:
> >>>>>>>>> Ah, this argument, again.  I continue to disagree.  While you could
> >>>>>>>>> certainly home-roll a FEM code that does this under assumptions like
> >>>>>>>>> constant quadrature order and small meshes,  this is going to fall
> >>>>>>> down
> >>>>>>>>> hard
> >>>>>>>>> as soon as you have varying quadrature degree or type, which we
> >>>>>>> always do.
> >>>>>>>>> This would also keep around way more state than the current assembly
> >>>>>>>>> paradigm allows, not to mention the per-quadrature-point storage
> >>>>>>>>> requirements of a full-blown tensor.
> >>>>>>>>
> >>>>>>>> I don't see why constant quadrature order is so terrible.  Is it
> >>>>>>> really
> >>>>>>>> necessary to have varying quadrature degree?  What do you mean be more
> >>>>>>>> state info?  This is just another locally defined function.  I am a
> >>>>>>> little
> >>>>>>>> unclear about what you are saying.
> >>>>>>>>
> >>>>>>>
> >>>>>>> I don't see what the 'argument' is either. What is it exactly?
> >>>>>>>
> >>>>>>>>> The other problem with this approach is that you severely restrict
> >>>>>>> the
> >>>>>>>>> spaces your coordinates can live in by having some oddly-defined
> >>>>>>> notion of
> >>>>>>>>> "higher-order vertices.  If you have some coefficient that is the
> >>>>>>>>> coordinates instead it's automatic.  I think you definitely should
> >>>>>>>>> recreate
> >>>>>>>>> the jacobian in tabulate_tensor; it's what we do now; it's what we
> >>>>>>> should
> >>>>>>>>> do
> >>>>>>>>> if we don't want to store per-quadrature-point tensors on the DOLFIN
> >>>>>>> side
> >>>>>>>>> when the DOLFIN side doesn't even know about quadrature points.
> >>>>>>>>
> >>>>>>>> I am not proposing having higher order vertices.  I am saying treat
> >>>>>>> the
> >>>>>>>> geometric map like **it has its own finite element space**!  If you
> >>>>>>> want
> >>>>>>>> to have a special map for each bilinear form (so you can have varying
> >>>>>>> quad
> >>>>>>>> degree) then fine.  But keep in mind that once you have a non-linear
> >>>>>>> map
> >>>>>>>> for the geometry, you will (in general) not be able to compute the
> >>>>>>> tensors
> >>>>>>>> exactly.  So you will need to fix the quad degree somehow.
> >>>>>>>>
> >>>>>>>
> >>>>>>> I agree with this. Forgetting forms and PDEs, we should be able able to
> >>>>>>> have a pure geometric representation. Say, for example, that I have a
> >>>>>>> mesh that uses some mapping and I want to know (possibly approximately)
> >>>>>>> its volume. The mesh and cells need to know all the geometry. Also, say
> >>>>>>> I want to know in which cell a point (in the real coordiantes) lies.
> >>>>>>> This is not related to forms.
> >>>>>>
> >>>>>> We've had this argument many times before... The thing that I've
> >>>>>> always found attractive with Peter's approach is that one can
> >>>>>> represent the geometry (the embedding of the mesh) as a field on top of
> >>>>>> a standard mesh (with straight edges). So it doesn't require adding
> >>>>>> tons of new data to the mesh class.
> >>>>>>
> >>>>
> >>>> How would this work for very complicated meshes, e.g. a car, engine,
> >>>> etc? In these cases one doesn't have a straightforward functional
> >>>> description of the geometry, but just points that lie of the boundary or
> >>>> a complex collection of spline.
> >>>
> >>> We would then need a function space that can represent those kinds of
> >>> fields (NURBS). If we add such functionality (to DOLFIN and FFC), we
> >>> could also use the NURBS as basis functions ("isogeometric analysis")
> >>> which seems to be popular these days.
> >>>
> >>
> >> This is missing the point. Complex geometry is given, and not
> >> constructed for convenience by the person performing the analysis. It
> >> can come in many formats. It is necessary to support geometries that are
> >> provided.
> >
> > No one is arguing against that. The discussion is how we should are lotsstore
> > the geometry: either in a special MeshGeometry class or as a Function.
> >
>
> This is an over simplified perspective. We are not discussing whether or
> not to use Function,

I thought we were: either store the complex geometry as a Function or
as part of (an extended) MeshGeometry class.

I don't have any strong objections to doing the latter, but I think it
would be cleaner if we could reuse the Function class and keep
MeshGeometry simple.

I hardly know anything about NURBS (and the like) but my basic
assumption here is that whatever the geometry is, it can be
represented by a mapping from the standard UFC elements. Maybe that's
not the case?

> which since we all agree of a functional
> representation is an implementation detail. The question is what is
> required to represent a broad range of geometries.  Splines (the types
> of interest) are not defined on simplices, so it's not a simple
> questions of straightforward extension of FIAT. To evaluate splines,
> geometric data is required.
>
> (I'm wishing that NURBS were never mentioned ;). There is more out there
> than just NURBS - we need to deal with whatever is available. Part of my
> assertion is that FFC + FIAT cannot possibly support everything.)

Isn't the alternative that UFC supports everything?

> > My point is that if we store it as a Function (which among other
> > things requires adding the corresponding basis functions in FIAT) then
> > we could not only represent the geometry using NURBS, but we could
> > also use them to compute. Another advantage would be that we wouldn't
> > need to extend the MeshGeometry class or create a new MeshGeometry
> > class to handle the new geometry.
> >
>
> How could we construct NURBS on a domain without some geometric data for
> constructing the NURBS? It's like an FE simulation on a domain, but
> without a mesh to define the domain.

Just as we do today: by passing data through the UFC interface. My
belief is this can be done by representing the complex geometry as a
suitable Function so that the data can be passed as a coefficient to
tabulate_tensor. Is that not possible?

--
Anders