Automatic Hull Variation and OptimizationUsing SNAME’s OpenCalc System

Stephen M. Hollister (M)New Wave Systems, Inc., Jamestown, Rhode Island

SNAME's OpenCalc System is used to show how independent calculation programs can be combined to create new solutions by users without having the source code or writing a line of code. The system is based on a new programming architecture that separates calculations, user interfaces, and data into three separate and openly-defined components. The goal is to separate content knowledge programming skills from user-interface programming skills and to return control for creating new and complex programming solutions back to naval architects from computer specialists. This paper shows how independent computer programs can be combined by users to perform an optimization - something not possible with traditional program design that ties one user interface with one set of calculations.

KEY WORDS: CAD; design; calculations; optimization.

INTRODUCTION The SNAME OpenCalc framework (SNAME 2015) is used to show how three independent calculation programs can be combined to perform non-standard analyses and to automatically search for an optimum hull shape. A modified Lackenby hull variation program is combined with a separate intact hydrostatics and stability calculation program and a separate Holtrop/Mennen resistance calculation program to create one larger calculation that can be automatically run and analyzed by an open Excel macro user interface framework. This optimization sequence is based on one created by the author (Hollister 1996), but now built using the open tool framework of OpenCalc. This framework allows users, not programmers, to combine off-the-shelf calculations together in any combination without having the source code or writing a line of connecting or user interface code.

This new organization shows how naval architecture calculations can be separated from user interfaces to create stand-alone program tools that are easier to develop, have many uses and longer technological lives. OpenCalc defines how others can add in their own calculations that will eventually provide everyone with a large toolbox of calculation components which can be combined by users and not programming specialists in many different ways. A paper written by the author (Hollister 2015) described the OpenCalc framework and showed how any one separate calc program/engine can be analyzed using an open Excel macro framework without any programming. This paper shows how multiple calc engines can be sequenced and wrapped into one larger application without writing a line of code. The open Excel macro code collects the input for any set of calc engines, launches the external calculations, and then reads, analyzes, and displays the results. The user never knows that the calculations are done externally from the spreadsheet and there is no noticeable time delay due to separate external calculations. In addition, it is possible to launch external calculations located anywhere on the web.

In the three program combination described in this paper: Lackenby, Hydrostatics, and Holtrop Resistance, users can easily substitute in a different hull variation calc engine or write their own custom resistance calculation engine. Users could even launch a more complex computational fluid dynamics (CFD) resistance calculation engine located anywhere on the web. This is not an either/or programming architecture. One can still write a custom user interface that is tied to and launches one calc engine. However, the separate calculations can now be used for many other purposes with no extra programming effort. There is no technological or efficiency need to tie calculations to only one user interface. In fact, the traditional solution of tying calculations to one user interface is very limiting. OpenCalc is a new computer program organization that cannot

be implemented using any existing computer system or process. Naval architects will no longer be just “users” of programs developed by others.

SNAME OPENCALC The SNAME OpenCalc framework is built using the generalized Tri-Split Programming Architecture (TSPA) (Hollister 2016) which defines a new programming organization that divides computer program applications into three independent and stand-alone parts: User Interface Frameworks (UIF), Calculation Engines (CE) and open XML text data file definitions (OXML). OpenCalc uses TSPA to define a process for creating calc engines and to define independent XML data formats specifically for the marine industry. This new architecture came about because after 40 years of software development in the marine industry, too many good calculations were lost due to changes in computer hardware and user interface programming. The separation of calculations from any one user interface allows for a long life and many general ways to combine and run separate calculations automatically. For multiple program calculation sequences that might require thousands or millions of search calculations, having one user interface per set of calculations does not work. One needs separate stand-alone batch calculations along with open and industry-standard data file formats and definitions. These industry-specific components are defined and provided by the SNAME OpenCalc system.

The Tri-Split Programming Architecture can best be shown using a triangle to represent the three independent and separately-developed components of its programming architecture (Fig. 1).

Fig. 1 Tri-Split Programming Architecture

Computer experts define and develop the independent and open UIF tools, content experts define and create the batch calc engines (CE), and each industry defines its own text-based XML hierarchy of data definitions built up from basic and open XML definitions of design variables and basic geometry. This separation of knowledge and skills, along with industry data

