Re: NEC-LIST: Computer speed, was Imperfect ground.

I'll bite. Inexpensive open source code is the only code that you can
modify to suite your own tastes. Even NEC2 has lots of simple mods that
were done over the years. Try asking Zeland for their source :)

Of course, if you pay $10K for an EM simulator, I'd say that you should
have some input into new features, etc,- anything that will get the job
done faster. Ansoft has always been good in this regard. Serenade has
features in it that were requested by me and others back several years
ago. I applaud them for that.

As far as the 500Mhz Celeron goes- if you can buy a 2Ghz P4 or Athlon
equivalent with DDR memory, you will find your sims taking 1 to 1.5
hours. Thats probably a $500 investment for the Athlon system. CPU +
DDR + Mobo.

The Numeric Python EM project was intended for generating efficient
code. Most of the high level computations on arrays are indexed at the
C level so any program that can be vectorized can be very fast.
Unfortuately, the vectorization seems to be only possible with FDTD, and
some of the FEM software. I haven't figured out how to do much at all
for MOM programs like ASAP. I think any program with integration
routines will always be slow in Numeric Python.

But it is intended to be an educational site. In fact, it should be
mentioned in this December's IEEE Antennas and Propagation Magazine
under the Educational Corner.

Rob.

Jim Lux wrote:
>
> At 03:54 PM 11/27/2002 -0600, you wrote:
> >Hi Rob,
> >
> >You have said several times that computers are so fast now that almost
> >anything can be tolerated in software. Last week I ran a 101-point
> >impedance vs. frequency loop on a 1222-segment model using nec2dxs. It took
> >my 500 MHz celeron 5 hrs. Granted a 2 GHz processor would do it in a little
> >over an hour if memory bandwidth is not an issue, but that's still
> >significant time. Faster hardware just means we can run bigger problems, it
> >doesn't mean we can give up coding efficiency.
> >
> >Doug Miron
> >--
> >The NEC-List mailing list <nec-list_at_gweep.ca>
> >http://www.gweep.ca/mailman/listinfo.cgi/nec-list
>
> To which I'd add that it's really an issue of the number of users of the
> code and the "incidence" of the cost.
>
> Compare two alternatives:
>
> Inexpensive, but inefficient code. Consumes twice as much computer
> resources as a
> Expensive, efficient code.
>
> The former reduces the capital investment for the code, but increases the
> cost for ALL the users (whether you figure capital to buy a faster
> computer, or just the cost of the extra time to run slower).
>
> The latter costs the developer more, but saves lots of money for the users.
>
> "the market" sets where the equilibrium point is. Of course, as a
> practical matter, for codes that are likely to be of interest to the
> readers of this list, there are several general classes of users:
>
> A) Cash poor, free time rich, tinkering with a problem, the solution of
> which has little direct economic value (i.e. optimizing the spacing of the
> inverted V wires in my backyard, or a scientist investigating something to
> get it to a point where you can ask for real funding)
>
> B) Cash rich, free time poor, tinkering with a problem of little direct
> economic value
>
> C) Cash rich, with a problem that the solution has real economic value
> (commercial antenna designers, PWB layout to reduce EMI)
>
> D) Cash poor, with a "real" problem.
>
> For cases A, B, and D, the cheap code approach is probably the best. A and
> D don't have resources for either code development or better computers,
> and, so, just have to tolerate it (or reformulate the problem). B can just
> go out and buy a faster computer (or more computers in a cluster).
>
> Case C is the commercially viable one that supports the folks selling
> modeling software. If you need it (in a business sense) then you're
> willing (or should be willing) to pay for higher performance (or, buying a
> faster computer.. the choice is yours).
>
> Consider though... say it takes a year's work to produce a decent product
> (and I'll wager that there's a lot more than a year's work in, say, NEC2,
> or any of the commercially available products). That year's work costs,
> conservatively, $200K (if you had to pay for it). How many customers are
> there for a "better antenna modeling program" and "how much are they
> willing to pay"? If you charge $1K a pop, there better be 200 customers,
> who would rather spend 1K on better software than 1K on a faster computer.
> There ARE people who can make the business case, and are willing to spend
> the bucks for the slick, high performance, software. MATLAB isn't cheap,
> but my professional life is measureably better because it's available, and
> it really, truly does save money.
>
> Fortunately for the As, and really fortunately for the D's, is that what
> also happens, is that some folks are altruistic, and develop this kind of
> software as a "labor of love" to meet some personal requirement, and then
> decide to release it to the big wide world. Or, the "government" (or
> researcher) decides that it's worth spending money to solve the problem for
> one case, and then, since it's done, they might as well release it (since
> the "government" generally isn't interested in a continuing income stream).
> --
> The NEC-List mailing list <nec-list_at_gweep.ca>
> http://www.gweep.ca/mailman/listinfo.cgi/nec-list

-- 
-----------------------------
The Numeric Python EM Project
www.pythonemproject.com
-- 
The NEC-List mailing list <nec-list_at_gweep.ca>
http://www.gweep.ca/mailman/listinfo.cgi/nec-list