Re: [femm] Re: Circuits in FEMM

[dcm3c@xxxxxxx]

In a message dated 9/7/01 1:58:46 PM Eastern Daylight Time, 
frank.e.lenning@xxxxxxxxxx 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