Need a book? Engineering books recommendations...

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

RE: engineering software

[Subject Prev][Subject Next][Thread Prev][Thread Next]
>No matter what kind of codes, if they are buggy, they are useless.
Lotta useless codes around, then. Start with several I know something 
about: ANSYS, NASTRAN, COSMOS and STAAD. All have bugs and have had for 
years. Some developers are better than others about fixing them. ANSYS is 
pretty good, but they, like most others, seem to be adding new bugs at 
about the same rate as they fix the old ones. That includes the lower 
level stuff that doesn't produce misleading results, but either won't  
work as stated or produces unexpected results. I think I also mentioned 
erroneous or badly written docs, too--also a productivity problem. 

> This situation is not equivalent to "leave computer technology alone." We use
>computer to solve our problems, how can we leave computer alone?
'Course not. Maybe I wan't clear. I was only saying that developers 
should start fixing bugs in the code they've got before they worry about 
more code for whizzy hardware. Seemed simple enough at the time--perhaps 

>25-year experience, but still having problems with bugs and interpreting
>results.... What is the problem? Is that your software vendor's problem, or
>a problem of new computer technology?
I'll presume you're looking for a straight answer and not just being 
clever. Interpretation problems arise when results are ambiguous, and 
there's a need to determine whether there's a modelling error, a bug or 
simply badly labelled output. That's makes results difficult to check and 
wastes time which should be used more productively. Good example is the 
COSMOS principal stress calculation--choose one program option and it 
figures them correctly, choose another and it doesn't. God knows why. Or 
the fact that COSMOS post-dynamic results don't include reaction forces 
or nodal loads for some reason, unlike the static results. SRAC spent a 
lot of time working on faster iterative solvers when COSMOS desperately 
needed better post-processing--basic stuff that's very important to 
engineering use and which isn't rocket science. What the hell good is a 
faster solution that omits necessary results?

Or a problem I had years ago trying to reconcile two different types of 
dynamic transient analysis in ANSYS. They both produced exactly the same 
displacement vectors but the nodal force listings differed because one 
set included quantities that the other didn't. Bug, feature or 
interpretation? Turned out in this case it was some of all three, and I 
wasted a lot of time figuring out for myself what should have been 
straightened out inside the program. In terms of usability, the ANSYS 
'GUI' which is supposed to improve productivity, simply clutters the 
screen. Command line input is far faster than clicking around trying  
moving palettes and dialog boxes out of the way. This isn't a bug, but it 
greatly affects the usability of the program and it should be cleaned up 
before worrying about a faster solver or parallel processing.

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