Hollister Automatic Hull Variation and Optimization Using SNAME’s OpenCalc System 2

standards, is something that has been completely lacking in the computer industry. Traditionally, calculations are developed with attached user interfaces and proprietary data file formats that limit their technological life and flexibility (Fig. 2).

Fig. 2 Traditional Programming Architecture

This traditional approach connects a fixed user interface to each set of calculations along with proprietary data file formats and direct user control over each step of the process. Calculations cannot be reused in other ways and their technological life is limited by changes in hardware and user interfaces. Calculations are also not available for combining together into automated processes without direct user input.

Spreadsheets offer more user control, but the calculations are tied to the grid cells of the spreadsheet user interface and cannot be easily reused or combined. There are no standards for data file definitions for common industry data, and one study (Panko 1998, 2008) has shown that 88% of all spreadsheet applications have errors and are poorly supported.

Fig. 3 New Tri-Split Programming Architecture

With TSPA, the separation of calculations, user interfaces and open XML data formats is used to isolate skills, lower learning

curves, reduce costs, increase flexibility, and provide longer lives for computer components (Fig. 3). TSPA provides new ways to mix and match components without having the source code or expert programmers. One calc engine can have many different and custom user interfaces, and one user interface can launch multiple calc engines. There are standard frameworks of user interfaces and most of them can be provided with open macro source spreadsheet solutions. Spreadsheets make good tools for creating general user interface frameworks. They can easily launch external EXE calc engines, they are cross platform tools, they are updated to meet all new hardware and software environments, and most students start to learn how to use them in middle school. It may seem odd to view them now as facilitating external calculations rather than performing the calculations, but it’s easier and more flexible to put the calculations into separate and reusable batch executable files. Spreadsheets might work well for quick and simple calculation tasks, but there are too many examples of complex calculations that are poorly implemented, tested, and difficult to understand, reuse, or modify.

OPENCALC COMPONENTSTo understand how this new architecture works, one needs to study the individual components: Calculation Engines (CE), Open XML (OXML) industry data files, and open and generalized User Interface Frameworks (UIF). Each can be understood and developed separately and each is geared to the background and skills of different specialists. The calc engines will be developed by naval architects who have programming skills, but not necessarily the general and user interface skills required by computer science experts. The XML defined data structures will be created by industry groups, like SNAME OpenCalc, to create common terms, data definitions, hull geometry structures, and free and open input/output code for everyone to use. Finally, the open/free User Interface Frameworks will be built by computer experts to combine and work with any calc engine and XML data file variable and geometry formats. This split of independent components, skills, and learning curves is something missing in traditional computer architectures. It has become a complex and costly software development domain limited to those who can combine both content and computer programming skills.

Calculation Engines (CEs)Calculation engines are stand-alone batch programs that have no user interfaces. They read a standard and open XML text file of input variables and geometry, perform simple or complex calculations, and then write an open XML text file of results. They are written with no one use or user interface in mind and they can be written using any programming language. They do not have to be written in the same language as the user interface code. They are programs that can be launched all by themselves or automatically opened by general Excel macro-driven

Hollister Automatic Hull Variation and Optimization Using SNAME’s OpenCalc System 3

spreadsheets, custom user interface code, or they can be combined and launched by other standard and open user interface frameworks in any automatic process. This is not possible with traditional applications that tie one user interface with one set of calculations and a proprietary data file format.

Writing separate calculation programs can be done by naval architects who don’t have expertise in writing complex user interfaces. This is a critical factor that has been overlooked as computer technology has developed - the separation of skills and learning curves. This also eliminates the connection between calculations and technological obsolescence. Calc engines are written and tested separately and they are immune to complex changes in user interfaces and computer and web organizations. Many calculations were made obsolete when DOS changed to Windows and many calculations are being made obsolete with changes to web and cloud-based organizations. This won’t happen with separate and stand-alone EXE calc engines. They are unaffected by those changes and each calc engine can be located anywhere on the web. The data won’t be affected because they are built using simple and open XML text files, and many user interface frameworks that launch the calc engines won’t change because they are built using spreadsheets that are updated and adapted independently as technology changes.

