Re: [FEniCS] Replacing mesh geometry with a Function

Fri, 14 Mar 2014 09:53:02 -0700 



On Fri, 14 Mar, 2014 at 4:38 PM, Martin Sandve Alnæs 
<[email protected]> wrote:

There's a lot of interrelated issues here, I've tried to summarise 
some of the most important ones.



Representing the coordinate function as a Coefficient is really 
convenient in UFL. I've been doing some work on extending the 
symbolic geometry representation in UFL. I'll have to get back to you 
on the details of what I've done there.



I think that's fine.


Representing the coordinate function as a Function makes the form 
compiler pipeline simpler and it's probably important for e.g. the 
performance of isoparametric elements in tabulate_tensor that we can 
reuse the element tables for x/J and u/grad(u). This is partially 
implemented now in uflacs (not quite usable yet).



I don't understand this. The generated code never sees a 
dolfin::Function. Can you tell us what you actually want in the 
generated code? Is it a pointer to the coordinates at nodes, i.e. to 
use in the ufc::tabulate_tensor interface, or do you want a 
ufc::function?



Representing the coordinate function as a Function means we don't 
have to add anything to the assembler, since the coordinate data 
(it's not "vertex coordinates" anymore for degree>1) is passed as 
regular dofs.



It doesn't have to be a dolfin::Function to get this. It just needs to 
be a dolfin::GenericFunction.



Representing the coordinate function as a Function _now_ doesn't mean 
we can't have additional alternative representations _later_.



How would propose doing this?


One possible use case for representing the coordinate function as a 
Function is that it can be the solution of a linear system, e.g. for 
ALE stuff.




Code could be added to handle this. The performance (and memory 
penalty) penalty of using dolfin::Function is not worth it.



Another possible use case that might become possible to do in UFL, is 
shape derivatives, derivative(a, x, dx). (This would requires more 
work though).



I don't understand the logic in "Function contains _some_ 
functionality we _might_ not need for the coordinate function, so 
should duplicate it". That's just more work to achieve less 
functionality.




It means that we can implement performance specialisations for a 
coordinate function because we don't have to support arbitrary (and 
arbitrarily nested) function spaces. 


The actual reason I ask for adding function to meshgeometry now is 
related to how dolfin function spaces transfer between C++ and 
dolfin, losing UFL information in the process. I need to get the 
coordinate function from the mesh somehow to recover that 
information, otherwise the Function(V,i) constructor in python won't 
work. It's _critical_ for the python/C++ integration that we have UFL 
abstractions that match DOLFIN abstractions at the Mesh/Domain level, 
and attaching a Function to MeshGeometry fits perfectly with 
attaching a Coefficient to a Domain, which follows from various UFL 
design issues. My previous couple of emails to the lists about UFL 
Domain design issues have generated approximately zero response, so 
I'm not going into that now.


You need to make it very simple for us to get a response :).


Now my brain needs to shut down for the weekend and I suspect 
everyone needs some time to digest this. I'm expecting lively 
discussions when I get to Cambridge on Monday :-)



Yes, looking forward to it!

Garth


Martin


On 14 March 2014 15:22, Anders Logg <[email protected]> wrote:

On Fri, Mar 14, 2014 at 01:32:00PM +0000, Garth N. Wells wrote:
>
>
> On Fri, 14 Mar, 2014 at 12:21 PM, Martin Sandve Alnæs
> <[email protected]> wrote:
> >I'm already in the process of implementing from the
> >UFL/UFLACS(FFC) side, and getting fundamentals fully in place
> >there will be the leading priority. By using a regular Coefficient
> >for x everything falls into place quite nicely, and I'm doing
> >other symbolic geometry as well that simplifies a lot of things.
>
> I don't think we've discussed how this should be done on the FFC

> side. One extreme is that the map is provided as a Function, and 
FFC

> handles the Jacobian computation, etc using the Function. Other
> cases are that UFC provides an interface function that given a
> parent coordinate returns the map and Jacobian at that point, or

> ufc::cell stores 'higher-order node' coordinates that can be used 
to

> construct a polynomial map in the generated code.
>
> I'm not challenging (yet :)) what's being done - I'd just like to
> know if there is a plan.
>
>
> >Answering Garths comments:
> >Doing boundary cells only will require generating an additional
> >tabulate-tensor implementation as well as other details which will
> >lead this discussion into information overload. We'll have to push
> >that to a later stage, maybe it will be easier after we have
> >better designed support for functions on
> >submeshes/restrictions/whatever we call them.
>
> I think it should be considered now since it will affect the choice
> of data structure/implementation, e.g. it immediately discounts
> using dolfin::Function without major changes to Function.
>
>
> >Doing non-polynomial mappings would basically involve introducing
> >callable functions to UFL, which can be useful in other contexts
> >as well. Getting the framework in place for defining x as a
> >Coefficient in UFL and a Function in DOLFIN will be the first step
> >(which is already well underway). By later introducing the "space
> >of functions that can be evaluated in quadrature points"
> >(including derivatives) should then sort out the arbitrary
> >mappings you want as a side effect.
>
> >So I say getting in place coordinates represented by any vector
> >valued finite element function is a pretty good first step.
>
>
> In terms of implementation I agree, in terms of deciding how we
> start to go about now is the time to think forward. Deliberating
> implicit in the two cases that I presented is that they both
> discount using dolfin::Function.
>
> >
> >Answering Anders comments:
> >I think the right place to get the coordinate function from is the
> >MeshGeometry.
> >
> >It should be accessible from the Mesh, because the UFL abstraction
> >is   SpatialCoordinate(domain)
> >  Jacobian(domain)
> >  etc.
> >and ufl.Domain carries the dolfin.Mesh as domain.data().
> >
> >So if we can add a member
> >
> >  shared_ptr<Function> MeshGeometry::coordinate_function()
> >
> >that returns nullptr for meshes without a coordinate function set,
> >I think that's enough for now and I can try to get the basics
> >working.
>
>

> I don't get why we would want a dolfin::Function with all the 
extras

> that come with it. For the isoparametric case, we just need need an
> interface that supplies the coordinates of 'higher-order' points in
> addition to the vertex coordinates. We could also associate a
> dolfin::FiniteElement with mesh geometry to provide and complete
> definition of the coordinate field.

What functionality does Function have that we don't want for a
CoordinateFunction?

- Perhaps the possibility to extract subfunctions?

- What about dofmap? Would it be enough with a fixed scheme (for
  ordering the coordinate values) or will we at some point want to
  reorder the list of coordinates?


- When I think of it now, the biggest difference is that we don't 
need

  to store the values in a GenericVector since I don't see a need for
  sending that data to a linear solver (ever).

So in conclusion, perhaps we will need to implement a new class
CoordinateFunction which implements the GenericFunction interface but
is otherwise different from Function.

--
Anders




_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics






















					Reply via email to