[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:


"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

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:


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

* Ls

* Cs

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.