Programmers can add on their own custom and traditional user interface front ends and users can customize the open spreadsheet-based interface frameworks that launch CEs. For example, a naval architect could make a copy of the general UIF spreadsheet that launches a damaged stability calculation to add in special downflooding criteria formulas for one particular vessel. One does not need the source code of the calc engines. The added calculations are put into the open spreadsheet front end. A naval architect might create a new copy of a spreadsheet front end for different formulas needed by each new vessel, and tie the results to other open tools such as Microsoft Word and PowerPoint. If some calculations have to change, the new results could be automatically fed into the final report in Word.

Stand-alone calculations can be used in many other ways. It simplifies and separates programming and provides a larger and more flexible market that will drive the development of both open and proprietary calc engines and solutions. Naval architects can create their own calculation tools without having expertise in complex user interface and data file input/output programming.

A calc engine simply reads in a set of input variables and geometry from a text file, performs some calculations, and then writes the results to an output text file. Input and output data are defined in a common, industry-standard way using pre-defined XML tags. This allows all calculations to easily pass common design information defined by SNAME’s OpenCalc system.

Open XML Data File Definitions (OXML)Historically, software developers defined proprietary (and often binary) data file formats for individual program use. This makes it difficult to share data between functionally related industry software. The solution has often been to define neutral data file exchange formats. This adds two steps to the process - translation to the neutral file format and translation to another proprietary format - and it can cause loss or improper conversion of data. This can be seen in the CAD world with DXF and IGES neutral file formats. STEP/AP and ISO 10303 design formats are more carefully defined, but are complex and have translation error potential for conversion to and from the ISO neutral file formats. In addition, there are high documentation costs and no open/free input/output code. This makes sharing and transferring design data non-automatic and difficult at best. TSPA changes that to make all data file definitions open/free and all input/output code open and free. the goal is to make it simple for anyone to provide compatible and flexible components using common data.

TSPA provides all of the open XML data schemas for low-level and industry-independent program variables and geometry. It also provides a framework to create higher level industry-specific variable and geometry data structures. On top of the base level TSPA XML data definitions, SNAME’s OpenCalc implementation creates open and marine-specific XML schemas that define data such as hull shapes and compartment subdivisions. It also provides a consistent definition of all common design variables and ship operating conditions - something not currently available. Industry data needs to be defined by each industry, not independent software developers in an incompatible and hit or miss fashion. There should be no neutral data file conversion issues. This can be done using XML data file schemas in a way that allows software developers (and users) to add in their own custom tags as necessary. Open/free I/O software will be provided that reads and writes standard industry data, but passes along any additional custom data tags. XML is a text file standard that allows both standard and custom data definitions in one file. There is no need for both proprietary and neutral file formats. Industries only have to assert control over their own data.

The biggest example of industry control over common data is the use of HTML (which is evolving into an XML standard) by web software. Each web browser and HTML processing program does not define its own data file format with neutral file conversion tools. They all use the same industry-defined HTML web display schema and set of tags. HTML files are text files that can be viewed and edited using any simple text editor by anyone. The definition is open for anyone to learn, use, and modify. No conversion between proprietary formats is necessary. A number of industries have taken up the challenge of defining their own set of XML schemas for their data. HTML has shown that there are no time and size delays of transferring text files over the web with modern computers, processing speeds, and bandwidths.

Hollister Automatic Hull Variation and Optimization Using SNAME’s OpenCalc System 4

In the marine industry, there are different levels of design information. Most of the focus in the past has been on defining neutral AP/STEP/ISO formats for transfer of data between independent and proprietary detailed CAD design programs. This may be reasonable for shipbuilders who rely on one specific CAD software to handle every detail of construction geometry, but it does not work for conceptual and preliminary design data, geometry, and tools that have to work across many different CAD platforms, design offices, and calculation tools. Conceptual and preliminary design programs and tools need standard and open variable and geometry definitions that do not require neutral translation between proprietary systems. In addition, early stage design data definitions are not necessarily simplified construction level definitions.

