[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

# Re: [femm] Re: Circuits in FEMM

- To: femm@yahoogroups.com
- Subject: Re: [femm] Re: Circuits in FEMM
- From: dcm3c@aol.com
- Date: Thu, 13 Sep 2001 00:34:47 EDT

In a message dated 9/7/01 1:58:46 PM Eastern Daylight Time,
frank.e.lenning@boeing.com writes:

> Way cool Dave. Thanks. What I was really trying to do was understand
> better how FEMM solved this problem to tell if I could get another
> code, Quickfield, to do the same problem (I've been using FEMM but
> some others in my workgroup already own Quickfield). By your fine
> writeup, I believe the answer is no since Quickfield doesn't exactly
> have the same circuits capability and without setting up and solving
> the equations with the unknown potentials, you have nothing better to
> do but to guess at them and iterate...ugly.

From what I can tell, Quickfield 4.2 will let you drive multiple sections of
the model in parallel with a constraint on the total current, but all of the
blocks that are driven in parallel have to be composed out of the same
material. Femm will let you drive multiple sections with different
materials in parallel, enforcing a net current constraint on all block in the
"circuit" because it implements the constraints a little differently. I
haven't messed around much with the 4.3 version of Quickfield--it could be
different for that version.

> Your open source is great. I had already found the place in prob2big and
> your note will help me understand what I'm seeing better. BTW, your
> support of this group is nothing short of amazing. Microsoft could take
> some product support lessons from you.

Well, the dedication of the members of this list is the other key part the
femm development process. The open-source nature of the project has not only
allowed users to find bugs and suggest solutions (which is great in itself),
but also to expand the project in powerful ways that never would have occured
to me to do (e.g. lua).

> On a related subject, I'm interested in a 3D FEM as well. Is there a
> public domain 3D mesher out there like triangle (or can triangle do it)??

Well, Si Hang has recently released a 3D tetrahedral mesher he calls Tetgen.
It appears to extend the structure and overall "feel" of Triangle (which is
limited to 2D geometries) to address 3D problems. I might as well give the
web page a plug: http://www.weboo.com/sh/tetgen.htm There are a number of
other 3D meshers that can be located by rummaging around the sites listed in
the "Mesh Generation" part of the femm links page at
http://members.aol.com/_ht_a/gmagnetics/links.htm Some of these are freely
available, but because Si Hang's approach follows Triangle in the way that
it keeps track of boundary conditions and material properties in the mesh, it
ought to be particularly well suited to 3D finite element problems.

> I assume one could use the same solver engine as FEMM but the
> mesher and visualizations would need to change.

Well, having a mesh generator is an enormous step towards creating a 3D code.
For the current 2D code, the whole preprocessor could be viewed as sort of a
visual editor for Triangle meshes. Once I decided to use Triangle to do the
meshing, a particular structure of data that needed to be kept track of was
implied. A lot of the rest of the program just goes about enforcing the
conditions that are necessary to have a valid input file to Triangle--so in
some sense, the preprocessor "wrote itself" because of the implications of
the mesher. The same would probably be true of a 3D program, although doing
the 3D visualization and editing is somewhat more complicated than in 2D
Some parts of the solver could be re-used. The linear algebra-related parts
of the code (stuff in spars.cpp and cspars.cpp) are very generic and could be
re-used verbatim in a 3D solver. The formulation of 3D problems is a bit
more subtle than 2D problems, but the total lines of code in the solver would
probably be on the same order as the current one.
Sort of a truism in programming is that you don't really know how to write a
particular program correctly until you've already done it once. This is
certainly true of femm--it would be nice to incorporate some of the "lessons
learned" from the current 2D code a priori in a 3D program design. In the
current version, the data structures are sort of ugly, and some obvious
opportunities for a more object-oriented approach have been missed (e.g.
being able to do different sorts of problems like electrostatics, magnetics,
potential flow, as sub-classes of one "finite element problem" class). It
would also be worth some time to think of a way to structure things to make
it easier for multiple developers to work simultaneously. The number of
people who have contributed source code for the present version is fairly
limited because a fairly deep understanding of how femm is internally wired
is required to effectively make significant changes to the code--a better
structure could make it so that the typical developer need only understand
the inputs and outputs to most of the sections of the code, allowing one to
concentrate on specific aspects without having to understand everything
first. Lastly, it would also be good to build in the Lua scripting
capabilities as an integral part of the structure of the program--perhaps
this would imply some directions for a more segmented program structure.
Dave.
--
David Meeker
http://members.aol.com/_ht_a/dcm3c

- Prev by Date: Permanent Magnets & Frequency.
- Next by Date: Re: [femm] Permanent Magnets & Frequency.
- Previous by thread: Re: Circuits in FEMM
- Next by thread: Inductance - more confusion
- Index(es):
  - Date
  - Thread