I don't think we should go for #include <dune/uggrid/...> as the uggrid code currently does not at all bahve like dune code. I think it is not problem, but then it should also be OK to keep the includes differently.
Perhaps #include <ug/...> would be best, e.g. #include <ug/low/heaps.h>.
I think I'd prefer #include <dune/uggrid/low/heaps.h>. Even if the code currently does not behave like Dune code, we want dune-uggrid to become more Dune-like. Then, if we touch the headers at all, why not go all the way? What would be the advantage of a compromise like #include <ug/low/heaps.h>?
I think I'd prefer #include <dune/uggrid/low/heaps.h>. Even if the code currently does not behave like Dune code, we want dune-uggrid to become more Dune-like. Then, if we touch the headers at all, why not go all the way? What would be the advantage of a compromise like #include <ug/low/heaps.h>?
I think the ideal solution would be to clean the code sufficiently up
to completely integrate it into dune-grid. One option would be to move
parts, once they work sufficiently well and then have them in the dune
namespace and directory. But then it would be under dune/grid and not
dune/uggrid...
Christian, are you serious? UG has a long way to go to be ready for Dune-grid; both in terms of its code and of politics.
I am with Oliver regarding the includes.
I propose a new structure, moving many files below dune/uggrid. I tried to reduce the number of files with only three files or less and to make the short folder names more telling. Hopefully, I and other will find it easier to navigate through the new structure.
As I don't understand the stuff below parallel, it mainly remains untouched (what does ddd mean?).