In early design and analysis stages, marine industry standard data files need to include an agreed-upon set of variable definitions, such as Length Overall (LOA), Beam, and Length on the Waterline (LWL). The next level is the grouping of variables and loading conditions into different operating conditions, such as “Light Ship” and “Full Load.” Other open XML definitions would be geometric ones that define hull and compartment shapes using stations, polygons, or NURB surfaces. This data and geometry cannot be defined as a subset or simplification of complex AP/STEP/ISO neutral file definitions of detailed construction data and geometry. Computer tools and file definition needs change dramatically between conceptual/preliminary design and detailed/construction design.

After 40 years, there is still no one marine industry standard file definition for conceptual and preliminary design and analysis. This is a major hindrance to developing common and low cost design and analysis tools. SNAME’s OpenCalc system, however, is beginning to define industry-standard variable and geometry definitions and to provide open/free documentation and input/output source code. The goal is to provide free and open data definitions so that everyone can provide their own solutions to one common set of tools. Marine design and analysis tools should not be controlled and driven from the top down by just a few large independent CAD companies. That divides an already small market and limits new calculations and integrated design tools.

Industry-defined (OpenCalc) data is being defined because neutral file translation of separate proprietary data has not worked. Independent software developers might resist working with open data because private formats appear to provide a market advantage. However, common data and file formats will lower the cost of software development and get more people involved and focused on one common market, not split between separate CAD program-centric markets. This will benefit everyone by providing one open and integrated solution for all. The long term solution is not to hope that one proprietary CAD program will win the market share battle and force everyone to

write calculations that only work with that software. Instead of writing custom calculations for each separate CAD program, OpenCalc provides tools that allow simple independent calc engines to be tied to any CAD system in a standard fashion.

User Interface Frameworks (UIF)Many programming solutions fit common user interface formats or frameworks. Each calc engine reads input variables and outputs results variables. A simple one might read vessel dimensions and target speed, calculate hull resistance and horsepower, and then output the results. A more complex one might read in a 3D hull shape, perform a computational fluid dynamics (CFD) flow analysis, and then output resistance and horsepower results variables. All calc engines do the same sorts of things: read input variables and geometry and write output variables and geometry.

The user interface processing needs are common for all calculations: display the results for one set of input variables, display a table or graph of varying one independent variable, display a table or 3D contour graph of varying two input variables, and searching for an optimum results or merit function variable. Previous work (Hollister 2015) showed how a common open/free spreadsheet can launch any one external calc engine without writing a line of code. All that the spreadsheet front end needs is a definition of each input variable and output variable. This is provided in a simple text file in a standard XML text format that accompanies each calc engine executable program. It is a standard way to tell other tools how to use any calc engine.

In general, all calc engines look like the following (Fig. 4), which reads in a set of Xi input variables and outputs a set of Yj output variables.

Fig. 4 Generic Calc Engine Processing

There are many standard ways to process and analyze calc engines that can be done using generic and open UIF spreadsheet frameworks. There is no need for a custom user interfaces. One might be provided for a calc engine to meet special needs, but it won’t be necessary. Most customizations can be applied to copies of the standard spreadsheet front end.

This paper shows how one can wrap multiple calc engines together to create one larger calc engine with its own superset of input and output variables. A wrapping tool looks at individual

Hollister Automatic Hull Variation and Optimization Using SNAME’s OpenCalc System 5

calc engine I/O variable files to see how output variables and geometry can be automatically mapped as input to follow-on calc engines. It consolidates them all into one overall set of inputs and outputs producing a standard wrapped calc engine I/O definition file. A generic sequencing calc engine will then act like a single calc engine for use by the standard user interface framework, and it will handle the launching of each calc engine and the passing of data between the individual calc engines. The example used in this paper links a modified Lackenby hull variation program with a stand-alone hydrostatics program and a Holtrop resistance program. Input data and hull geometry get passed into the Lackenby hull variation program and the new hull shape gets transferred to the hydrostatics program, but only the results of the hydrostatics program and principal dimensions of the hull are read into the Holtrop resistance analysis program. This is a generic and open tool that can be applied to calc engines from any source as long as it follows the rules of defining all input and output variables and uses standard XML industry file definitions.

