Netgen Mesh Generator

Joachim, since the build system is broken (se my bug report) i simply thought i had it turned off with --disable-parallel (but that only enables it with the current configure script). This caused me quite a bit of confusion.

Philippose, it lags alot even for the simplest geometry just as much as a very dense mesh. The GMA card has full support for OpenGL 2.0, but of course, it can still be a bug. If you know of any less common opengl extension used in netgen, i'd appreciate it if you could tell me so i can locate it.


Now what I would like to concentrate my time as a developer on; making some more structure of the core of netgen.
I'm mostly interested in the core of netgen, using it's meshing functionality in adaptive problems. Nglib is much to limited for my needs.

I believe the build process should construct a library
netgen_core (csg, meshing, geom2d, stlgeom and gprim,linalg,general (these last three might be able to be it's own library?))
netgen_occ
netgen_interface
netgen_visualization
and the main executeable
netgen
which dynamically links to these.

In Debian and Ubuntu the current package has compiled static and shared libraries out of csg, meshing, geom2d, stlgeom and so on, but this is not a meaningfull operation.
The cross dependencies between these requires you to link all of them in your application, as described in my setup above. In fact, for the static libs you should never have cross dependencies as the only choice it so unpack and repack the libraries to avoid these, or use compiler specific hacks such as --start-group --end-group in gcc.

The build system should also give an option to build the core alone, so it will be useable on computers without the GUI's many dependencies (i.e. any cluster).

I wrote a Apache Ant build script that takes care of these issues, making compilation a much smoother process. It is also some 30% faster at compiling this project, supports out of tree builds, requires no configure step, is all contained in a single file (< 200 lines of code compare to >0.5MiB of configure scripts) without any need for any makefiles or configure scripts, better descriptions for the modules, more options, same build script for every platform, support for many more compilers and written in a sane format as opposed to m4. It doesn't conflict with autotools so it there is no need to replace something, just adding a single file to make the build so very much easier. I'll be posted this script in a feature request to keep it more structured.

The documentation is also very lacking for these modules in libsrc/. Since many of my friends here at the university will probably end up using this code for mesh generation, I plan on writing a complete doxygen documentation over all of these.

The code is also shock full of ifdef's. I have no idea which ones i should be using or not. Some are not even meaningfull as they brake the source if defined (or vice verse).
Some of these are; _INCLUDE_MORE, CHECK_Array_RANGE, PARALLELGL, ABC, abc,NONE, none, DEVELOPE, SMALLLIB, ACIS, OPENGL
I'd like to sort them out, and remove them if appropriate as they only cause confusion at best. I mean.. none? abc? What are those supposed to mean? Are they defined somewhere or not? I dont know and tracking it down for other developers are a big workload. OPENGL makes you think that the OPENGL support is actually optional, but it's as far as i can tell not (will only break stuff if you leave it undefined). ACIS, why do this need to be an option? Is there any harm using it other than a few kilobytes of more code? The rest i have no clue about, and i'm guessing it's leftover from old code.

The headerfiles are also quite messy. Defining the namespace outside of the headers is unheard of. Anyone who wants to use the code will look at the header and it should contain the correct namespace (as the functions without the namespace prefix simply doens't exist). I can't tell why you have chosen this approach for many of the header files. It simply doesn't have any good effect. Some files includes headers through
../include/..., mixing "" and <> (i've found "file.hpp" within each project and <> for system headers to be a good split),

Can i get a branch in the SVN to push these changes into? I dont want to sit down and hack away for so long without beeing able to push the changes into a repo, but of course I understand that you don't want to hand out write access to anyone. Please speak openly what you think is the best solution. I do no take any offence if you don't trust me with write access (i wouldn't, that would be horrible project management!)
Is it possible to grant me write access to only a certain branch? I believe that would be optimal. I plan on working very actively; since i need the meshing functionality in my PhD position i plan on working fulltime or parttime on this until i'm satisfied with the build setup, documentation and general ease of use for researchers as me.