Re: Convergence problem with pure iron?

[uwenh@xxxxxx]

Hi Dave!

thanks a lot for the support. The calc. really got faster as well - 
nice "spin-off" ;))

Uwe.

--- In femm@xxxx, David Meeker <dmeeker@xxxx> wrote:
> uwenh@xxxx wrote:
> 
> > Hello Everyone, Hello Dave!
> >
> > well, since I'm new to the group let me introduce myself. My name 
is
> > Uwe, I'm living in Frankfurt, Germany.
> > First of all I wish to express my gratitude to Dave for supplying 
us
> > with such a good piece of free software. Thanks.
> > I'm using FEMM now for some months, first of all to get into the
> > field of electro-magnetics. I'm a mechanical engineer primarily
> > dealing with electro-mechanical issues who wants to expand his
> > understanding. Currently I'm working on a solenoid actuator for a
> > pressure valve. The model consists of a plunger and some 
stationary
> > parts (let's call these bobbin) carrying the coil. Plunger and 
bobbin
> > are made of VACOFER S1, that is a high purity iron (more info on 
this
> > web-site http://www.vacuumschmelze.de/100p_fra.htm). The coil is
> > modelled by a rectangle to which a current density is applied
> > amounting to a current per turn of 0.5A, 1A, 1.5A and so on. For 
my
> > inital trials with the FE model I just used M19 steel. These
> > calcualtions always ran straight. But of course the forces I got 
were
> > way off of what to expect. Then I got the data of VACOFER in Excel
> > and I created my own material entry. But soon I realized that the
> > computing time rises drastically with the number of data points
> > used. Sometimes the calculation even seemed to be stuck in an
> > endless loop. All right I thought, there's to be some trick in 
making
> > a suitable non-linear BH curve for the computation and started 
using
> > the "pure iron" material entry of the FEMM material database. Now 
my
> > model seemed to run reasonable well at least for a current 
density of
> > 0.8A/m2 (that is 0.5A per turn). But as soon as I switch to higher
> > currents the calculation seems to stall during the Conjugate 
Gradient
> > Solver (the cpu load stays 100% for the fkern process, but memory
> > usage does not change anymore, the .ans file is not yet created). 
I
> > also tried different meshes etc. But at some point the calculation
> > seems to get stuck. Now, am I rather impatient (my PC is 
PII300Mhz,
> > 256MB RAM) or do I have a bad model, or is it possible that the
> > solver gets numerically ill-conditioned during the calculation 
for a
> > material like pure iron?
> 
> The program fits the BH data points with a cubic spline. However, 
it doesn't
> currently do any checking to make sure that the resulting curve is
> single-valued. That is, the spline goes through the specified data 
points,
> but it does funny things in between the data points. If the BH 
curve is not
> single-valued, the solver has problems converging (and the problem 
is in some
> sense not physical).
> 
> Often, you can just plot the BH curve and "eyeball" it to see if it 
looks
> ok. Unfortunately, because of the scaling of the plot, it is 
difficult to
> tell whether or not the BH curve is ok. This is actually what is 
going on
> with the "Pure Iron" curve--the curve fit is messed up in the steep 
initial
> section, but it's hard to see in the plot. I looked through the 
library, and
> it appears that the "430 Stainless" entry is also mucked up in a 
similar
> way--the rest of them appear to be OK.
> 
> Anyhow, I've attached a modified version of your geometry. I've 
fixed the BH
> curve in the "Pure Iron" material defined in this problem by adding 
some more
> points into the BH curve to ensure the the program gets a single-
valued fit
> to the BH curve. You can replace the definition of this material 
in the
> Materials Library with the one in the file by going into the 
library by
> selecting Properties | Materials Library off of the main menu, 
deleting the
> Pure Iron entry out of the library, then adding to the library the 
Pure Iron
> entry from the model.
> 
> I've also been looking into ways to fix the sensitivity in the BH 
curves. It
> is easy to programatically check if the curves are OK, but I 
haven't decided
> whether or not I like the fix that I have implemented in my 
development
> version--I just repeatedly smooth the BH points using a 3-point 
moving
> average filter until the resulting fit is single valued. Now, this 
has the
> advantage that it always works in the sense of providing a smooth,
> single-valued BH curve that won't hang the solver. However, it is 
possible
> for a repeatedly smoothed curve not to match up that well with the 
original
> BH data points...any suggestions are welcome.
> 
> Dave.