The general calculation spreadsheet is just one open UIF solution. There are many others, such as one that solves any free-body diagram (FBD) problem where all forces and moments are calculated externally in calc engines. This balance of forces and moments is used by calculations such as sailboat Velocity Prediction Programs (VPP). If implemented with a FBD UIF spreadsheet framework, users could easily add in a new or replace an old force or moment. They would not have to have the source code for all parts and would only have to program and test their own calc engine. One could replace the empirical tank test (Delft III) data for resistance of a hull with a more accurate CFD analysis.

A different UIF framework could be one that compares two common calculations. If a user makes a modification to a calc engine (or wrapped set of calc engines), then this UIF could run both calculations and graph the two results side-by-side automatically without writing custom code or running them separately and then trying to combine separate results.

Another UIF could be one that offers on-board stability analysis for any industry standard XML definition of hull and compartment shapes. It would launch a stand-alone damaged stability calc engine and then provide a spreadsheet dashboard display of all results. Since it is a spreadsheet application, naval architects could make a copy to add in their own customizations and tie it to just one hull definition. One could also add in calc engines that collect tank or structural sensor data.

Standard and open User Interface Frameworks are a way to use calc engines in standard ways without writing any code. However, one can still write custom user interfaces that launch any combination of external calc engines.

CALC ENGINE WRAPPINGThe key new work developed for this paper is to provide tools that combine or wrap multiple independent calc engines into one larger and equivalent calc engine (Fig. 5). This requires two parts: a program tool that maps the outputs from one calc engine to inputs for another, and second, a processing executable that launches each calc engine in sequence and passes the needed output from one program to the next using a standard XML data file. The wrapped calc engines are then treated exactly the same as one calc engine and the wrapping process produces an overall input/output XML definition file. This allows the wrapped sequence of programs to use the same open UIF frameworks as single calc engines.

Fig. 5 Calc Engine wrapping Sequence

Wrapping is made possible by the standard input/output XML file variable definitions for each calc engine and the standard XML file that contains the low level variable data, along with the open code that allows all calc engines to read and write common data without the need for neutral file translation definitions and human intervention. The overhead of reading and writing text files is minimal compared to the calculations that are done. With the advent of solid state drives and modern buffering, the time delay is not a factor. For the UIF that launches only one external calc engine, this could be done many times in a row as one or more variables are varied automatically, but there is no delay and the user has no indication that the calculations are done outside of the spreadsheet.

One of the issues of transferring data from one calc engine to the next is units compatibility. Each calc engine may be created to allow for fixed or variable units, but the XML files that contain the data will contain data with specific units, like feet or meters. However, the open input/output code will automatically translate the units to those required by each calc engine. This allows the calc engine writer to create a program that only uses one set of units. Different user interface frameworks can offer different sets of units and the I/O code will automatically convert the units on the fly.

This wrapping process opens up enormous possibilities for users. The author received a call from someone who developed an automatic hull generator inside of a general CAD program

Hollister Automatic Hull Variation and Optimization Using SNAME’s OpenCalc System 6

that had to be manually fed into a hull mesh generator, and then manually fed into a CFD flow analysis program. He wanted to automate the process to search for optimum hull shapes, but it couldn’t be done without very expensive custom programming. It would also require all of the source code or a process that custom-connected separate batch executable programs. Those batch programs don’t exist in most cases. That’s what OpenCalc provides in a stand-alone and open organization that everyone can use without the cost of custom programming. One can write a custom hull generator CE and easily use it in place of the Lackenby CE described in this paper. One can replace the Holtrop resistance calculation with a CFD analysis by inserting a hull meshing CE into the sequence. All of the UIF control software is open and free.

CALC ENGINESThere are three independent executable calc engine programs used in this paper. The first one (Lackenby) applies a modified Lackenby hull variation technique (Hollister 1996) that reads a parent hull defined using stations and changes its shape based on user target input values such as length and longitudinal center of buoyancy (LCB) location. The second calc engine performs hydrostatics calculations using the modified hull stations to produce input for the third independent calc engine that calculates hull resistance using the Holtrop/Mennen calculation technique. Each calc engine is described in more detail below. Note that when each calc engine is developed, it is tested, validated, and set into a fixed executable format that needs no further testing when it is combined or wrapped with other calc engines. This is a key element of TSPA and OpenCalc - long shelf lives for validated and reusable calculations.

