#538 dependency dune-grid <-> dune-localfunctions

Actually, the monom shape functions (and some other) need the quadratures for interpolation -- but you are propably right about moving the quadratures elsewhere.

I would like to add

For debugging dune-localfunctions Suggests: dune-grid because it needs VirtualRefinement. VirtualRefinement cannot currently be seperated from dune-grid because for refining Hypercubes it uses SGrid.

I also think that the reference elements should be moved to dune-common. We just had an other module where the reference element was needed, but all the other grid stuff was superfluous.

Regarding the quadrature rule, I'm not sure where to put them. dune-grid doesn't need them, localfunctions does, but on the other hand, they might be needed by other modules as well, but without localfunctions!?

The tests I wrote use quadrature rules to get sets of test points. You don't really need those rules but only a simple factory for lists of points. I was going to write such a factory one of these days, but didn't get around to it yet.

Off-hand I'd prefer not to have any dependency between dune-grid and dune-localfunctions, but I have to think about the consequences a bit.

There is another issue. I implemented mixed finite elements (RT0) and I recently thought about Hermite elements and C1 elements (Argyris, Bell triangle). In all those cases you have to apply a transformation to the local basis functions that depends on the geometry (Piola Transformation in RT). So far I put this transformation into the local operator and it works. But it also shows up in other places e.g. evaluation of a function in the VTKWriter and you have to program it twice. It would be much better to have a well-defined place for these transformations.

If this place would be dune-localfunctions, then a dependence to dune-grid is natural.

If dune-grid depends on dune-localfunctions then the reference element and the quadratures have to move either to dune-common or dune-localfunctions - they could both be moved to localfunctions or both to dune-common or reference elements to common and quadratures to localfunctions...

My comment would mean that dune-localfunction would need the Geometry (!) not only a reference element. You really need something like jacobian() and integrationElement(). And one would not like to move Geometries out out of dune-grid?

An alternative would be to move the reference element to dune-common and to introduce a GeometryInterface to dune-common - which is basically an interface for mappings from the reference element to R^w with jacobian, jaconianInverseTranspose etc. A grid geometry interface would just be a special implementation of the general geometry interface and the piola transform could be easily implemented for general mappings from the reference element to R^w.

We just had a discussion with Christian and decided that we would like to move GenericReferenceElement to dune-common. For compatibility there would still be a deprecated file in dune-grid/grid/common. This would mean that we also move most of the files from grid/genericgeometry to dune-common - with the exception of the Geometry implementation class which belongs in dune-grid. As I suggested above, I would also add a ReferenceMapping interface class, having a similar interface as the Geometry class in dune-grid. If nobody objects I would do this in a week.

Off-hand I find this fairly invasive. Could you please explain the rationale for this move a bit?

As stated in the original post:

dune-localfunction has to depend on the Referenceelements and needs a interface for geometries (Piola transformation).
to implement isoparametric grids, it would be nice to use dune-localfunctions (e.g. higher order Lagrange basis functions) This means there is at the moment a circular dependency between dune-grid and dune-localfunctions.

So the idea was to move the ReferenceElements to dune-common since they are needed in both dune-grid and dune-localfunctions. For most implementations this means that one include has to be changed and the transition is smooth if we keep the header file in dune-grid. For implementations using basic stuff from grid/genericgeometries (e.g. CornerMappings...) the transition is more invasive - but since GenericReferneceElement needs CordnerMapping for example these files would also have to be moved to dune-common.

It was the first point I was curious about, because I have not much experience implementing non-affine finite elements.

The second point doesn't convince me. Yes it would be nice to be able to use existing shape function implementations for isoparametric grids. However, you really only need a few low order Lagrange functions for this. Rather than compromise the design and have dune-disc depend on dune-shapefunctions I'd introduce a copy of the necessary Lagrange functions in dune-grid.

I can't see how this does resolve the dependency problem. For hermite elements you do not only need information about the reference element, but the mapping of the element to the reference element, i.e. the element geometry.

On the other hand the use of dune-localfunctions for of an isoparametric grid is imho an implementation and not an interface detail. So one could just add the dependency on dune-grid and dune-localfunctions to a seperate 'dune-fancy-isoparametric-grid' module.

As stated in the original post:

dune-localfunction has to depend on the Referenceelements and needs a interface for geometries (Piola transformation).
to implement isoparametric grids, it would be nice to use dune-localfunctions (e.g. higher order Lagrange basis functions) This means there is at the moment a circular dependency between dune-grid and dune-localfunctions.

So the idea was to move the ReferenceElements to dune-common since they are needed in both dune-grid and dune-localfunctions. For most implementations this means that one include has to be changed and the transition is smooth if we keep the header file in dune-grid. For implementations using basic stuff from grid/genericgeometries (e.g. CornerMappings...) the transition is more invasive - but since GenericReferneceElement needs CordnerMapping for example these files would also have to be moved to dune-common.

