[Beowulf] Re: about clusters in high schools

Jim Lux James.P.Lux at jpl.nasa.gov
Sun Jan 29 16:01:08 PST 2006

At 12:28 PM 1/29/2006, Timothy W. Moore wrote:
>I did not know about the new standards/requirements.  Interesting
> > > The ABET certification is now emphasizing more soft skills such as team
> > > work and presentation skills.  This leaves fewer hours for technical
> > > classes.
> >
> > A whole CLASS on "team work" or "presentation skills"?  As fundamental
> > to an ENGINEERING curriculum?  God save us...  Or rather, let's hope
> > all the engineers we import from India and China save us - from faulty
> > automobiles, process plant disasters, collapsing bridges, etc. etc.
> >
>I use spreadsheets to track my financial records.  I have never pondered
>any scientific application.

Spreadsheets are great for "quick estimates", but the temptation is to not 
accept the limits.  Some real life examples:
An excel spreadsheet to determine if an antenna mast will break in the 
wind, and what the guy loads will be.  Put in the tubing sizes, etc., and 
you quickly can weed out the obvious non-starters.    However, once you 
want to know things like fatigue loading, or you're close to the limit, 
better get out the real tools.

A spreadsheet to figure out gain, power, and noise figure cascades in an RF 
chain.  Just how many stages do you need, what's the SNR, etc.  A 
spreadsheet to identify the various frequencies of spurs, etc.  But once 
you've gotten beyond the "block diagram design" stage, you're better off 
using the real tools like ADS.

Calculating mutual impedances and element currents in a phased arary can be 
done to a first order with a spreadsheet or algebra, but once you're at the 
needing 5% accuracy stage, better break out NEC or something similar.

The problem with the real tools is that they:
a) have a steep learning curve, and need regular use to remain 
facile.  This is particularly true for FEM programs that require a certain 
amount of expertise to code up the models.
b) They're expensive, and it's hard to justify $10k-$50k on a speculative 
project with a value of $100-200K.
c) They might have real significant resource requirements to run acceptably 
fast (hey, but isn't that what Beowulfs are for!)

> > > The simpler engineering analyses can be done with a spreadsheet and
> > > fairly complicated work can be done with Matlab/Mathcad.  There are
> > > plenty of commercial systems for CFD and FEA.  In the squeeze, the
> > > schools have dropped programming.
> >
>I never said Matlab is not a programming language.  In fact, I know
>nothing about it because I have never used it.  When in grad school
>(well over 15 years ago), I remember there was a computer with what was
>probably a very early version of Matlab installed...I never approached
>it.  I opted for the computer with MSC/NASTRAN installed because that
>was the software package that helped me design composite aircraft
>pressure bulkheads, fuselage skins and window frames.

Even today, you'd choose NASTRAN (an FEM code) over Matlab for this sort of 

>   It may be
>appropriate and I have nothing against students learning the package.  I
>DID say that it is not a substitute for learning C or FORTRAN.  To my
>knowledge (maybe I am naive and stupid), I have yet to see a CFD or
>finite element code written in Matlab.

But how many people actually need to code the FEM algorithm, as opposed to 
using it and being aware of its limitations.  FWIW, there ARE FEM codes in 
matlab (IMOS is an example), because many FEM problems are basically matrix 
solving problems, and matlab does that quite well.  The application 
specific part is building the matrix.

>   For example, I use a particle
>code originally developed with its own visualization code. It was
>archaic, slow and not user-friendly.  My programming abilities have
>allowed me to change the plot format (as well as the numerics) to work
>with commercial visualization tools that I use for most of my
>applications allowing me to have a single interface.

BUT... and here's an interesting problem... would the dollar equivalent of 
work hours you spent modifying the code have been better spent on a tool 
which actually did what you needed (assuming it's available).  I've seen 
engineers spend hundreds of hours building FORTRAN, C, or matlab codes to 
do what ADS (an RF design tool) can do in seconds.  The difference was that 
the hours were spent in small increments over a fairly long time, in 
comparison with the multi-kilobuck shot to license ADS.

Business processes and institutional requirements CAN get in the way here, 
of course.

> > Since when is Matlab not a programming language?
> >
> > It is entirely appropriate that an undergraduate curriculum use a
> > programming language like Matlab rather than C or Fortran.  Most
> > engineers will NEVER program in C or Fortran (nor Pascal or Java)
> > after college, and rightly so.

I'd even go so far as to say, many engineers SHOULD BE PROHIBITED from 
programming in their professional career (unless they're in the software 
development business).  Better they should learn how to write effective 
specifications and test cases so that someone else can do it better.  Yes, 
being an engineer means you're, by nature, a jack of all trades, and we're 
justly proud of it, BUT, from a business standpoint, machinists should 
machine, artists should art, and engineers should engineer.  All should 
know what the other one can do and how they do it(and should have done a 
bit, so they understand WHY they shouldn't be doing it).

> >
> > Learning effective use of one or more higher level languages, on the
> > other hand, would serve them EXTREMELY well.  A scripting language
> > like Tcl, Perl, or Python would certainly be useful, but a math or
> > statistically oriented language like Octave or R probably has better
> > synergies with the rest of the engineering curriculum.

I'd be happy if engineering students all learned english grammar and 
spelling and could write an effective 2 page essay.

> >
> > The only improvement - and it's a big one - would be to teach with an
> > Open Source language like Octave or R rather than a proprietary one
> > like Matlab or S-Plus.  Among other advantages, that way the engineers
> > can easily take all the code they wrote in school with them and USE
> > it.

Octave and Matlab are basically the same syntax and function.

I would run in fear if someone popped up at a design review for a 
production system and said "hey, I've got this nifty piece of code I wrote 
back when I was a sophomore, let's use that".

I'd be glad they had done the work back then, and I'd hope they remembered 
the significant design issues and implementation gotchas, but I'd also hope 
that they'd code the new stuff from scratch, or use whatever we had already 
done as a basis.  The intellectual property rights issue alone is 
frightening.  (been there, been depositioned, been the expert witness, 
lived through the lawsuits, have no desire to repeat it again)

> >
> > Ages ago when I was a Process Engineer, I wrote a whole bunch of
> > Bourne shell, sed, and Awk code (plus a touch of Perl later on), but
> > although I knew some C (and was learning more), I never touched it
> > once on the job, and never had any reason to either. If I'd actually
> > learned one or more of Tcl, Python, Perl, Matlab, Octave, S-Plus, or
> > R, they DEFINITELY would have been useful to me.  C, Fortran, or Java,
> > no.
> >

But that's somewhat specific to the job and environment.  If you had toiled 
away learning tcl, then you might have wound up at a place that used only 
perl, etc.  Gotta pick somthing, so you might as well pick something that 
is reasonably stable and widely known.   Hence the popularity of Latin in 
classics instruction.

>My experience is slightly different.  I am not a full-time programmer
>and can program in FORTRAN quite well.  I have written sophisticated
>programs that allow scientists to explore the inner workings of complex
>weapons systems involving thermodynamics, chemistry (reactive flows) and
>fluid mechanics.  Maybe the run-of-the-mill engineer does not use or
>need such tools.  I typically work on problems that either do not have a
>solution or has never been studied which might explain why I have to
>develop tools for my applications.
>These codes are written in C, C++ and FORTRAN and simulate complex

And, today, these codes get written in matlab, and work just as 
well.  Matlab just saves you the hassle of having to explicitly call the 
"MATMUL" routine, or worry about coding up yet another LU solver.


More information about the Beowulf mailing list