Modified Lackenby Calc EngineThis standalone calc engine is based on the Lackenby approach (Botting 1967) for hull variation as modified in the paper (Hollister 1996). The modification adds in additional variables and repeats the calculation to search for a match to all input target shape values while maintaining either a constant displacement or a constant draft (Fig. 6). This modification generates hull shapes that achieve all target input values. The input and output is a hull defined using stations. Note that this is based on a very old technique that is still not available for common use. OpenCalc attempts to change that.

The Lackenby calc engine reads an XML data file containing the hull defined using stations and variables that define the target principle hull shape dimensions.

Fig. 6 Modified Lackenby Variation

The process of hull variation produces a derivative hull from a parent hull by specifying new values for any of the following major parameters:

1. Length of the waterline (LWL)2. Beam of the waterline (BWL)3. Depth of the boat (Depth)4. Draft (T)5. Displacement (Disp)6. Prismatic coefficient (Cp)7. Longitudinal center of buoyancy (lcb)8. Parallel middle body - forward (Pfwd)9. Parallel middle body - aft (Paft)10. Midship coefficient factor (Cmfact)

Because many of these parameters are interrelated, the designer must choose whether the calculations are done for a fixed draft or for a fixed displacement. The variation search will continue until all other target input values are met. This allows the user to examine the sensitivity of individual variables.

Hydrostatics Calc EngineThe Hydro Calc Engine (provided free with the SNAME OpenCalc system) calculates intact hydrostatics and stability information for any heel and balance condition for a hull defined using stations. This station definition is compatible to the SHCP and GHS station definitions. Given one of the following input choices - draft & trim, draft & LCG, displacement & trim, or displacement & LCG - the calculation

Hollister Automatic Hull Variation and Optimization Using SNAME’s OpenCalc System 7

will search to find the balance condition. If a non-zero heel angle is given, the program will search for an upright displacement and LCG, and then use those values to balance the boat at the input heel angle.

This calculation is a common need and the calc engine is expected to be used with many large-scale wrapped problem solutions. It is based on code that has been developed and tested over the last 30 years. It can provide many needed values for follow-on calculations, such as LCB, wetted surface, and half-angle of entrance of the LWL for any balanced and heeled condition. Work is also being done to create a full damaged stability calc engine version.

This hydrostatics and stability calculation can also produce station information (Figs. 7 and 8), but that not used in this wrapping analysis.

Fig. 7 Sample Hydro Calc station results

Fig. 8 Other output from the Hydro Calc single UIF

Since calc engines do not know how much or how little is needed by other calculations, they output everything to an XML data file and it’s up to the wrapping tool to pick out and pass

along only what’s needed. If these extra calculations cause a speed problem for large calculations, one could create two different versions of a calc engine or include an extra input switch to limit the calculations.

Holtrop Resistance Calc EngineThe Holtrop Calc Engine (provided free with the SNAME OpenCalc System), calculates the resistance of a displacement ship hull that may include a bulbous bow (Holtrop and Mennen 1982, Holtrop 1984). Figure 9 shows a spreadsheet list of input.

Fig 9. Speadsheet display of Holtrop input

The Holtrop/Mennen resistance calculation is an empirical one that is based on hull information such as LWL, displaced volume, and wetted surface. Much of the input data is passed from the Hydro Calc Engine to the Holtrop Calc Engine automatically.

Hollister Automatic Hull Variation and Optimization Using SNAME’s OpenCalc System 8

Fig 10. Speadsheet display of Holtrop output

The calculation outputs all of the values defined in the original papers (Fig. 10).

Once the three programs are wrapped into a single calc engine, any of the results can be printed or plotted. Since the controlling UIF is implemented using a spreadsheet, a user can add in additional calculations or generate any other output offered by the spreadsheet. Open spreadsheet front ends provide much more user flexibility and customization than can be provided by proprietary user interface front ends.

USER INTERFACE FRAMEWORK ANALYSISOnce the three separate calc engines are wrapped into one larger calc engine, it can then be used by any of the standard one calc engine UIF frameworks. The UIF one calc engine framework presented in the previous paper (Hollister 2015) will be modified to cover all of the following standard analyses.

