SCOUG-Programming Mailing List Archives
Return to [ 08 |
January |
2004 ]
Content Type: text/plain
On Tue, 6 Jan 2004 08:01:50 PST8, Lynn H. Maxson wrote:
>Gregory Smith writes:
>"...Huh? If I knew the values to assign the cells, then the
>problem is solved and I have no need for a computer. The
>computer is supposed to calculate what to put in the cells
>from the governing equations. ..."
>
>Hehehehe. I suspected that. This looks like an algorithm we
>might offer up as one of comparative linguistic examples. I
>don't quite understand why the dependency on what your
>employer provides given the number of free or essentially so
>compilers available on Pentium class machines.
If my boss wants someone to do computational fluid dynamics
on a regular basis, she should spring $20k/yr to license a
CFD package. If I need one or two cases for a research proposal
or report I can do it myself. A few weeks to apply the physics
and do the calculus to derive the equations for cell(i,j); a few
days to code it; and a few days to run the program.
When I do it myself, I will make a LOT of assumptions in my
derivations and my program will NOT be general purpose. A lot
of assumptions went into my description that limited my problem
to only four values per cell. The dusty deck FORTRAN program
that I inherited in grad school had about twenty values per
cell. (The card deck has gone to visit the paper recycler,
but the books and journal articles live on.)
I talked to reps from some of the major CFD vendors at the
Pacific Design Expo yesterday. When you lease their software,
you are contracting the expetise of their matheticians and
physists. They have put a lot of effort into derivations
of different cases for the cell equations. The Ansys reps
were on the show floor near the plastics people. They were
emphasizing the ability to model flows of plastics. The Fluent
rep and the CD Adapco rep were in another hall near the bio-medical
people. They were emphasizing the ability to model blood flow.
Blood, plastic, water, oil, air--they are all fluids. They all
flow through tubes. They all obey the Navier-Stokes equations.
But how you manipulate the Navier-Stokes equations to get something
that can be solved is different in each case.
And sometimes you have to use a great big analog computer: a wind
tunnel and a scale model. Nova on PBS this week (Mars Dead or Alive)
was a good example of this. The scientists at JPL thought they
had the parachute part down pat since they had done it before on
other Mars missions--until they did a test of the parachute.
> Heck, I would
>let you use my PL/I compiler for Windows or OS/2 and let you
>have the free runtime support. I don't see why have you have
>to settle for some 30 x 30 compromise on a spreadsheet that
>won't provide the accuracy that you desire.
I have both Open Office AND Open Watcom. I can code a Fortran
DO loop. I can enter a formula into a spreadsheet cell and
copy it to the other cells. I just find the graphics and
statistical capabilities that I get with the spreadsheet easier
to use for the typical analysis that I need to do after solving
the problem. (Versus trying to use some add-on statistical
library in FORTRAN.)
>
>"...FORTRAN, C, spreadsheets, or Octave in my case. PL/I
>never made it to the VAXen or Cybers that were all over the
>engineering schools in the past. ..."
>
>In a sense this supports my position for providing something in
>open source across all platforms with somewhat more than
>the capabilities of PL/I. I sense that you don't like to
>compromise in a solution. I agree.
Open Watcom Fortran is now at version 1.1. The most recent
GNU PL/I is at version 0.0.2 as indicated at
http://pl1gcc.sourceforge.org/
>I can't make the case "for" logic programming here nor can I
>make one "against". We may have a "wash". However,
>regardless of the "wash" situations that exist along with the
>much larger "unwashed" situations, logic programming
>provides no "worse" instances. Thus at the very least equal
>to a non-logic programming approach, otherwise a better
>approach. That alone should justify its pursuit.
>
>The only little niggler remaining that I have is why you didn't
>(or haven't) done this simple and rather small program in
>Python?
Spreadsheet vs. HLL -- I discussed this tradeoff above.
Interpreted vs. compiled -- another tradeoff.
===============================================================
Gregory W. Smith (WD9GAY) gsmith@well.com
finger gsmith@well.com for PGP public key
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
Return to [ 08 |
January |
2004 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
| 
