Joseph H. Rosevear <joe@airlink9.hopto.org> wrote:
> ~kurt <actinouranium@earthlink.net> wrote:
>
>> I haven't come across documentation for engineering analysis code that
>> was of much good for anything, other than code that was written in the
>> 80's or (much) earlier
>
> That's when our code was written.

The one I can think of with the best documentation was written in the
60's. The primary algorithm descriptions are excellent, and were all
part of the milestones that had been budgeted for in the initial development
of the software. They had some really smart people back then.... In the 80's,
they actually created a large set (volumes) of instructional documents.
This application is more of a modeling language, and really requires
a lot of instruction to become proficient in. It is hard to learn, but
very powerful, and there does not exist a GUI driven application that can
even begin to compare to it even to this day.

> Say you've got a collection of engineers who use a collection of
> software. How are they going to do it? Likely someone is in charge of
> each piece of software, but the average user may not know what software
> is available, who is in charge, where to find it, or how to make it go.
> Together, these things formed most important documentation for the
> software we used.

We have this very situation for my current project. The code has roots
back to the 60s, and the applications came to be in the late 80's. It
is a GUI driven modeling and analysis tool that has just continued to
grow over the years. It is very powerful, but not well documented. Staffing
has been cut to pretty much nothing, and all money goes to software developers
who don't know a thing about the modeling aspects. There is no formal training
process, and almost no one who "uses" the software realize what it can do.
People are constantly amazed when I show them just what can be done, and then
they ask why all these brand new projects are being created to replace what
currently exists (all the new projects are responsible for the lack of funding
for the current project...).

> Secondary (but also important), was the input file format. Our
> software usually ran at the command line, read input from a file, and
> wrote output to a file. A handy reference (on paper in a dusty
> notebook) sufficed to define the input format, but users needed to know
> where to find the document. For example, "Find the documentation in
> Fred's book case." This document could also give the theory the
> analysis was based on.

The current project is completely GUI driven, taking paremeters from
a large database. Despite being a GUI, there are so many functions, and
options, it is a bitch to use for the beginner (also, you need to have
the engineering or physics background to use it effectively).

The application I really like from the 60's is based on a deck of cards
in, and ream of paper out. Now days, it takes input files, and writes
multiple output files. I've recently seen a sucessful attempt to make
a GUI for this application. However, the GUI more of resembles an IDE
to help one build the input file. That was a really excellent idea -
seems like the future for this application. You can still just "vi" an
input file. But you also have the option to use a development environment
that helps you build the inputs, and feed the outputs to various display
applications. It is really neat seeing a 45 year old application that
is still out there doing what it does best.

> We ran code like SQ5 (did stress, strain and failure analysis for
> composite laminated plates) and BOSOR (did similar analysis for
> Buckling of Shells of Revolution).

Sounds neat - other than what I did in college, I don't do any
structural engineering. A lot of the techniques for that stuff
seemed to be similar to boundary layer analysis done for fluid flow -
finite element analysis and solving nasty diffQs with various explicit
methods. I just have a vague recollection of some of that stuff
(I don't do much low level fluid flow either). For aircraft with
thin walled structures, there were all sorts of assumptions we could make
that allowed us to use various analytic solutions and skip the diffQs for
initial analysis - dang, I really don't remember much of that at all.

- Kurt

~kurt <actinouranium@earthlink.net> wrote:

[snip]

> The one I can think of with the best documentation was written in the
> 60's. The primary algorithm descriptions are excellent, and were all
> part of the milestones that had been budgeted for in the initial development
> of the software. They had some really smart people back then.... In the 80's,
> they actually created a large set (volumes) of instructional documents.
> This application is more of a modeling language, and really requires
> a lot of instruction to become proficient in. It is hard to learn, but
> very powerful, and there does not exist a GUI driven application that can
> even begin to compare to it even to this day.

60's. Wow.

[snip]

> We have this very situation for my current project. The code has roots
> back to the 60s, and the applications came to be in the late 80's. It
> is a GUI driven modeling and analysis tool that has just continued to
> grow over the years. It is very powerful, but not well documented. Staffing
> has been cut to pretty much nothing, and all money goes to software developers
> who don't know a thing about the modeling aspects. There is no formal training
> process, and almost no one who "uses" the software realize what it can do.
> People are constantly amazed when I show them just what can be done, and then
> they ask why all these brand new projects are being created to replace what
> currently exists (all the new projects are responsible for the lack of funding
> for the current project...).

Sad.

[snip]

> The current project is completely GUI driven, taking paremeters from
> a large database. Despite being a GUI, there are so many functions, and
> options, it is a bitch to use for the beginner (also, you need to have
> the engineering or physics background to use it effectively).

Sounds like a big app.

> The application I really like from the 60's is based on a deck of cards
> in, and ream of paper out. Now days, it takes input files, and writes
> multiple output files. I've recently seen a successful attempt to make
> a GUI for this application. However, the GUI more of resembles an IDE
> to help one build the input file. That was a really excellent idea -
> seems like the future for this application. You can still just "vi" an
> input file. But you also have the option to use a development environment
> that helps you build the inputs, and feed the outputs to various display
> applications. It is really neat seeing a 45 year old application that
> is still out there doing what it does best.

I'm with you. Something nice about a simple, file based interface.

[snip]

> Sounds neat - other than what I did in college, I don't do any
> structural engineering. A lot of the techniques for that stuff
> seemed to be similar to boundary layer analysis done for fluid flow -
> finite element analysis and solving nasty diffQs with various explicit
> methods. I just have a vague recollection of some of that stuff
> (I don't do much low level fluid flow either). For aircraft with
> thin walled structures, there were all sorts of assumptions we could make
> that allowed us to use various analytic solutions and skip the diffQs for
> initial analysis - dang, I really don't remember much of that at all.

That's what I understood, although I wasn't good enough with the theory
to appreciate the relationship to fluid flow. Yes, we did lots of
finite element analysis; the program was called NASTRAN. Some of our
runs would produce stacks of fan-folded paper a foot or two high.
Hmmm. I guess we were lacking in computer aided post processing.

> - Kurt

Kurt,

Thanks for the comments.

-Joe