1. Given a set of input Xi, calculate the Yj results2. Build a table of Yj given changes to any one Xi

3. Add custom Yk functions based on Xi and Yi results4. Plot any Yj or Yk versus any Xi or Yj

5. Interpolate plots at any ordinate or abscissa6. Find max, min and areas under curves7. Search for iterative solutions8. Build a table given changes to any 2 or more input Xi

9. Plot 3D contours of any Yj or Yk vs. 2 independent Xi

10. Find max, min and volumes of 3D surfaces11. Define custom merit functions12. Search for the max or min of a merit function

The purpose of this paper was not to show an optimum hull shape given a parent hull, but to show how the SNAME OpenCalc system works and how others can wrap separate calculations together to perform their own analyses and optimizations without writing any custom code or even having the source code.

In designing an open UIF that can do optimization, more questions were raised, such as what information is needed for an optimization in general? It isn’t just the one set of input variables that produces the best merit function value. One might want to know a domain of input values near the optimum that are within 5 percent of the best result. One might want to study how each variable or two variables affect the optimum value. Some of these things can be done using the existing UIF framework - plot any result versus single or two variable changes. The standard UIF calc spreadsheet can produce graphs or contour charts for any variables. As this open and free UIF tool evolves in the future, it will contain more analysis tools, and it will be in a spreadsheet form that anyone can customize. Users can add their own merit function into the spreadsheet or they can add in an extra calc engine that might perform a complex cost analysis to use as a merit function.

CONCLUSIONThis paper demonstrates the ability of SNAME’s OpenCalc system to wrap any set of external calc engines together for use as one calculation by standard and open User Interface Frameworks. These are open/free spreadsheet-based tools that perform many combination analyses and optimizations defined by users without having the source code or even writing a line of code or script. This is something that cannot currently be done by any system.

There are many pieces to this puzzle, but the development effort and knowledge are split into separate and encapsulated parts. Naval architects will create the batch calc engines (CE), computer science experts will create common and open user interface frameworks (UIF), and Industry groups like SNAME will use the open XML tools to define standard variable and geometric file definitions (OXML). Keys to this work are the industry-defined and open XML data definitions for variables and geometry that let all of the pieces work together in a standard fashion. As discussed, these data definitions have to be defined specifically for conceptual and preliminary design and not as a subset or scaled down versions of ISO and detailed design “neutral” translation formats.

Once the data definitions are set and open/free XML data input/output code is made available, then it will be easy for naval architects to add in their own set of calc engines. This was difficult and costly before because of changes in user interfaces. The author has propeller optimization calculations for

Hollister Automatic Hull Variation and Optimization Using SNAME’s OpenCalc System 9

Wageningen and Gawn-Burrill series that never justified the conversion cost from DOS to Windows. It will now be easier to separate the calculations and to create a calc engine that can cost less and have a much larger market. This will apply to all legacy code attached to dead-end user interfaces. The old code can be pulled out and left in the original programming language rather than updating it to a modern one driven by the needs of a user interface.

OpenCalc offers a finished system structure and not just standards and components. As each new calc engine is finished and the standard XML text file definition of the input and output variables and geometry files is created, it can be immediately linked to the standard open UIF framework for analyzing one calculation and also tied into OpenCalc’s “Marine Design Executive” (MDE) spreadsheet that displays a list of current calc engines. In the MDE spreadsheet, one can access the abstract and documentation for each calc engine and the user can launch the UIF spreadsheet to run those calculations. This tie-in to the UIF framework and the MDE is done by editing simple text files. In other words, once a new calc engine is completed, it can be immediately launched and used with no additional software coding.

The OpenCalc system currently offers four free calc engines: intact hydrostatics and stability, simple planning boat horsepower calculations with full calc engine source code, a full “long-form” Savitsky planing hull resistance calculation, and a Holtrop ship resistance calculation. The first exposure to the OpenCalc system will be as a user. It looks like a spreadsheet based collection of calculations. However, it is hoped that many will continue on to learn more about the organization and to add their own expertise to a common and integrated set of conceptual and preliminary design tools.

