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

3 phase cable/animation & thanks



OK. Thanks, I sped up the calculations using:

function cos_alt(x)
return floor(cos(x)*1.e4)/1.e4
end

which basically rounds to 4 places. I have placed one of the 
animations in the folder 3_phase_cable called "mumetalall.gif". This 
demostrates a 1/4" plate of mu metal, 3 meters wide over a 3 phase 
cable carrying 500 amps.

Once again thanks


--- In femm@xxxx, dcm3c@xxxx wrote:
> In a message dated 10/23/01 4:17:33 PM Eastern Daylight Time, 
> lkloesel@xxxx writes:
> 
> > Dear All,
> > 
> > I was trying to simulate the rotating fields around a 3 phase 
cable 
> > (see FEMM folder 3_phase_cable). In order to change the 
currents, I 
> > used modifycircprop() lua command. As you can see, in the 
> > pre-processor script, I changed the currents by adding 10 degrees 
> > to each program loop. The post-processor file will take a 
snap-shot
> > of 
> > the field, to which I will eventually assemble with a 
gif-animator to 
> > reveal a very nice animation of the fields.
> > My problem is this: FEMM hangs in the fkern portion, the 
biconjugate 
> > gradient solver just sits there. I had to add 0.5 (or 0.1) to the 
> > currents in order to get fkern to unhang. I believe there may be 
a 
> > bug here which warrents review. I changed the precision, but 
that 
> > didn't work. I looked for a simple lua method of rounding the
> > numbers 
> > after they were created from the sin() and cos() functions, but 
found 
> > none readily available.
> 
> It is theoretically possible for the BiCG iteration to break down 
(i.e. not 
> converge), although this "rarely happens in practice." This appears 
to be 
> one of those "rarely happens in practice" situations... The 
iteration 
> converges nicely when I force it to start from a random initial 
guess, but it 
> hangs when I start it from an initial guess of all zeros. I'll try 
to muck 
> around with the solver to see if I can get it to be a bit more 
robust to this 
> situation. 
> 
> In the mean time, things also appear to converge OK when I round the 
sin() 
> and cos() functions to single precision. To get it do this, you can 
define 
> the following functions at the beginning of your script:
> 
> function cos_alt(x)
> return floor(cos(x)*1.e8)/1.e8
> end
> 
> function sin_alt(x)
> return floor(sin(x)*1.e8)/1.e8
> end
> 
> Then, make calls to cos_alt() and sin_alt() rather than cos() and 
sin(). The 
> script seems to run ok with this modification.
> 
> Anyhow, thanks a lot for pointing this out--I really appreciate it.
> 
> Dave Meeker
> --
> http://members.aol.com/_ht_a/dcm3c