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

Hi Doug,

Yes, Numeric Python was invented at Lawrence Livermore Labs for just
such purposes. (Python was invented years before in the same spirit as
Perl) They use it alot there for wrapping their huge weather/climate
model programs. I've also seen references to it being used to wrap EM
simulator programs running on huge parallel machines. To that end,
there is a module called PyFort that can be used to interface any Python
program to any FORTRAN one. And also some modules for parallel
computing.
(see www.python.org under "Vaults of Parnassus")

Rob.

"D. B. Miron" wrote:
>
> Sounds like what I used to do in APL. There is also a tradeoff between code
> development time and code execution time. If you are writing code for a
> special problem and don't plan to run it often, then an easy-to-program
> interpreted language is a better choice than programming in a compiled
> language which generally takes a lot more time to write and debug. My point
> in my previous e-mail is that production programs need to be efficient as
> possible, or affordable, because inefficiency costs time when the code gets
> used a lot.
>
> Doug Miron
>
> ----- Original Message -----
> From: "Rob" <rob_at_pythonemproject.com>
> To: <nec-list_at_gweep.ca>
> Cc: <nec-list_at_gweep.ca>
> Sent: Wednesday, November 27, 2002 6:22 PM
> Subject: 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

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