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, [email protected] 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, [email protected] 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 _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
