[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [femm] 3D Code (was Re: Linux and 3D)
I think that GNU General Public License is the best
license to be used.
Compiler: GNU C++ with DDD debuger.
OpenGL should be the graphics library.
An other possibility is Java. It is portable for all
platafforms but the speed processor is very low.
--- David Meeker <dcm3c@xxxxxxxxxxxxx> escreveu:
<HR>
<!doctype html public "-//w3c//dtd html 4.0
transitional//en">
<html>
sihang wrote:
<blockquote TYPE=CITE> <tt>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.</tt>
<br><tt></tt> </blockquote>
Well, it looks like we <i>could</i> be approaching a
critical mass that
is big enough to kick off a 3D code. Here are
some thoughts about
making a 3D version.
<p>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 <i>everyone</i> having to understand
virtually <i>everything</i>
about the way that the code works to be able to make a
valuable contribution.
<p>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 <i>lot</i> 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.
<p>We need to define a core functionality that the
program would
implement:
<br> How does user interface "work"?
<br> What type of problems are to be
solved? (suggest
nonlinear magnetostatic and nonlinear time-harmonic as
a start)
<br> What formulation is to be used?
("dive off the deep
end" and suggest T-Omega formulation)
<br> What sort of license will the
program be developed
under? (Some sort of open-source license, but which
one?)
<p>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)?
<p>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.
<p>We would want to include scripting (i.e. Lua) in an
integral way from
the start, rather than as a "retrofit".
<p>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 <a
href="http://developer.berlios.de/projects/femm/";>http://developer.berlios.de/projects/femm/</a>).
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.)
<p>Dave.
<br>--
<br>David Meeker
<br><A
HREF="http://femm.berlios.de/dmeeker";>http://femm.berlios.de/dmeeker</A>
<br>
<br>
<tt>Your use of Yahoo! Groups is subject to the <a
href="http://docs.yahoo.com/info/terms/";>Yahoo! Terms
of Service</a>.</tt>
</br>
</html>
_______________________________________________________________________________________________
Yahoo! GeoCities
Tenha seu lugar na Web. Construa hoje mesmo sua home page no Yahoo! GeoCities. É fácil e grátis!
http://br.geocities.yahoo.com/