Need a book? Engineering books recommendations...

Return to index: [Subject] [Thread] [Date] [Author]

RE: engineering software

[Subject Prev][Subject Next][Thread Prev][Thread Next]
I agree with Cristopher Wright that the biggest issue is productivity which
includes building and debugging a model.

Some suggested areas where essentially all programs need improvement
include.

1.  Aids in identifying the cause of error messages, including locating the
cause of modeling instabilities.

2.  Once the model has run you need to print output and plots.  Often times
these plots and output need to be plotted out for each of multiple runs yet
you have to spend hours waiting for plots get done so you can manually
specify the next plot or output printout.  What is needed is a way for a
user to specify a series of outputs and or plots and have them repeated at
the end of a sucessful run or by issuing a single command.

3.  A similar problem occurs when post processors must be run after the
analysis is done.  There is a need for a way to specify that certain post
processors be automatically executed upon completion of the analysis.

4.  Make it easy for the user to automatically extract input and output
data from the files created by the analysis program so they can be
processed in ways not supported by the program.  This would also allow the
user to create custom summary reports.   This is especially important when
working with design criteria not supported by the existing code checking
routines.

5.  let the user to specify a line, plane or region of the model and have
the program report any forces acting on this surface.  This is essentially
a free-body diagram.

A number of  these problems could be solved by providing the user with
hooks that allow another program to access the output files and to control
the order of execution of pre and post processors.  Much of this could be
accomplished by having the program follow certain Windows Standards and
providing an object interface that Visual Basic could use.

The currrent user interfaces are getting better but they still have a long
way to go.  Many of the senior engineers do not feel the pain because they
turn this boring and mind numbing work over to the more junior engineers.  
In addition to the lost man hours the  lack of a productive environment
results in project delays.


Mark Gilligan


----------------------------------------

>I'd be very pleased if developers would leave computer technology alone 
for however long it takes to come up with readable docs, bug-free 
operation, features that actually work and the QA program to back it up, 
support staff that knows engineering and a user interface that doesn't 
suck. 

I think the emphasis on whizzy computer science is vastly overrated; the 
real cost of computer tools, especially FEA, is debugging a model and 
interpretation, not solution time. Saving me 50% of the solution time is 
trivial compared to the time it takes be to verify that a model is 
providing me with accurate, relevant results. To go further, the move 
toward faster machinery and greater storage capacity seems to encourage a 
sloppy approach to problem solving and less reliance on first principles. 
It also gets newbies in over their heads much faster.

Christopher Wright P.E.    |"They couldn't hit an elephant from
chrisw(--nospam--at)skypoint.com        | this distance"   (last words of Gen.
___________________________| John Sedgwick, Spotsylvania 1864)
http://www.skypoint.com/~chrisw
<