Thanks for reply soon. I use the (1) method at
my origin work. But the smoothing solution of B was not very good along the
axi. The only diffrence between you and me is the Gauss Point's location.
It seems we always should choose the centroid of a element as its Gauss
Point. Is that right?
In function GetNodalB, I was not very clear now what
method you used to get nodal value when it is on interface?
Thank you.
----- Original Message -----
Sent: Wednesday, March 14, 2001 6:50
AM
Subject: 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.
Your
use of Yahoo! Groups is subject to the Yahoo! Terms of Service.