Hi there,
Just a thought. I developed an electrostatic BEM solver which I built on the
back of GID ( http://gid.cimne.upc.es/index.html
<http://gid.cimne.upc.es/index.html> ) a pre & post processor, I know it's
not free but it isn't expensive has a passable modeler, good mesher and
postprocessor with a TCL-TK extension. it allowed me to concentrate on the
solver code rather than the user interface.
This is a great user group. Thanks for FEMM.
Regards
Mark
-----Original Message-----
From: David Meeker [mailto:dcm3c@xxxxxxxxxxxxx]
Sent: 01 February 2002 05:45
To: femm@xxxxxxxxxxxxxxx
Subject: [femm] 3D Code (was Re: Linux and 3D)
sihang wrote:
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/
<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 <http://femm.berlios.de/dmeeker>
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .
--------------------------------------------------------------------------
This e-mail may contain privileged/confidential information and may be
read, copied and used only by the intended recipient. If you have received
it in error, please contact the sender by return e-mail or by
telephoning +44 (0)1480 302100.
Please then delete the e-mail and do not disclose its contents to any
person.
Any information in this message that does not relate to the official
business of Linx shall be understood as neither given nor endorsed by Linx.
We reserve the right to monitor all e-mail communications through our
internal and external networks.
--------------------------------------------------------------------------
Attachment:
bin00043.bin
Description: Binary data