[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ScanTesla Version 7.50
Original poster: Vardan <vardan01@xxxxxxxxxxxxxxxxxxxxxxx>
Hi dest,
At 10:58 AM 5/31/2006, you wrote:
Hallo Terry.
> The program can iterate through Tesla coil configurations very fast
> and search for the most optimal component values. It is sort of like
> MicroSim on steroids ;-))
haven`t used microsim at all - it is really so slow? : )
It is super slow if you are trying to iterate through
combinations. Although Steve did figure out how to do parameterics:
http://scopeboy.com/tesla/drsstc/simulation.html
"The screen will flash by a lot of stuff for a few moments and
disappear. The end of the "output.txt" file has the data we want
stored."
yeah - after 35 mins of sleeping on the keyboard i finally got goal
#99 that says, that my toroid must be about 15pf instead of 45pf that
i`ve build - such small pice of crap surelly would look very comical
on my 9" secondary, kinda '1903 style : )))
i`ll write on them with black marker - "recommended by most powerfull
tc proggy on da net" ^______________^
:-)) The program uses the data we have. It does not consider
physical dimensions or what we "know is right" for say streamer
feeding. It does have that ability, but there is not enough data yet
for the active streamer loading part of the program to work (if you
set the increment on Csec to -1.0, it will try).
But this is where to program can really do something neat! Let's
make a plot of Streamer power vs. Csecondary to see what the effect
of various terminal sizes might have. If I pull up ouputdata.csv and
make the plot I get:
http://drsstc.com/~sisg/files/scantesla/dest-01.gif
The first part of the graph the program is just searching but after
that it certainly does appear that smaller top terminals will give
better streamer power. Along the bottom we see Csec decreasing while
load power is increasing. Of course, we need better streamer data to
figure out why that does not seem to be the case with our
coils. This simulations shows a lot of things that are "not" the problem...
My 3GHz takes about 31:47 to do it too so the speed is about the same
for both of us.
what i have varied:
* Lp
34.0e-6
104.0e-6
1.0e-6
* Ls
98.0e-3
158.0e-3
1.0e-3
* Cs
25.0e-12
65.0e-12
1.0e-12
for 750us it takes only 177571 models to test : )
a couple of questions:
1. at first run (different input) it was doing about 1 model/sec only,
after 800 or so steps it suddently speeds up for short time (~200
steps), then slowed down again - surely "steroids" at work : ))) why
it so slow?
When it is slow, it has found a new best match and it is recording
the data. When it is fast, the model it is working on is less than
the previous best so it skips over recording any data about it. Most
(80%) of the time is for file writing.
2. it takes about 98-99% of my athlon xp 1600+ and about 50-55% of my
piv 3000 - why it can`t take all available cpu cycles?
btw - i see the same situation when run bela also % )
The writing to files is what is taking time. As it writes to disk
the CPU mostly sleeps. If your computer has dual core, it will only
use one of them. My 3GHz Intel only gets to 54% too. You can
actually have another program going in a different directory to get
to about 100% CPU usage. So two programs run just a little slower
than one since two use both cores. My true dual CPU computer does
the same thing. There might be a ways to get the compiler to use
both, but I don't know it. Of course, you basically have 1/2 the CPU
free so you can go ahead and do your other computer work as it
runs. Other stuff running will not significantly slow the simulation
since they are running on two different CPU cores.
3. imo there is no need in Rpri, Rsec and Rload, coz "i" just want get
maximum. can i gain some speed if i define Rpri=Rsec=Rload=1 - then
there is no need to multiply/divide on them? or you use another
algorithm, so this is not the case (didn`t looked at c code - don`t
know and don`t like c : D)?
I think the calculation time there is very small. The machine
probably just spends as much time calculating with "1" as 1.3956464604e-034...
4. mmm - i forgot already : )
Here is how to speed it up. The "Time" variable is very important
for speed. It will always start at zero but it may not have to go to
750uS. If you coil's burst gets all done in say 400uS then only go
that long. The increment value might not need to be 0.1uS
either. Sometimes I run at 1uS especially just to get close to an
answer. You can also set the increment value to -1.0 and the program
will automatically adjust it for a fairly optimal (speed/accuracy) time.
Buy lowering the time each simulation runs and increasing the
increment time, the number of steps in each model can be
significantly reduced. This also increases file writing speed.
Cheers,
Terry