I would like to join the developing work on 3D version. I got some experience in 2D finite element calculation, but no experience in 3D. As I have encountered several problems that need a 3D solver. Now, I will continue to work on the Tetgen program, make it more easy to use and more robust.Well, it looks like we could be approaching a critical mass that is big enough to kick off a 3D code. Here are some thoughts about making a 3D version.
Robin has already noted Si Hang's "Tetgen" program. This would make a good backbone for a 3D program. As Robin has also noted, planning is key. The internal structure of the current 2D version wasn't incredibly well planned, and that has made it hard to make things modular enough to be developed by a team. Opportunities for an object-oriented structure weren't really exploited very well, and an opportunity to make a code that would easily be modified to attack other similar problems (e.g. thermal, elastic, electrostatic) was lost. Any 3D effort would need to be structured in such a way so that multiple programmers could be working on it without everyone having to understand virtually everything about the way that the code works to be able to make a valuable contribution.
We could use an existing front-end for a 3D solver, but the pre- and post-processors are what really make or break the functionality of the program. For example, like 4/5 of the source code of femm is devoted to the user interface--the technical things that the program does aren't really incredibly novel. For a 3D code, it would probably be better in the long run to write and maintain a 3D user interface. Probably the preprocessor could largely be an analog of the 2D version, which I originally envisioned as a graphical way of entering in the information used in a Triangle .poly geometry definition file. A lot of the heavy lifting gets sorted out for free by the mesh generator. Just tagging regions with block labels makes it a lot easier to do the preprocessor, because the preprocessor then doesn't really have to be all that smart and keep track of the various regions in the problem as the geometry is changed. I'd like to do a similar approach for a 3D code, except that one would think of the preprocessor as being a graphical tool for building a Tetgen input file.
We need to define a core functionality that the program would
implement:
How does user interface "work"?
What type of problems are to be solved? (suggest
nonlinear magnetostatic and nonlinear time-harmonic as a start)
What formulation is to be used? ("dive off the deep
end" and suggest T-Omega formulation)
What sort of license will the program be developed
under? (Some sort of open-source license, but which one?)
How would the program be structured? By breaking things into the old-fashioned preprocessor-solver-postprocessor divisions, or just having one code that envelops all aspects (e.g. like latest Quickfield version)?
We also need to define what set of programming tools will be used. The current 2D code is all MSVC++, but there are tools out there that allow for simultaneous development on both Linux and Windows platforms. Historically, cross-platform development has resulted in some of the commercial magnetics FEA programs having really lousy user interfaces. However, cross-platform development tools are maturing pretty rapidly, and they might now be good enough for our purposes. Candidates might be wxWindows or Fox Toolkit (among others?) for getting things to compile across platforms. And if things could be made to compile on Linux machines concurrently with Windows machines, we might have access to a pool of Linux programmers who are used to contributing to open-source projects. There could be a learning curve to using either wxWindows or Fox, but it might be worth it in the end.
We would want to include scripting (i.e. Lua) in an integral way from the start, rather than as a "retrofit".
Lastly, we need to create a skeleton of the where multiple programmers can be working at the same time. Some of the logistics could be accomplished via standard CVS tools at BerliOS (or SourceForge). A project has already been created for femm at BerliOS (see http://developer.berlios.de/projects/femm/). Perhaps it would be better to move discussions about a 3D version over to the "Developers" discussion forum on Berlios and focus the Yahoo list more on the 2D version. (N.B.: You have to sign up with Berlios and become a developer for the project to get access to the "Developers" forum. There are no restrictions as far as who can become a developer, and it doesn't cost anything to sign up.)
Dave.
--
David Meeker
http://femm.berlios.de/dmeeker