At the point where the shape functions are transformed to a given entity you need the geometry implementation - to implement in dune-localfunctions how to do this you just need the geometry interface (or at least some part of it). Reimplementing shape functions in two places is not a good idea imo. Isoparametric elements are also interesting in 3./4. order, Lobattopoint based basis functions are more stable that Lagrange - so prehaps a good idea and so on...

I would still like to see where the big invasion is. Why would dune-disc depend on dune-localfunction? dune-grid would suggest dune-localfunction bit not need it. The linear mappings made available by the generic geometries would still be available. All functionality would remain the same as now without needing dune-localfunction - just the location is changed...

Regarding so of the comments:

a circular dependency is no problem, as dunecontrol can handle them. On the other hand it is a bit strange, to have different modules for something that does not work without the other.
I concider the higher order mapping a weaker argument
the geometric stuff, reference elements, geometries is needed at some very different places and making all these places depend on dunegrid is a rather big requirement. Thus this functionality should be moved to a more basic module, either dune-common or a dune-geometry module.
I don't see the problems for dune-disc, first of all dune-grid does not need dune-localfunctions yet, second I would never make this a dependency, but rather a suggestion, if localfunctions is not available you can't use higher order mappings, so what?!

my 0.05 € Christian

Concerning dune-disc: I just realized that I mistyped. What I meant was 'dune-grid'. And I think Carsten is correct. If you want to implement a grid that uses fancy isoparametric elements put it into a separate module and have that module depend on dune-localfunctions.

Concerning 3) I don't think depending on dune-grid is a big requirement. And putting more and more stuff into dune-common amounts to gradually going back to a monolithic design.

Just some stats:

dune-common: 40k lines dune-grid: 94k lines genericgeometries/referencelements: 5k lines

I don't think that moving moving 5k lines from grid to common will bring us back to a monolithic design.

All I said was: one step towards a monolithic design. Not all the way.

And if you really do need the reference elements, then why not depend on dune-grid? According to your stats that's only 94kloc. We could make the dependency a suggestion.

Finally, could somebody please explain to me what you need the reference elements in dune-localfunctions for? I see the need for the geometry interface, but the reference elements?

I'd rather not decide this issue without an discussion at the next meeting.

We have implemented generic shape function sets (for lagrange and Raviart-Thomas and so on) using the recursive definition of the reference elements, i.e., the Point, Pyramid and Prism classes. Information concerning the subentities on which to place the dofs (there types and embeddings) was also heavily needed. The local keys used in dune-localfunction only make sense in combination with the reference element construction. All of this can be obtained using the classes in grid/genericgeometry (without using the GenericReferenceElement in grid/common). So what we would like to have in dune-common is a GeometryInterface class and the template magic available in the genericgeometry folder. I do not really see why any of this stuff is grid related; I think they are more related to common (where for example the geometry type is also located). In fact dune-localfunctions could be quite interesting even for people not interested in using the dune-grid interface and there is no reason why this should not be possible without also having to use the much bigger dune-grid module. I actually like that dune-istl does not depend on dune-grid but can be used seperatly. I think having modules depend on dune-common but as little as possible on each other is a good step in a non-monolithic design.

A more concrete example: Edge elements have DOFs in the edges and each DOF has an assosiated orientation along its edge (these directions must match in the global basis function). When implementing the shape function, for each edge with local index i I need to know the local indices of the vertices at its endpoints to calculate the orientation. I also need the center of and a tangential vector along each edge (which I can calculate from the positions of the endpoints of the edge). This is all information which I can get from the reference elements.

Alternatively I have to duplicate that information in the code of the edge elements. But I would rather avoid that, since then the edge elements depend on the particular numbering of the subentities in the reference element. A lot of poeple will have a major headache in the near future, because they hardcoded that information.

Hi Andreas, Hi Jö! Thank you for your explanations. I start to understand the problem now.

On the last meeting it was decided, that we create a new module dune-geometry. This will help us avoid a dependency between localfunctions and grid. Until then it might be unavoidable, but we can live with it.

Status changed to closed

mentioned in issue #604 (closed)

Property	Value
Reported by	Andreas Dedner (A.S.Dedner@warwick.ac.uk)
Reported at	Apr 8, 2009 11:06
Type	Feature Request
Version	Git (pre2.4) [autotools]
Operating System	Unspecified / All
Last edited by	Christian Engwer (christi@conan.iwr.uni-heidelberg.de)
Last edited at	Dec 1, 2009 09:28
Closed by	Christian Engwer (christi@conan.iwr.uni-heidelberg.de)
Closed at	Dec 1, 2009 09:28
Closed in version	Unknown
Resolution	Deferred
Comment	Discussion settled, issue is now covered by #604 (closed)

#538 dependency dune-grid <-> dune-localfunctions

Metadata

Description

Designs

Child items ...

Activity