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

Re: [femm] Question in Axisym. Problems in Postprocessor



 

stsc_sh@xxxxxxxx wrote:

David:
  First of all, thanks for providing the FEMM program and it's source
code. It's really help me a lot and save many times for me in my work
in solving 2D electro-magnetic problems.
I'm glad that the program is proving to be useful to you.
 
  Could you give me a more detail description on how to interpolate
the potential in axi case. And how to get element's B value where it
is near the axi and the equations you used(because I can't got the
references you listed in the User Mannual). Thank you.


Someone else asked me this question privately a few days ago.

I have a question about FEMM...

I cannot understand the formulation used for the axisymmetry analysis. I cannot understand the referred paper at all.
 
I want to know how we can find the magnetic flux density, B from your ?*.ans? file.
 
I tried to find B from old formulation (A-Phi, A-r), but my result was not the same as FEMM result.
 
Please tell me...

Well, you don?t really have to understand that paper in order to back flux density out of the *.ans files.  The methods in the paper were just used to derive the element matrices.  Once I derived the matrices, I transformed the matrices back so that they work with nodal values of A, because there are all sorts of advantages in working in a direct vector potential implementation.

But anyhow, the details of what the solver does internally don?t matter all that much. In all the versions (even 2.1 and before) and regardless of the formulation that I used to derive the element matrices, the values stored in the *.ans file are the nodal values of flux?that is, 2*Pi*r*A, where r is radius from the centerline, and A is vector potential.  The reason that it?s stored this way is the the postprocessor plots level contours of flux in the axisymetric case as the flux lines?the flux density travels tangent to level contours of 2*Pi*r*A.  The original rationale was that then the postprocessor could interpret the results as being largely similar to A for 2D planar problems.

Anyhow, femm does some sort of subtle things to get things to come out ?right,? especially for the elements adjacent to the r=0 line, but most of the complicated stuff that femm does ends up in the 4th or 5th significant digit of the flux density, and you probably don?t care about it.  You could use one of two ?easy? ways to find the flux density:
1) divide each nodal value of flux by (2*Pi*r) where r corresponds to the radius of the node in question.  Then, get flux by computing curl(A), being careful to use the axisymmetric version of curl(A) evaluated at the centroid of the element.
2) you can get flux density directly from the nodal values of flux.  If you write curl(A) for the axisymmetric case in terms of flux, things are actually look simplified somewhat.  In this case, the r-direction flux is -1/(2 Pi R) (d flux)/(d z) and the the z-direction flux is 1/(2 Pi R) (d flux)/(dr).  (You should check the signs on this?I just re-derived these expressions and might have messed them up...), where R is the average of the nodal radii of the element in question.

The best interpretation of the result from either approach is the flux density at the center of the element (i.e. the Gauss point).  In 2-D problems, flux density is constant over an element.  In axisymmetric problems, things aren?t exactly constant, but the result is a similarly discontinuous flux density from element to element.  Therefore, femm smooths the results by backing out out nodal flux densities.  The nodal flux densities are obtained by taking the weighted average of the flux density in each element that contains a particular node.  I then interpolate these nodal flux densities for points in the interior of each element using the usual triangular interpolation functions.  There is a lot of extra logic included that tries to deal with interfaces between materials and corners in a sort of coherent way.

Anyhow, if you want to see how femm does it, you can always download the source code off of the femm website.  The relevant subroutine is GetElementB, which is located in the femmviewdoc.cpp file in the source code for femmview.  The way that the flux density is computed is a more complicated version of method (2) above. [The difference is that flux is interpolated linearly with respect to r^2 rather than r, which gives the 'right' results as r goes to zero.]  The source code for method (1) is also in there, but it is commented out.  There is also a pretty messy routine called GetNodalB that does the weighted average to get the nodal values and tries to sort out all of the special cases and exceptions that might occur along the way.

  Anyway here are two suggestions that maybe help FEMM get more
efficient in use:
  (1) In postprocessor view you can try to use the virtual window
replace redraw the window. Just use win32 API function BitBlt() after
draw all items in the window. In WM_PAINT message handler use BitBlt
() again to restore the items without addtional job. This will avoid
a long wating time while redraw the windows.
I'll look into figuring this one out.
  (2) In postprocessor Line Integral. It will take a long time when I
try to get a Force or Torgue result from a contour when the mesh size
is big. I think it was a point loction problem. There have some
algorithms for efficient point location[1][2]. If possible, I can
write a function for you for FEMM to solve the efficient point
loction problem.
Yes, this is a lot of the problem--the search scheme I use isn't very bright.  If you want to muck around with how it is implemented that would be great.   The source code that does it is available for download at the femm webpage at
http://members.aol.com/gmagnetics/
The particular subroutine that implements it is CFemmviewDoc::InTriangle, which just uses a sequential search.  The only smart thing that the line integral section does is check to see if the next point in the line is in the same element as the last point, which actually gives a suprisingly large improvement in speed from doing the whole search for each point.
 
[1] E.P.Mucke, Isaac Saias, Binhai Zhu, Fast Randomized Point
Location Without Preprocessing in Two- and Three-dimension Delaunay
Triangulations. In Proceedings of the 12th Annual Symposium on
Computational Geometry,1996.
[2] L.J.Guibas abd J.Stolfi. Primitives for the Manipulation of
General Subdivisions and the Computation of Voronoi Diagrams.
Transactions on Graphics,4(2):74-123.
 
Thanks for the references.  If anyone is interested, I was able to find the first of documents online at:
http://citeseer.nj.nec.com/cke96fast.html

Thanks for the suggestions.

Dave.
 

begin:vcard 
n:Meeker;David
tel;fax:781-890-3489
tel;work:781-684-4070
x-mozilla-html:TRUE
url:http://members.aol.com/dcm3c
org:Foster-Miller, Inc.;Electrical and Electronic Systems Group
version:2.1
email;internet:dmeeker@xxxxxxxxxxxxxxxxx
title:Senior Engineer
adr;quoted-printable:;;350 Second Avenue=0D=0A;Waltham;MA;02451-1196;USA
fn:David Meeker, Ph.D.
end:vcard