FUTURE WORKInstead of waiting for a full set of marine design software tools to come from independent software vendors, SNAME is taking control over standards and data definitions that will allow everyone to contribute to a common and integrated solution. It is clear that after 40 years the marine industry cannot rely on the market to provide a proper path and set of conceptual and preliminary design and analysis tools.

The next phase of implementation is education and the building of a broad set of calc engines. These calc engines could be free or they could be sold by software developers. In either case, they can be used as stand-alone programs or mixed in with calc engines from any other source. The hope is that with a common set of tools, many will provide their own calc engines and UIF customizations for free and SNAME can offer a point of download and support.

These calculations will come tied to the standard spreadsheet calculation user interface framework, and a “Marine Design

Executive” spreadsheet is provided to access any calc engine. A user will see the complete list of calculations and can immediately access any of them without knowing anything about how everything works internally. Users can just start the MDE spreadsheet, select a calculation “program” and that will launch the main UIF spreadsheet that provides input fields for the calc engine, launches it automatically, and returns the results.

An online SNAME OpenCalc website will provide a forum and the main access point for all definitions, free/open I/O code and free/open User Interface Frameworks. SNAME will provide support for converting legacy code to this new format, and SNAME will promote its use for university research code, which will be a fast way to turn developmental code into usable tools.

SNAME will also continue the development of early stage design data XML formats. One example is the need for weight data (individual CG and weight distribution shapes) and overall weight curve data. That would allow for common calc engine tools for things like combining individual weight shapes into an overall weight curve, and longitudinal strength calculations (Fig. 11). As it is now, these programs are custom made, costly to develop, and cannot be applied to other uses.

Fig. 11 Longitudinal strength calculation

With a common weight curve definition, it will easier to provide general tools for estimating early design weight curves for different types of vessels and operating conditions. Without standards and common formats, development costs go up and the marine market uses go down.

Hollister Automatic Hull Variation and Optimization Using SNAME’s OpenCalc System 10

SNAME will also put together an open industry hull geometry file library that will offer common hull shape definitions. Figure 12 shows the stations of the SS United States digitized by the author and figure 13 is a NURB surface definition of the Wigley Test Hull.

Fig. 12 S.S. United States

Fig. 13 Wigley Test Hull

Many possibilities open up for computer-aided design and analysis with modern computer speeds and interconnections, but they will only become available in the relatively small marine market if industry organizations work together to define and create common and integrated tools. SNAME’s OpenCalc is the start of that process.

REFERENCES

Botting, M., "Hull Form Derived From Parent" DTMB Report 2328, Feb, 1967

Hollister, Stephen, “Automatic Hull Variation and Optimization”, Presented at the February 28, 1996 meeting of the New England Section of The Society of Naval Architects and Marine Engineers

Hollister, Stephen, “A New Paradigm for Ship Design Calculations”, Presented at the Nov. 2015 WMTC conference http://www.sname.org/project114/home

Hollister, Stephen, “The Tri-Split Programming Architecture”, To Be Published, 2016

Holtrop, J. and Mennen, G., "An Approximate Power Prediction Method", International Shipbuilding Progress, Vol 29, July, 1982

Holtrop, J. "A Statistical Re-Analysis of Resistance and Propulsion Data", International Shipbuilding Progress, Vol 31, Nov, 1984

Lackenby, H., "On the Systematic Geometrical Variation of Ship Forms" Trans. INA, Vol 92, 1950, pp 289-315

NAVSEC, Ship Hull Characteristics Program SHCP, CASDAC #231072 User’s Manual Naval Ship Engineering Center, January 1976

Nowacki, “Horst, Five decades of Computer-Aided Ship Design” Computer-Aided Design, No. 42 (2010) 956-969

Panko, Raymond R., "What We Know About Spreadsheet Errors." Journal of End User Computing's Special issue on Scaling Up End User Development, Volume 10, No 2. Spring 1998, pp. 15-21 Revised May 2008.

SNAME, “Open Source Computing Tools” http://www.sname.org/project114/home, 2015

Woodward, John B., The Computer System Spiral Documentation for the User and the Module Writers June, 1979, The Department of Naval Architecture and Marine Engineering, The University of Michigan

Hollister Automatic Hull Variation and Optimization Using SNAME’s OpenCalc System 11