What is to be cleaned up before 2.0 - assuming localfunctions is to be included in 2.0.
There is no problem with moving the localfunctions/generic/*localfiniteelements.hh files to
the localfunctions directory - is that what is meant with this task?

- There a several features duplicated in localfunctions and localfunctions/generic, perhaps not literally, but they implement nearly the same stuff.
These have to be merged
- There are quadrature rules which do not belong to dune-localfunctions
- There is a mysterious math directory
- There is a common directory, stuff in there should go to localfunctions/common
- The files in common contain hardly any documentation
- Why are files like dglocalcoefficients.hh in common?
- generic/ uses GMP, but there is not test for GMP

I could continue this list.

As you stated yourself, the idea was to dump the stuff to dune-localfunctions and clean it up afterwards.
If we want to have the implementations in generic in the release, what would be really nice IMHO, these points
need to be sorted out. And this must be done rather quickly, because such major changes can not be merged
after the freeze, sorry for this, but otherwise maintainance will be come a real pain.

- we did not move the quadratures to dune-grid since they are to be moved to a new
module and I do not like to duplicate work
- the math stiff could go to dune-common. And by the way: what is so terribly mysterious
about it?
- the stuff in gneric/common should not be in the general common directory, since this
is common stuff for our construction of local finite elements based on the generic
geometries.
- The documentation in dune-localfunctions is in general not very good (131 Please doc me in
the main directory alone). The documentation of helper classes for the generic construction
is for me not first priority.
- dglocalcoefficients uses the factory construction for finite elements - together with
l2interpolation is one of the few things which could go to the general common directory
- of course there is a test for gmp, you should just look instead of stating stuff. If you wanted
to state that the test is buggy we will have a look at that.
For us the generic stuff is not a show stopper for the 2.0 release - there are much more
important issue with concepts (C0,C1,Ck for example) and with documentation (e.g. a module
structure is totally missing; the only docu being a long class list with over 100 classes
with no structure what so ever). So these issues need to be sorted out first.

It would be nice to have the FEs from generic/ tested in testfem.cc - especially since you provide different interpolations.

This would also reduce (in the short term) the need for more documentation in helper classes since it would be clear which classes are needed by the user.

Regarding the number of 'Please doc me's: almost all regard the standard methods that each FE provides.

As far as I can see CRTP(Barton-Nackman) is still used in the generic/ stuff.

There is still the generic directory. It was stated (by Andreas), that this directory is only temporary and has to be merged with the rest. This is still an open task.

I never stated that. What I did state is that there are a lot of
helper classes which I would not like to put into a common directory.
There is also some stuff which will go into the new dune-geometry
module and I stated that I will not move this before that module is
available.
I do not see a good reason for moving the finiteelement headers to the
localfunctions directory - it is full enough as is.
If somebody comes up with a better name for generic, feel free to change it.
For me this tasks is closed.

No, when you sent me the merged repositories, I asked about the generic subdirectory and you said that this is not a permanent solution, but you wanted to avoid chaos during the merge.

Also the current directory structure completely contradicts the decisions made in Berlin.

Please be a bit more constructive! Which decision to you mean? How would
you like the directory structure to be?
I think I wrote my problems with merging down rather clearly and all I am
getting from you is: "you promised to do better" - not helpful.
Do you want me to repeat my problems?
1) helper stuff should stay in seperate directory with whatever name seems
suitable.
2) quadrature should go to dune-geometry which does not exist
3) math should go to dune-common but only after a discussion on how to handle
higher precision field type - a discussion for which we have no time and
no urgent need at the moment. So think of the stuff in math as helpers

Since we apparently in Berlin to have one huge directory (54 file now) I will
add the corresponding 10 files for the new finiteelements. But I do not quite
understand how?
FS673 states that there should be one header and a corresponding directory
without the dot hh. Now there is a
raviartthomas directory
but no raviartthomas.hh file. What should be in that file? Should I also
move our raviartthomas stuff to that directory. How should I call the files
or should they be in a seperate directory and if yes what would be a godd name. What should be in the raviartthomas.hh file? Please give some
constructive hints how you would like to have it...

Just closing the task is not very constructive either.
You might have talked with Oliver, who is working on the directory cleanup for the rest of the code.
* All implementations should be available under dune/localfunctions/foo.hh.
* Where are the quadrature rules needed atm?
* How about moving the math stuff to localfunctions/common/math for the beginning.
All in all it should be structure where a user can easily find the different implementations, like in dune/grid the different headers for the different grids.
That some headers are missing atm is an issue where Oliver is working on.

> Where are the quadrature rules needed atm?
Why is it not enough for you that I tell you that we need them?
They are needed in the L2localInterpolation and in the interpolation
for the RaviartThomas stuff. The lobatto points are needed in the
Lobattopoint based lagrange space.
> How about moving the math stuff to localfunctions/common/math
> for the beginning.
If you think that would help to understand what is used where...

I will just wait for Oliver to complete the restructuring of the directories
and then see if I can see clearer how to merge this stuff.

I'd rather not have the 'generic' directory in a release. That name is meaningful only to the people who wrote the code, and that's a small percentage of the overall user base.

IMHO, the quadrature rules should go to dune-grid. Yes, that is not the perfect place, but scattering them all over the place is even worse.

I don't see why the generic/common stuff cannot go into the common directory. If it is only used by the stuff now in 'generic'---so what?

I am working on the restructuring, but I have a few other things on my mind as well. It may take another few days.

Everything except for quadratures has been moved down.

Quadratures will be moved to dune-grid soon. Please bear in mind that this means dune-localfunctions will have to depend on dune-grid (at the very least suggest it).

dune-localfunctions depends on dune-grid anyhow currently for similar stuff.

quadratures now moved to dune-grid

Great, that this issue was sorted out before the freeze/branch.