#698 Clean up the dune/localfunctions/generic directory
Metadata
| Property | Value |
|---|---|
| Reported by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Reported at | Dec 20, 2009 18:26 |
| Type | Bug Report |
| Version | Git (pre2.4) [autotools] |
| Operating System | Unspecified / All |
| Last edited by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Last edited at | Mar 12, 2010 06:28 |
| Closed by | Christian Engwer (christi@conan.iwr.uni-heidelberg.de) |
| Closed at | Mar 12, 2010 06:28 |
| Closed in version | 2.0 |
| Resolution | Fixed |
| Comment |
Description
The implementations in the generic sub directory have to be merged with the other implementations.
Activity
- 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.
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.
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?
- helper stuff should stay in seperate directory with whatever name seems suitable.
- quadrature should go to dune-geometry which does not exist
- 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.
