I have been approached by a colleague from my early NAVSEA days, Dr. Larrie D. Ferreiro, who expressed interest in the early history of SHCP – when / where it was created, who authored, promoted, and maintained the code, etc.? Since he is looking for this background to contribute to his possible follow on book to the initial “Ships and Science: The Birth of Naval Architecture in the Scientific Revolution, 1600-1800 (Transformations: Studies in the History of Science and Technology)“, I thought I’d provide a bit of background and then a portion of a paper presented by the original SHCP author Michel E. Aughey at a SNAME Section meeting in 1968.
The original version of what we call SHCP today was originally developed at BuShips/NAVSEC and was a collaborative effort to provide the Navy and industry with a general naval architecture calculation tool. Like most collaborative efforts, it sufficed until the real requirements could subsequently be defined and the code rewritten to be what it was really intended to be in the first place. Michael Aughey was the singular POC and primary author of the SHCP that was delivered in it’s initial fulsome form in 1972 and distributed as CASDAC # 231072 (23-Oct-1972). Mike had the foresight to develop a tool that used a general and common core of routines to perform the suite of naval architecture calculations required by the US Navy. And while Mike was *very* efficient with his coding (the compact nature of which we more current programmers needed to ‘un-spool’ to understand), it continues to serve as the basis for the much expanded and capable SHCP that is in use today. Mike continued his support and advocacy for SHCP until those new to the Navy took over the continued development and maintenance of the program in the early 1980s.
Below is the initial portion of the 1968 paper authored by Mike, writing the same as he spoke, in his own inimitable style. Apologies for any OCR conversion errors I missed.
SHIP HULL CHARACTERISTICS PROGRAM
by
Michael E. Aughey
(Extracted from a paper presented during the Sept 26-28, 1968 Joint Meeting of the Chesapeake & Hampton Roads Section of the Society of Naval Architects and Marine Engineers)
BACKGROUND
The Naval Architect has for centuries been burdened with exhausting calculations of areas, volumes and centers. He has adopted the tools of the times, as they developed, to aid him in this cumbersome work. Until a decade or so ago his tools were the desk calculator and the slide rule, which he would belabor for days, weeks, or even months on end *1 in the solution of a complex problem.
After this considerable effort had been expended, the answers come out. Now for the checking. Surely even the most careful of men engaged in such work would be hard put to hold his errors to a few in an eight-hour workday. Hence an additional effort was required of a second, equally skilled Naval Architect, this additional effort often rivaling the original.
Development of EDP *2 equipment during the 1950’s gave personnel in various engineering disciplines great hopes for relief from laborious, repetitive calculations. Early machines were small and sluggish when measured by today’s standards, yet were of sufficient capacity and speed to permit man to multiply his efforts by several magnitudes. Those engaged in ship design/shipbuilding who were fortunate enough to gain access to such a marvel proceeded to reduce their daily labors to strings of logical or arithmetic operations which were then coded and fed to the machine as programs.
It was quickly noticed that errors within a particular calculation could be generated at an alarming rate. Moreover, answers which were considered acceptable for one type of calculation for a specific ship more often than not were found to be incompatible with answers for a different type of calculation for the same ship. Errors in the first instance were generally reduced or eliminated by incorporating elaborate checks or more sophisticated algorithms in the programs.
The second type of errors – incompatibilities – were of a more subtle nature, and were somewhat more difficult to correct. These generally arose when separate programs were written by different programmers in conjunction with different Naval Architects. These separate programs required their own unique inputs to describe the hull form, and often performed area, volume and centers calculations in diverse ways, depending upon the personal preferences of the programmers and/or Architects. The results were quite predictable: answers for one calculation did not jibe with answers for the next, since the separate calculations were operating on slightly variant ships in slightly different fashions.
The Computer-Aided Ship Design office of the Naval Ship Engineering Center (then BUSHIPS) undertook in 1964 to remedy this type of discrepancy. A system of programs was designed which would operate on a single, common data base describing the hull form, and which would perform all area, volume and centers calculations for the different types of output programs in an identical manner. The result of this substantial effort, called Ship Hull Characteristics Program, was published and disseminated in June 1966. The system at that time consisted of routines to perform five of the basic Naval Architectural calculations:
- Hydrostatics (Curves of Form and Bonjean’s curves)
- Longitudinal Strength
- Floodable Length
- Limiting Drafts (Load Lines)
- Intact Stability (Cross Curves)
Shortly after the completion of the dissemination of this system of programs to various ship design agents and. shipyards around the country, the telephone calls, telegraphs and letters began to arrive at Main Navy citing errors and shortcomings in the programs, and requesting fixes or patches. Maintenance of the program –providing the fixes – quickly became a full-time occupation. Comprehension of the program at the level required in order to perform this maintenance was difficult to obtain due to the bulk and complexity of the system. Utility of the program suffered due to the fact that it required relatively large amounts of time on large and expensive computers for its operation. Acceptability of the answers was often doubtful. The call was clear: a major overhaul was in order.
*1. An elaborate hand-calculation of Damaged Stability can consume a man-year.
*2. Electronic Data Processing/Pulverizing, depending on the validity of the inputs
BASIC CONCEPTS UNDERLYING THE REWRITE
Early in 1967 a complete revision of the program was initiated. This rewrite was to become an experiment with a personal programming philosophy, the basic elements of which are as follows:
- Make it right(1) – ACCURACY
- Make it fast – EFFICIENCY
- Make it small – ECONOMY
- Keep it simple – SIMPLICITY
Big deal. A quick inspection of this philosophy reveals that it is neither profound nor unique, yet it is rarely observed in practice.
- “Right”, in the parlance of the day, means close enough for government work.
ACCURACY
All too often programs have been distributed for general use without having been given adequate checkouts. This shameful practice has frequently resulted in great wastage of time and money, gnashing of teeth and greying of hair. To avoid this waste and aggravation, ”making it right” must be the overriding element in programming. The assurance of valid answers will come only with the rigid application of elaborate test procedures followed by long hours of hand checking.
ECONOMY OF TIME AND SPACE
Elements of efficiency of processing time and economy of core storage space are of secondary, yet major importance. Both elements in this philosophy are carryovers from small machine days. Efficient use of core (or drum) space was often of paramount importance during the 1950’s and early 1960s in order to fit the problem in the computer at all. Development of coding techniques which would minimize space and time required for execution consumed much of the effort of programmers of the small computers. The payoff from such efforts came when the use of these space/time saving techniques became a matter of habit; the possibility of using less efficient methods simply did not enter the programmer’s mind. The application of these techniques permitted a given computer to perform significantly greater amounts of useful work over a given time span.
A conspicuous decline in the use of these methods seems to parallel the advance in capacity and calculating speed of data processing equipment. Parkinson’s Law reworded to suit this observation might read: “A program expands so as to fill the core space and time available for its execution”. As a consequence of a lack of concern for programming efficiency, many of today’s data processing facilities find themselves overloaded. A revival of the beneficial programming techniques of a decade ago and their implementation in today’s programs would reduce this overload to a degree which would astonish us all.
SIMPLICITY
Simplicity, the last of the elements of this philosophy, is often in conflict with the matter of making it right, is a natural fallout of the concepts of speed of calculation and conservation of core storage. It has been observed that the easy way is usually the best way; sophisticated and devious treatments are generally of greater value if left in the university classroom. Students of the calculus and other forms of higher mathematics will be somewhat underwhelmed by the depth and brilliance of the arithmetic to be found in the Ship Hull Characteristics Program. Second order curves are assumed throughout.
WHY THE STRESS ON EFFICIENCY OF OPERATION?
The Ship Hull Characteristics Program (SHCP) has been referred to since its inception as the Navy’s “bread and butter” program. It has become – in all of its many versions – a program of great utility at NAVSEC and at dozens of ship design/shipbuilding installations around the country. Thus a small savings in execution time to be realized during a single run becomes quite significant when magnified by the number of users times the number of individual problems run by each.
WIIY THE STRESS ON ECONOMY OF CORE STORAGE?
The published version of SHCP was expected to operate on large-scale scientific equipment (univac LARC and IBM 7090). Few of the ship design facilities had ready access to such computers. Hence we can expect that factors of transportation and inconvenience had a damping effect on the utility that such a program might otherwise enjoy. Here’s where the payoff from the economy of core storage comes in: The updated program, containing very little fat, is currently operational on a large variety of computers, ranging from the modest IBM 1130 (8K of 16-bit words with 1 disk) to the mighty CDC 3600 (32K of 48-bit words). Almost any digital computer ls sufficient to nun this program.
FAR-OUT SPECULATION
Considerations of a “blue sky” nature further underscore the requirements for efficiency and economy. The time is not far off when a Naval Architect will sit at an active graphics terminal using the programs available to him in a design mode (as contrasted with the performance mode of operation today). Large programs will be on the inside of immense iterative loops. The need for quick response from each such program is obvious.
PROGRAM STRUCTURE
SHCP is composed of nodular routines, each operating at one of three basic levels:
Level 1 – A minuscule executive (or monitor) routine which reads an identification card and a list of the work to be done, then supervises the performance of this work.
Level 2 – Output programs which read their own sets of data, perform their distinct types of calculations with the aid of Level 3 routines, print out their answers and return control to the executive. The first of these (DESIN) reads various combinations of design parameters (Displacement, LCG, Draft, Trim), calculates the missing parameters, performs initializations and prints out design information. The remainder of the Level 2 programs are those which perform basic Naval Architectural calculations:
- Hydrostatics (HYDRO)
- Trim Lines (TRIML)
- Longitudinal Strength (STRNH)
- Floodable Length (FLNGH)
- Limiting Drafts (LMDFT)
- Intact Stability (INTAC)
- Damaged Stability (DAMAG)
These programs have stand-alone capability; none need be aware of the existence of any of the others. It is a relatively simple matter to add on additional programs to perform other types of calculations.
Level 3 – Working level, or calculation routines which perform all integrations, interpolations and iterations. …
