#537 Use new local indices in dune-localfunctions
Metadata
| Property | Value |
|---|---|
| Reported by | Carsten Gräser (graeser@math.fu-berlin.de) |
| Reported at | Apr 7, 2009 23:01 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Sven Marnach (sven@pantoffel-wg.de) |
| Last edited at | Jun 19, 2009 10:00 |
| Closed by | Sven Marnach (sven@pantoffel-wg.de) |
| Closed at | Jun 19, 2009 10:00 |
| Closed in version | Unknown |
| Resolution | Fixed |
| Comment |
Description
The LocalKeys in dune-localfunctions should use the new local indices.
Activity
I propose the changes to LocalKey as attached. Notice that the automatic translation old->new number requires dune2generic in dune-grid.
Attachments
I don't really like Carstens patch -- main reason is that subentity() for the old number and subEntity() for the new number will probably lead to confusion.
I can think of two alternatives:
-
Keep LocalKey as it is, but rename the LocalCoefficients::localKey() method to something else. The localKey() method would return a LocalKey with the old subentity number while the new method would return a LocalKey with the new subentity number. However, I can't think of a good name for the new method.
-
Make a clean cut -- branch dune-localfunctions-1.2 now and just change the numbering on the trunk (similiar for dune-pdelab. This is not supposed to be a real release, but just to tag the version which works with dune-1.2). Since dune-localfunctions and dune-pdelab didn't have any releases yet, this can still be done, I believe.
Personally, I prefer the clean cut in this case.
-
I can't see the problem with the renaming. Since there is no dune-localfunction release it should not confuse normal users. With a release the old methods are gone.
In my opinion the problem is that as long as there are no new numbers in shapefunctions you can not really (application-)test the new numbers also for the grids. But if the old ones are replaced by the new ones you (read: developers) will have to completely switch to the new methods in dune-grid since mixing both is so dangerous.
An the fact that subentity doesn't follow the usual naming and it would anyway be nice to rename it luckily provides the renaming possibility.
But if the above doesn't scare anybody I'd prefer 2) over 1).
-
Relayed from the mailing list:
Hi,
I would certainly like to have a branch in dune-localfunctions that works with dune1.2 before any changes are made.
Why not branching a dune-localfunctions/2009-04 ?
This is not a release, it just states that this worked in 04/2009. I would further suggest to go to such a naming scheme for all Dune modules then when you download 20XX/YY you know it works together.
-- Peter
-
I just talked with Peter and Sven about branching something off dune-localfunction and dune-pdelab which is compatible with dune-1.2, since this is needed for the lectures in Heidelberg. I'm going to branch 1.2snapshot soon (the version should make clear it is compatible with dune-1.2 but not a release).
That does not mean anything about which course we take regarding the LocalKeys issue, of course.
Sven Marnach (sven@pantoffel-wg.de) commented on the issue:
There are some problems with the patch introduced by commit 103. For example in the case of RT0 elements, also the definition of the global basis functions relies on the local indices of the edges. The class RT02DLocalFiniteElementMap assumes that the shape function associated with edge i has index i. In the current version, this does not hold anymore. (The current version works nevertheless since RT02DLocalFiniteElementMap still uses the deprecated numberInSelf() method.) There is a similiar issue with pk2d.
I will try to fix this on Monday. The changes should be done in pdelab and localfunctions simultaneously.
I can't see the problem in dune-localfunctions. It now uses the correct new local indices.
If you want to use dune-localfunctions in applications (in this case dune-pdelab) you can (1) adapt you app, (2) use dune2generic/generic2dune, (3) use the snapshot branch of dune-localfunctions. As I understood Jö's and Peter's comments they prefer solution (3) for pdelab.
-
For some shapefunctions, it is better to adapt the LocalBasis class instead of (or in addition to) the LocalCoefficients class. For example, if you have degrees of freedom in the vertices, you want shape function #0 to correspond to vertex #0, and both correspond to vertex #0. Of course, you can always introduce a renumbering, but that will make debugging much more complicated.
On the other hand, there are local elements (Pk2D I believe) which do the numbering of their shapefunctions and dofs based of geometric position withing the reference element, in that case modifying LocalCoefficients is correct.
The problem with dune-pdelab is that its LocalFiniteElementMap classes (one for each LocalFiniteElement from dune-localfunctions) need a-priory knowledge about the numbering and position of the dofs. Well, for most LocalFiniteElements its the same, but if you have for example several dofs at different points of an edge you need some kind of twist to ensure that corresponding dofs from neighboring elements end up at the same global position.
If I read Svens comment about RT0 correctly, "adapting dune-pdelab" would mean keeping the old subentity numbering in RT0LocalFiniteElementMap because dune-localfunctions RT0LocalFiniteElement is still using the old subentity numbering.
OK, you don't want the old subentity numbering - you just want to reorder the local basis functions such that the (new) subentity numbers associated to them are in an order which is nicely suited for you app (e.g. pdelab).
@Sven: If you also reorder the pk2d functions please be sure to also reorder the refinedp1 functions since they use Pk2DLocalCoefficients !
-
Sven Marnach (sven@pantoffel-wg.de) commented on the issue:
No, I do not want to reorder the local basis functions in an order which is nicely suited for pdelab, I just want to reorder them in the only intuitive way (following the principle of least surprise). Each local basis function of the RT0 elements is associated with an edge, and local basis function #i should belong to edge #i, as Jö pointed out. Otherwise, the LocalCoefficients class would have to return local keys like LocalKey(2-i,1,0), where "2-i" is actually the mapping from old to new numbering without explicitly saying so. Additionally, and even more importantly, any application which uses the RT0 elements would have to do this remapping of indices as well (when calling the constructor, which has to be told the signs of the local basis functions). I don't think it is a matter of taste -- there is only one reasonable choice for the order of RT0 basis functions.
I didn't think enough about pk2d yet, but there might be a similar issue.
@Carsten: If I really reorder pk2d, I will also take care of refinedp1. But please, have a close and critical look at my commits. We have to be really careful!
