[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [femm] r-component of force in problems with axisymmetric geometry
James Rabchuk wrote:
Hi,
I've just begun using FEMM, and have found it to be very useful and
accurate. What a great tool! Not only so, but the archive of discussions
on
the program have been very useful as well. Thanks so much.
I hope that the program proves to be useful to you.
I have a question regarding the calculation of forces on objects lying along
the axis of symmetry using the stress tensor integral. It's clear from the
Roters' example provided on the website that to find the z-component of
the
force on such an object, I need to create a contour with beginning and
ending points on the axis (r = 0) line which "encloses" the object, like
so:
-------|
| ^
-| | | z I hope this picture is preserved!
-| | -> r
-------|
Yes, this is right. You could imagine the surface of revolution made by
this countour as a pill shape that encloses your object.
Doing so has given me very believable results for the force, if I use a
small enough mesh, though the magnitude of the force is quite small (on
the
order of 10^-4 Newtons). However, just as a check, since I am looking for
an
equilibrium solution, I wanted to see what the program would say about any
forces acting in the r direction. Of course, I expected that they should
cancel out because of the symmetry of the problem (allowing for possible
numerical error). Surprisingly, the program predicted a quite large,
positive force in the r-direction (on the order of 10^-1 N), which varied
smoothly with vertical position of the object.
As I was doing this calculation using lua scripting, I just changed the
_expression_ found in the Roters' example to
fr,p,fz=lineintegral(3)
where fr and fz should pick out the real parts of the r and z components
of
the 1x force, as I understand it.
Can anybody explain to me what is going on? Even if I were to explain away
the positive force in the r-direction as being equivalent for every value
of
theta, and therefore cancelling out as expected, I expect and know that
there should in fact be a restoring force pushing the object back toward
the
center line, so that the sign of the force should be negative in this case.
Not only so, but the magnitude of the force is just too big.
The result that you get from the lua function for radial force is garbage.
As you say, the net radial force for an axisymmetric problem should be zero.
If you take the line integral "by hand," the program doesn't report a radial
force component (because it is supposed to be zero). However, when you take
the integral using the lua function, it reports an essentially meaningless
result for the radial force, rather than zero. I'll go back and make sure
that it reports a zero force for the radial direction for the lineintegral(3)
in axisymmetric problems--thanks for pointing this out.
I did notice when I graphed B dot n along an upward vertical line, the
program automatically gave the sign of the dot product to be positive, when
the field should have a negative r-component, as verified by the plot of
B
dot t for a horizontal contour moving away from the axis. Does the normal
always point 90 degrees ccw from the direction of the line segment?
Yes, the normal always points ccw from the direction of the line segment.
Therefore, an upward vertical line would have the normal pointed in the
-r direction, i.e. along the vector (-1,0). If the field has negative r component
along your line, the dot product with (-1,0) would yield a positive-valued
result.
I should also mention that in this case, the stress tensor proved much MORE
useful than did the coenergy method that is usually recommended by the
program author. I guess that it is because in my problem, the object which
is moving is so small compared to the entire solution domain. I could never
resolve a clear trend in coenergy vs. position.
It's hard to say quite what's going on without seeing the problem. Generally,
however, it's good to make the elements in the region that is in motion small
enough so that each step traverses a length longer than the element size--this
has given OK results for me in the past.
Dave.