INCORPORATING AND APPLYING CONCEPTUAL DESIGN TOOLS FOR NAVAL WARSHIPS

INCORPORATING AND APPLYING

CONCEPTUAL DESIGN TOOLS FOR NAVAL

WARSHIPS

Chapter 1

Introduction

1.1 Conceptual Design of Warships

The task of naval architects, both those directly assigned and those supporting the

U.S. Navy, is to continuously analyze and update conceptual design execution

methods to drive the success of future design projects, reduce costs, and maximize

the performance of ships used by sailors. Architects involved in the design of

warships rely heavily on design tools to help them in the conceptual phase. Some of

the most effective design tools combine knowledge gained from successful previous

designs with the latest research and technology, creating a suite of design tools that

can minimize uncertainty. Currently, graduate students in MIT's Naval Construction

and Engineering program use a variety of design tools such as ASSET/RSDE,

Maxsurf Ultimate, POSSE, and others to support warship design. However, there are

problems with these design tools and their ability to contribute to the progress of the

2N program as a whole, rather than just for individual design projects. One of the

main problems is that some of these tools are outdated, with software no longer

supported by their design teams, making them unsuitable for future use as situational

awareness tools. Furthermore, this problem is exacerbated by the need for all design

tools used by 2N to only access design information that can be released publicly and

accessed by foreign students who do not have a U.S. security clearance. These

problems have created gaps in the design tools available to 2N students, and to

address these problems, a new thesis project was developed to implement a new

package of design tools that are not classified for 2N, with the aim of improving the

quality and efficiency of conceptual ship design.

During this thesis project, the search for a new design tool was carried out and

successfully completed. A powerful new platform for conceptual design tools was

identified, adapted for 2N use, and built on top of it. In addition, a new module for

the automatic manufacture of critical engineering components in Rhinoceros 7 using

the Grasshopper plug-in and Orca3d was created. This module assists the design

team with the structuring of vital engineering equipment across the ship's three-

dimensional model, helps assess the feasibility of the design, as well as examines

potential equipment interference within compartment areas and volumetric

constraints. As a demonstration of this design tool and the effectiveness of the new

initial setup tool, a case study of a medium-sized surface combatant ship is included

in this paper.

1.2

2N Design Project 2,705

MIT's Naval Construction and Engineering Program (2N) features a 2.70X series of

naval architecture courses built toward a year-long capstone course (2,705) with the

goal of producing conceptual warship designs. The general design pursued by the

students included many forms of modern monohull surface combatants, although

advanced marine vehicles such as multi-hulls, planing ships, submarines, and

autonomous vehicles were also chosen with great success. In this thesis, the design of

the monohull surface combatant is the main focus and the tools researched and

implemented are also the best performing for the conceptual design of the monohull.

1.3 Design Tools Currently Used by 2N

Many naval architectural design tools in the form of software packages are available

for use in academic settings that can help with conceptual design. Now

The most

commonly used design software in the 2N program is the Advanced Ship and

Submarine Evaluation Tool (ASSET). ASSET is a government-sponsored ship

synthesis package that uses a robust parametric design process offset by

The characteristics of U.S. Navy ships quickly converged on effective ship design.

This tool is particularly useful for designing more traditional monohull warships,

although multi-hull designs and other more advanced marine vehicles are possible

but their effectiveness is limited. 2N students in the past have created their own

design tools to support the design of smaller ships or advanced marine vehicles in

situations when ASSET was deemed ineffective for a variety of reasons. In 2010,

Gillespy found that ASSET was unable to adequately capture and evaluate the design

space for patrol vessels, and created its own design tool to evaluate the marine

maintenance performance of patrol vessels [2]. Als o i n 2 010, K a ra u sed t h e

A SSE T data base ext e nsi vely f o r p a r ame t ric co m p ar i s ons o f s hip

c omp o ne n t s suc h as wei g ht a nd size . [3] He also created a new design tool

for evaluating corvette-sized ships and his work showed the power of having direct

access to accurate databases of known ship systems.

ASSET software is no longer supported by the U.S. Navy, as a Rapid Ship

Design Environment (RDSE) is available that leverages the Leading Edge

Architecture for Prototyping Systems (LEAPS) database to support and create

efficient design architectures. The Formal Object Classification for Understanding

Ships (FOCUS) is a large database of known surface ship data, and is used by

ASSET and RSDE to quickly invoke known parameters to converge on a good hull

design using ship synthesis. [4]. O ne of the main advant ages of LEAP S is

tha t it allows mu lt ipl e de sign tools to c all simil ar da tabases f or

informati on, which inc rea ses eff icie ncy by a llo wing fo r e asie r

int egration of tool s. Fu rthe r design tool s such a s Sm art Sh ip Sys te m

De sign (S3 D) ar e al so bein g deve loped and util ize the LEAPS

database an d wou ld be advantageous to p oten tially incorpo rate i nto

concept ual design pa rts where a more d eta iled initial desig n would

be pos sib le [4]. Further complicating the issue is that no publicly

released version of the RSDE is currently available, although some

interest has been shown by engineers at the Carderock Naval Surface

Warfare Center potentially developing this in the future. Therefore, the

potential

Fully integrating RSDE/LEAPS as the primary 2N design tool is avoided

although the use of edited and case-specific RSDE/LEAPS as the primary design tool

is still possible for U.S. Navy 2N students. Although the ASSET and RSDE analyses

do not provide a clear path forward, they demonstrate the power of the ship synthesis

tool and some advantages of using a trusted and robust database of hull parameters

and ship systems that are known and serve as examples of the capabilities that this

new design tool should bring to the 2N program.

Article 2

Virginia Tech's Navy Concept and

Requirements (C&RE) Tools

2.1

Current Research

Currently at Virginia Tech (VT), a team of researchers under the guidance of former

2N Academic officer and NAVSEA Ship Design Professor Dr. Alan Brown is in the

process

of updating the Naval Concepts and Requirements Exploration (C&RE)

design tool that represents more than two decades of research and development [5].

T h e n e w C & R E d e s i g n t o o l w a s c r e a t e d b y a t e a m o f n a v a l

a r c h i t e c t s a n d s u p p o r t e d b y r e s e a r c h c o n d u c t e d a t M I T a n d

V T t o p r o v i d e a p o w e r f u l t o t a l s h i p c o n c e p t u a l d e s i g n t o o l

f o r w a r s h i p s , c o n v e n t i o n a l s h i p s , a n d o t h e r m o r e a d v a n c e d

m a r i n e v e h i c l e s . T h i s t o o l a n d i t s s u p p o r t i n g d a t a a r e

s u i t a b l e f o r p u b l i c r e l e a s e a n d a r e c a p a b l e o f s u p p o r t i n g

n a v a l a r c h i t e c t u r a l d e s i g n p r o j e c t s f o r d e s i g n e r s w i t h a n d

w i t h o u t e x p e r i e n c e o n n a v a l w a r s h i p s . M o r e t h a n 2 0 y e a r s

a g o , B r o w n w a s p r e s s u r e d w i t h t h e n e e d t o d e v e l o p n e w a n d

u n c l a s s i f i e d d e s i g n t o o l s f o r u s e i n a c a d e m i c s e t t i n g s . I n a

2 0 2 2 a r t i c l e f e a t u r e d i n t h e N a v a l E n g i n e e r s J o u r n a l , B r o w n

d e s c r i b e d t h e c u r r e n t s t a t e o f C & R E t o o l r e s e a r c h a s " P r i o r

t o 2 0 0 2 , t h e o r i g i n a l A S S E T h a d n o t b e e n c l a s s i f i e d a s a D

D i s t r o a n d w a s u s e d i n V T a n d M I T p r o g r a m s , b u t

s u b s e q u e n t l y , i t b e c a m e c l e a r t h a t t h e u s e o f A S S E T / L E A P S

f o r g e n e r a l g r a d u a t e a n d u n d e r g r a d u a t e c l a s s e s a n d p r o j e c t s

n e e d e d t o b e d i s c o n t i n u e d a n d a t V i r g i n i a T e c h w e w e r e

g r a d u a l l y e x i t i n g A S S E T .

curriculum and replace it with our own Concept and Requirements Exploration

(C&RE) tool... These tools have been continuously developed and improved over the

past 15 years supporting research and design under several ONR grants, NAVSEA

funding and the Naval Engineering Education Consortium (NEEC) "[1]. T his

d esc r ip t i on c orr ela t es c l o sely with t h e c urr ent c hal l enge s w i th t he

d esi g n t o ols t hat the 2 N p rog r a m i s t ryin g t o s o l ve, e s pe c i ally t he

n eed t o r emove a nd r e p lac e A S SET a s t h e m ain d e sig n t o o l a n d

c ond u ct a ll f urth er r es e a rch at a n u n cla s sifi e d l e vel.

C&RE's suite of design tools was heavily influenced by ASSET during its

creation as its founders were trained at ASSET at MIT and through other avenues of

naval service and research. Many of the research team members are also 2N

graduates which greatly increases the likelihood of successful collaboration between

VT and 2N on future projects. The weaknesses and limitations of ASSET in an

academic environment were well understood and improved during the creation of

C&RE tools and eliminated many of the frustrations that design teams face today

when using ASSET as a primary design tool. Naval architects using C&RE have

more control over the total ship design process including utilizing proven processes

to create and compliment design spaces that are then fully integrated into the

synthesis model. This is very much in line with the current syllabus of the 2.702 and

2.703 2N courses, and creates an opportunity for a more uniform process for creating

and exploring design spaces for new naval vessels. The high level of automation in

ASSET severely limits the designer's ability to fully understand the decisions made

when a button is selected or a parameter is selected. C&RE gives this control back to

the design team with reduced automation.

After much coordination between the leadership of the MIT 2N and VT naval

architecture programs, the decision was made to pursue the implementation of the

C&RE tool package for use by 2N in the hope that the continued collaboration

between the two naval architecture programs will continue to make the C&RE tool

the primary unclassified design tool for naval warships and will be used for many

years to come. This decision was further supported by naval leadership in NAVSEA,

the Office of Naval Research (ONR), the NAVSEA Carderock division, and the

Naval Surface Warfare

The Dahlgren Center increases the support and future growth

potential that the C&RE tool package can experience through implementation in the

2N program.

2.2

C&RE Tool Design Process

The C&RE design process is characterized by two important phases of design:

Concept Exploration and Concept Development. Throughout this phase the

important steps of this process can be further characterized as the creation of Logical

Architecture, Physical Architecture, and Operational Architecture. Through this

phase, the total ship system is designed and incorporated into the synthesis model. A

three-dimensional hull model was developed, designed, and evaluated using a total

ship synthesis approach with embedded feasibility analysis, Overall Measure of

Effectiveness (OMOE) analysis, and overall measure of risk (OMOR) analysis.

There are two common ways to approach total ship synthesis, namely the "inside-

out" or "outside-in" method. "Inside out" refers to a strategy in which the design of

the ship's systems and subsystems is completed first, followed by the synthesis of

designing a hull capable of supporting all of these ship's systems. The "inside and

out" method refers to the completion of the hull design first, and the ship's systems

and subsystems are built within the limitations of the hull through synthesis. Both of

these methods have proven to be successful. Brown describes the C&RE approach to

ship design as an "outside-in" approach, meaning that the ship's systems are designed

in parallel with the hull design and synthesis combines these processes to converge

on an acceptable outcome [5]. The 2-1 below represents the 19 steps of the C&RE

process. The remainder of this chapter will summarize the high points of this process

with a greater emphasis on concept exploration (steps 1-8) and how this process

applies to the design of warships in the 2N program.

The following flowchart represents the 19 steps of the C&RE Design process.

Figure 2-1: C&RE VT Design Process [1]

Steps 1-8 in figure 2-1 shown above represent an exploration of the concept. An

initial capability document (ICD) is the first step of the process and this document is

created by the design team, usually after reviewing the project sponsorship

requirements while also including the child requirements. The creation of the ICD

was the first step in the 2,705 design project. For some naval officers, such as

experienced submarines now designing surface ships, or the opposite situation,

further research into the capabilities of the current U.S. Navy or foreign platforms

will be necessary to accurately create an ICD. Creating a Concept of Operations

(CONOPS) document can help the design team to visualize the operational mission

that must be completed, and refine the requirements in the ICD.

Throughout the Concept Development, comparative naval architecture and

parameter size calculations are carried out to create a first look at the potential design

space. Also during this phase, it is important to consider the additional systems that

may be installed, the associated sizes, and how these systems will be able to achieve

the requirements and objectives outlined in the ICD, CONOPS, and

also other requirements that have been set by the design team's industry sponsor. The

relationship between the ship's system and mission achievement is simple and is

marked by figure 2-2 below.

Figure 2-2: Ship Systems for Mission Achievement [1]

Navy officers in the 2N program generally have a strong understanding of how

ship systems interact and the fact that many different architectures and system

components can achieve the same mission objectives. This is why parametric sizing

and outside research can be very helpful during this design phase to understand the

variance in size, weight, and power requirements for different combinations of

systems. Typically, the system hierarchy is set and the best-performing system can be

considered a "wish list" for the design team. This may include new cutting-edge

naval systems that are still under research and development that are expected to work

at a high level. Integrating this system into design at the academic level is very

common. Incorporating new technologies can be a difficulty using a program like

ASSET, but the process is very easy using C&RE tools. This gives 2N students the

ability to pursue nontraditional design projects that may have had too much

uncertainty in the past, or there is no clear way to complete design validation or

verification definitively beyond careful calculations for weight and power

requirements. This type of design decision-making is accommodated during step #3,

Mechanical Power and Energy System (MPES) design.

This initial system design was incorporated into a model of the ship's synthesis later

in the process to help explore the design space. After completing the ICD, initial size

calculations, and related comparative naval architecture designers can now move

their work to the Model Center to continue the C&RE process. Figure 2-3 below

shows an overview of the Model Center workspace, and the separation of modules

based on synthesis, hull exploration, and initial setup. The left side (synthesis) of the

Model Center workspace is described as Concept Exploration, while the right side

(Hullform Exploration/Initial Settings) is named Concept Development [1]. To

ach iev e t otal shi p syn thes is, each mo dule mu st be co mp leted by t he

desig ner.

Figure 2-3: C&RE process in the Cen Modelter[1]

In its basic configuration, the VT Ship Synthesis Model (SSM) represents the

MPES of a medium-sized surface combatant and represents a new design for a U.S.

Navy frigate or similar-sized vessel. This information represents an excellent

baseline when starting a design and can be easily scaled to represent surface

combatants of various sizes or hull shapes. Inside the synthesis model there are

separate Excel worksheets for Design Variables (DV) and Design Parameters (DP),

combat systems, mechanical systems, propulsion systems (PSYS), electricity,

Overall Effectiveness Measures (OMOE), Overall Risk Measures (OMOR), and

others. This worksheet can be modified by the design team to more accurately

represent the design capabilities intended for the purpose of incorporating all known

critical engineering and combat systems

into the synthesis model. By completing this

step, the design team can feel confident moving forward that the output of the

process will result in a design that is capable of fielding all of the ship's systems of

interest and can meet the project's performance objectives. The SSM can also be

modified to incorporate all Combat systems for the ship's design. Combat system

information is entered into a separate Excel worksheet for each area of warfare in the

SSM organized by area of warfare. Each worksheet for areas of warfare such as Anti

Air Warfare (AAW), Anti Surface Warfare (ASUW), Anti Submarine Warfare

(ASW), Command Control and Communications (CCC), and air operations is

updated accordingly and systems intended to operate together such as SPY radars

and VLS are grouped and labeled as discrete variables set by the design team. The

worksheet of each area of warfare has all the combat systems related to the Vital

Components (VCs), such as weapons, launchers, sensors, and subsystems, which are

listed and regulated by the weapon or combat system concerned. Individual combat

systems Vital Components (VCs) are included in each variant of the relevant Combat

Systems Equipment List (CSEL) and can be modified as needed to accurately

represent the variant in question. Several combinations of systems and equipment are

built by the design team and are numerically listed under each area of warfare as

potential options to incorporate into the design. Each combination listed accurately

takes into account all weight, space, and power requirements for all associated

equipment. Table 2.1 below is an example of the combat system options available in

the SSM for medium-sized combatants.

Table 2.1: Configuration of Synthetic Model Combat Systems

Currently the SSM propulsion system (PSYS) worksheet has 8 different options

for propulsion types and covers the most common warship propulsion configurations

including various configurations of Integrated Propulsion System (IPS), Combined

Diesel and Gas Turbine (CODAG), Combined Gas Turbine and Gas Turbine (CO-

GAG), and Hybrid Electric Propulsion (HED). It is up to the designer to determine

which type of PSYS best suits their design goals, and whether a particular type of

PSYS is not feasible and should be removed from the design space. Some of the

factors that should be considered can be weight requirements, maximum speed,

endurance range, acoustic signature, space constraints, electrical power requirements,

and others such as sponsorship requirements for specific propulsion generator

configurations. The PSYS worksheet also requests a database of engineering

equipment from the Mechanical Equipment List (MEL). An example of a PSYS

configuration is provided below in table 2.2. T h i s i s n o t a n e x h a u s t i v e l i s t

o f V C s i n e v e r y c o n f i g u r a t i o n , a s t h e r e a r e m o r e t h a n 2 0 0

i t e m s f o r e a c h t y p e o f P S Y S .

Table 2.2: PSYS Configuration of Synthesis Model

Research completed by CAPT Thomas Trapp (2015) and Mark Parsons (2020)

created dynamic architecture flow optimization (DAFO) where the mechanical VC

size is further optimized based on the ship's DP and DV which provides more

accurate weight parameters and component sizes for each PSYS category to quickly

and accurately scale components to the right size based on the vessel design [1].

T h i s e n s u r e s t h a t t h e V C c h a r a c t e r i s t i c s f o r e a c h t y p e o f P S Y S

a r e a c c u r a t e a n d s a v e s t h e d e s i g n t e a m f r o m t h e t a s k o f p r o p e r l y

m e a s u r i n g e a c h V C f o r t h e d e s i g n , w h i c h w o u l d n o t n o r m a l l y b e

c o m p l e t e d a t t h e c o n c e p t u a l d e s i g n l e v e l .

This design work is very similar to the current process used by 2N students to

update the P&A ASSET table to represent the weight, size, power, and location

information of the VCG for the main components. This is done manually in ASSET

without any form of optimization and needs to be completed before running the

synthesis. C&RE's ship synthesis tools give users more control over the architecture

of the total ship system and the ability to quickly create dirty ads or refine models

without changing unwanted parts of the design. Navy officers who have served

hundreds of hours in engine rooms and combat systems suites greatly benefit from a

higher level of control over the architecture and capabilities of the ship's systems. By

using previous experience, stronger and more accurate decision-making is possible

during the C&RE synthesis model update process. By maintaining a higher level of

control over system-specific marking decisions, the design team can also greatly

increase the likelihood that errors or unintended consequences are discovered much

earlier in the design process, demonstrating a clear advantage over designs in ASSET

where control is much more limited.

The hull shape design process (#4 in figure 2-1) applies the Design of

Experiments (DOE) approach to create a design space based on the DV of

continuous hull shapes such as Overall Length (LOA), Length to Beam Ratio (LtoB),

Beam to Draft (BtoT) ratio, and other Orca hull shape parameters such as

Longitudinal Prismatic Control, Deadrise Mid, Fwd Fullness, and others that will not

be explained in more detail. In order to limit these variables to create an effective

design space for warships, many known designs were reverse-engineered and fit

models were recreated in Orca to show an acceptable range for hull shape parameters

[6]. T h i s m a t c h i n g m o d e l h e l p s d e s i g n e r s t o a c c u r a t e l y i n s e r t

D V i n t o M o d e l C e n t e r , a n d t h r o u g h t h e u s e o f R h i n o s c r i p t

c o d i n g , M o d e l C e n t e r c a n i n t e r a c t w i t h R h i n o / O r c a 3 d f o r f a s t

h u l l c r e a t i o n .

Figure 2-4: Rapid Hull Manufacturing Center Model using Rhino/Orca3d

This link allows the experimental design to be executed in the Model Center

using Latin-Hypercube or a similar process, chosen by the designer. This allows the

design team to visualize the design space of approximately 200 or more runs and

their impact on resistance and power, hydrostatics, and stability. Histograms can be

used to limit DOE response data, and the effects of continuous variables on responses

can be visually identified, which can guarantee potential changes to the design space.

The figure below shows an example where the constraint is placed at the height of

the metacentric to the beam (GMto B) and the continuous displacement (MassShip)

variable design space.

Figure 2-5: Examples of Constraints Applied to the Design Space

The following figure shows an example where constraints are placed on the

overall length (LOA) and the length-to-beam ratio (LtoB) of the design space. The

red part shows the DOE experiment filtered by the constraint, and the green part

shows the experiment within the constraint. Constraints on the design space can

greatly affect the number of valid experiments in the DOE, and a visual analysis of

the effects of these constraints could potentially warrant rerunning the DOE to better

capture the appropriate design space.

Figure 2-6: Histogram Showing the Effect of Constraints on the Design Space In

the center of the model, the PD strip is used to calculate the seaworthiness

characteristics using

Strip theory. Holtrop resistance analysis is run in Matlab, and a separate Matlab

module runs the PSOP SNAME program for propeller design [1]. T h e p o w e r

r e q u i r e d f o r t h e p r o p e l l e r is t h e n c a l c u l a t e d f o r dur a b i l i t y a n d

s u s t a i n e d s p e e d ( d e s i g n ) . I f c h a n g e s m u s t b e m a d e t o c a p t u r e a

m o r e a c c u r a t e r a n g e o f o n e o r m o r e c o n t i n u o u s v a r i a b l e s , t h e

f i n a l D O E i s r u n p r i o r t o t h e d e r i v a t i o n o f t h e R e s p o n s e S u r f a c e

M o d e l ( R S M ) o f h y d r o s t a t i c , m a r i n e m a i n t e n a n c e , a n d p r o p u l s i o n

d a t a f o r u s e i n M u l t i - P u r p o s e G e n e t i c O p t i m i z a t i o n ( M O G O ) i n

f u r t h e r a n a l y s i s . R S M

generated from the DOE tool in the Model Center and

labeled hydrostatic, marine maintenance, and propulsion as shown in figure 2-7

below.

Figure 2-7: RSM Generation in the Model Center [1]

This RSM represents the hull generated in Rhino/Orca, while the synthesis model

organizes the design and performs all further calculations including OMOE and

OMOR calculations. The ultimate goal of MOGO is to explore the design space to

create a non-dominated ship design frontier ranked by cost, OMOE, and OMOR [6].

Figure 2-8 below shows the MOGO results for a medium-sized surface combatant.

Costs versus OMOE are plotted for each variant, and each variant is colored based on the

calculated OMOR value. These OMOR values are calculated by the OMOR worksheet in

SSM, and are set by the Model Center based on the design team's preferences. In this case,

the OMOR value has been set as low (green) for values less than 0.5, medium (yellow) for

values 0.5 to 0.75, and high (red) for values above 0.75. Planning these variants as shown

gives the design team an excellent visual reference of the undominated frontier and goes a

long way in choosing the preferred variant.

Figure 2-8: OMOE vs. Fees for Surface Vessels [1]

Once the selected variant has been selected, it can then be repeated using further

single-objective optimization techniques that are typically focused on minimizing a

single parameter such as cost, or maximizing a single parameter such as sustained

speed. Once all the optimizations are complete, the resulting DV can then be easily

loaded back into the SSM and a new hull can be generated in Rhino/Orca and is now

ready for subdivision.

C&RE tools provide a clear and logical path to DOE, MOGO, and non-

dominated frontier analysis that includes cost, OMOE, and OMOR. This is a clear

advantage over ASSET, which lacks this feature, and also an advantage over the

creation of project-specific design tools that may or may not be useful to future

design teams. There are many examples in the 2N program of powerful design tools

that are created and used for only one ship sign for various reasons. Individual design

tools can and still should be created in some cases, although the obvious advantage is

also that they can interact with Model Center and Rhino/Orca which will allow for

the future growth of MIT's design tool packages. Popular coding languages such as

Matlab, Excel, and Python

easily integrated with C&RE tools and is another obvious advantage that increases

the likelihood that naval officers in the 2N program will be able to successfully

contribute to improving the tool through future research.

Article 3

New method to complete the initial

setup

3.1

Current Initial Setup Process

Once steps 1-8 of the C&RE process shown in Figure 2-1 are completed, the three-

dimensional hull including the superstructure has been created in the Model Center.

An example of the resulting stomach is shown below. The deckhouse design is

driven by volume and area calculations that can be set based on user input into the

SSM. The physical shape of the deckhouse will be modified by the design team as

necessary to meet further criteria such as wind resistance, radar cross-section,

interference between top-side equipment, or general aesthetics.

Figure 3-1: Three-Dimensional Hull with Superstructure Generated in Rhinos

The design team can now focus on the Physical Architecture component of the

C&RE process shown as steps 10-14 in figure 2-1. D u r i n g t h i s p h a s e , t h e

h u l l i s s u b d i v i d e d b y t r a n s v e r s e b u l k h e a d s , l o n g i t u d i n a l

b u l k h e a d s , a n d h o r i z o n t a l d e c k s . T h e r e a r e s e v e r a l m e t h o d s

t o c o m p l e t e t h e h u l l s u b d i v i s i o n b u t t h e m o s t c o m m o n

a p p r o a c h i s t o m a n u a l l y c r e a t e a n d p l a c e t h e R h i n o

p o l y s u r f a c e r e p r e s e n t i n g t h e b u l k h e a d a n d d e c k a t t h e i r

r e s p e c t i v e l o c a t i o n s c a l c u l a t e d b y t h e M o d e l C e n t e r d u r i n g

s t e p 1 0 o f t h e C & R E p r o c e s s . T h e h u l l s u b d i v i s i o n m o d u l e i n

t h e M o d e l C e n t e r i s t h e m a i n r e f e r e n c e f o r p l a c i n g b u l k h e a d s

a n d d e c k s u n l e s s f u r t h e r d e c i s i o n s a r e m a d e t o a c c o m m o d a t e

c o m p a r t m e n t s t h a t m a y r e q u i r e a d j u s t e d d i m e n s i o n s . O n c e t h e

s u b - d i v i s i o n i s c o m p l e t e , t h e i n i t i a l s e t u p o f t h e V C c a n

b e g i n , a n d t h i s i s c o m p l e t e d b y u s i n g a s e p a r a t e m a n u a l

p r o c e s s . D e s i g n e r s h a d t o m a n u a l l y c r e a t e m o r e t h a n 4 0 0

i n d i v i d u a l R h i n o o b j e c t s r e p r e s e n t i n g V C s w h i c h w e r e t h e n

a s s i g n e d t o t h e o r c h e s t r a t e d R h i n o l a y e r s y s t e m . T h e V C c a n

t h e n b e s e t u p i n s i d e t h e a p p r o p r i a t e c o m p a r t m e n t , a n d v i s u a l

a n a l y s i s o f t h e s e t u p c a n h i g h l i g h t p o t e n t i a l s y s t e m g l i t c h e s

o r p r o b l e m a t i c s p a c e l i m i t a t i o n s w i t h i n t h e c o m p a r t m e n t .

N o d a l d i a g r a m s s h o w i n g t h e l o g i c a l a r c h i t e c t u r e o f a

p a r t i c u l a r s y s t e m a r e u s e d t o a i d i n t h e s e t u p p r o c e s s [5]. T h e

l o g i c a l a r c h i t e c t u r e o f a s y s t e m c a n b e t h o u g h t o f a s a l i n e o r

b l o c k d i a g r a m . A n e x a m p l e o f a n o d a l d i a g r a m f o r a n e w f r e t -

d e s i g n p r o p u l s i o n p l a n t i s s h o w n b e l o w i n f i g u r e 3-2. T h i s

d i a g r a m i s u s e d t o a i d i n t h e s e t u p o f a m e d i u m - s i z e d s u r f a c e

c o m b a t a n t f e a t u r i n g a h y b r i d e l e c t r i c d r i v e p r o p u l s i o n

s y s t e m .

Figure 3-2: Nodal Diagram for Hybrid Electric Propulsion Generator

If the VC cannot be fitted into the hull according to the logical architecture of the

system, or there is a problematic interference between the systems, the design may be

declared unfeasible due to conflicts with the area or the adjustable volume. This

process is very demanding because there are over 400 VCs enrolled in SSM and

above-average Rhinoceros skills are required to complete the initial setup accurately.

The biggest challenge occurs when VCs that require a large amount of internal space

are placed in their respective locations while further supporting subsystems must be

arranged according to the logical architecture of the larger system. Simultaneously,

designers must also carefully account for potential interference between systems in

three dimensions. Figure 3-3 shows an example of a surface vessel that has been

manually subdivided with a Rhino Poly surface, and the initial setup has been

completed in the main engineering room with a manually constructed VC.

Figure 3-3: Manual Subdivision and Initial Setup

As seen in figure 3-3, it is possible to achieve a high level of detail at the level of

concep-tual design using this method. Designers with operational experience in the

battleship's engine room are at a clear efficiency advantage during the process of

dividing the hull and setting up the VC. The engine room can be set up with

confidence by calling upon hundreds of operational hours spent by surface warfare

naval officers in many classes of ships. Designers without experience on surface

vessels are at a disadvantage and without guidance from references such as detailed

ship information books, which cannot be released to the public, the manual VC setup

process can experience inefficiencies and lower confidence in the design. Therefore,

the information for VC found in the SSM such as compartment assignments,

dimensional information, and system nodal diagrams is the main reference for initial

setup during the C&RE design process. To improve the manual process of

subdivision and initial setup, a new tool was sought that could leverage critical

component data from the SSM to perform initial setup more effectively and could be

incorporated into the C&RE process.

3.2

New Process for Preliminary Setup

The new tool needs to implement as much automation as possible for the initial setup

process described above while also providing a more efficient method for creating

and setting up more than 400 VCs that need to be set up. Incorporating automation

into this process will increase efficiency by eliminating some user error without

compromising the overall learning experience in completing the ever-complex initial

setup of a warship. Since the three-dimensional hull shape is generated by the Model

Center using Rhino, this new initial setup tool should also be able to easily interact

with Rhino to reduce complexity.

It was initially believed that macros written in Rhino script coding would be able

to achieve this goal. An attempt was made to trace the exact sequence of Rhino

commands required to construct a Rhino object representing VC, and then use this

command sequence as the basis for creating macros. The ultimate goal of

This macro will quickly generate Rhino objects for all VCs, arrange them into layers,

and then place them in the appropriate locations according to the x,y,z location

information found in SSM. This attempt failed, as more training in Rhino scripts was

needed to create coding that was powerful enough to accomplish all of the tool's

goals. Therefore, new methods for creating tools using different naval architecture

software are sought. Paramarine software packages were investigated as a viable

option, but ultimately it was considered that the learning curve for the use of this

software was effectively too steep for an academic environment due to the low level

of experience with Paramarine.

The search into the Rhinoceros design tools used by architects was carried out on

the basis that large ships and buildings have an integrated system that covers various

levels. This leads the search to the Rhino Grasshopper plug-in application, which is

an interactive python coding platform with a user-friendly graphical user interface

that is very similar to Rhino and capable of creating powerful macros through python

templates. These macros are represented by displaying ter-terminal inputs and

outputs that can be connected to encoding that are visually represented by cables.

After an initial investigation into the feasibility of using Grasshopper to develop a

new tool, it was discovered that the Grasshopper Bumblebee2 plug-in can quickly

read excel data defined by a specific file path and import a specific range of excel

worksheets into Grasshopper. This finding is very strong because now all the

dimensional and location information for VCs under the ShipSYSnew worksheet

from SSM can now be imported and used in Grasshopper to create and place Rhino

objects that represent VCs.

To reduce complexity, it's a good idea to reduce the amount of data read and imported

by excel readers. This is achieved by importing two specific cell ranges that contain the

exact information in the desired SSM. The first imported dataset includes five columns of

information displayed in the ShipSYSnew tab section shown in the image below. Column

A, plex, indicates the VC subsystem, while column B Vertex Label/VC gives the VC

name. Columns C, D, and E, provide the X,Y,Z location of these individual VCs. These

locations

provided is the centroid of a specific subdivision block previously designed by the

VT research team and represents approximately where these components would be

found on the hull of the same size. The image below provides an example of SSM

data to be extracted that will provide the necessary location and dimensional

information for all VCs. Simultaneously, further data is imported from the

ShipSYSnew tab of SSM under the "Customized VC Design Data (adjusted to the

standard Required Capacity) section. This data represents specific size information

for each VC. The KO, KP, and KQ columns above represent the length, width, and

height of each VC.

Table 3.1: Data Extracted from Ship Synthesis Models

The Locust Code shown below in figure 3-4 is used to extract the VC information

shown in table 3.1. T hi s exa mpl e c lea rly i llu str a te s how G ra s sh opp e r

cod e a ppe a rs t o th e us e r as a c ode bo x w i th i nput s a nd ou tp u ts

con nec ted b y wi res a s d esc rib e d ear lie r.

Figure 3-4: Bumblebee2 encoding in a grasshopper that extracts the information of SSM VC

Now that the location and dimension information for the VC is imported into

Grasshopper, the data is then sorted into a data tree. Each branch of this data tree

directly correlates with the information columns extracted from ShipSYSnew's excel

worksheets in the synthesis model. These branches can now be sorted and placed as

input into a Grasshopper code shell that automatically creates a 3-dimensional

rectangular box Rhino object based on length, width, and height information as

shown in table 3.1.

Using the same data tree, the centroid of each subdivision block can be replicated

by a single point in Grasshopper using the "create point" command. These dots are

represented by a red cross in figure 3-5 below. The "move" command in Grasshop-per is

then used to move each VC to the appropriate subdivision block. This puts all VCs with the same

location information on top of each other in the approximate location where these VCs will actually

be on board. These locations are not exactly correlated with the hull as seen in figures 3-5 but are

almost correct. By completing this step, a Rhino object representing a VC with the

corresponding dimensions and location information is now visible inside the ship,

although the image is very crowded, with many VCs sharing the same location

information. These boxes have not been "baked" or actually made into Rhino but are

a red sketch of what the components in the model would look like if baked into

Rhino.

Figure 3-5: VC box and Subdivision Center block created in Grasshopper

After

this discovery was made, the decision was made to move forward with Grasshop-

per as the primary coding platform for this new initial setup design tool

as further research on Locust further increases the belief that it can be used to

achieve all goals.

3.3 Improving the Setup Tool

In order to create cleaner images and encourage an organized process for setting up

VCs in Rhino, it is necessary to organize and tidy up the number of Rhino objects

generated and placed in the same location. A straightforward solution to fix this

problem is to create a method to sort VCs into groups based on their subsystems, and

then place them into separate Rhino layers for each subsystem. This is achieved by

using the "plex" information in column A shown in table 3.1, which represents the

respective VC subsystems. By applying a data filter to the plex information, the

number of unique plexes can be determined which will then correspond to the

number of individual layers that need to be created. In this case, there are 18 unique

plex categories for more than 400 individual VCs.

The VC node/name label and assigned compartment found in column B and

column F of table 3.1 are separate branches of data in Grasshopper, respectively. These two

branches are combined, and attached to each VC correlate as a property of the Rhinoceros

object. Now that the VC plex, node/compartment information, dimensions, and locations are all

known, they can be inserted into Rhino as "attributes" using the Grasshopper Elefront plug-in

that must be downloaded and added to Grasshopper to complete this task. This bake function

permanently creates a box in Rhino

that is now free to move and also creates a number of

individual layers determined

by the number of unique plexes in the VC list. Next,

the VCs are then sorted into the corresponding layers, and the layers are colored

to distinguish the components from those in other plexes. Examples of the

various layers with VC baked into the Rhino model are provided below.

Figure 3-6: VC Made from Locusts and Arranged into Layers

As shown above in figures 3-6, the image was very crowded at first with many

VCs imported on top of each other. The name of the compartment generated by Orca

V2.5 is increasingly crowding the image. The designer can also clearly see that the

VCs need to be moved to the appropriate location because some are outside the ship

because the VCs are placed in the centroid of the subdivision blocks, which roughly

represent their actual location inside the ship.

The obvious advantage of this process is that with each group of vital components

organized into layers, the active layers can remain visible while others can be hidden

to greatly reduce clutter in Rhino 3d's view-ports and make the process of manually

arranging components much more efficient. When a user selects an individual VC in

Rhino, the object's properties can also be viewed under the "properties" menu. This

property contains the VC name and the assigned compartment. When the Large VC

located in the main chamber such as a propulsion engine is set up, a system known to

be associated with an engine such as a fuel oil pump can be brought forward by

turning on the fuel oil layer (FO) and locking the MECH layer. Now all FO VCs can

be seen and arranged precisely around the machine without making any unwanted

changes to the MECH layer. By locking the finished layer, the error of accidentally

moving components can be greatly reduced. It is up to the designer to determine the

most effective method for setting up VCs within their respective engineering spaces,

although it is advisable to start with the most complex and/or physically largest

systems.

Finished coding view for the initial setup tool in Grasshop-

per is shown below. Further technical descriptions of this code can be found in Ap-

pendix A.

Figure 3-7: Locust Code for the Initial Setup Tool

3.3.1 Added Connectivity between VCs in Grasshopper

Vital Components are generally connected by some physical part be it a conduit,

pipe, cable, conduit, or any other form. It is estimated that if this physical

connectivity can be replicated in the initial setup tool, then the designer can more

accurately place the VC in the correct location that will align the physical

architecture of the system with the logical architecture found in the nodal diagram as

shown below in figure 3-9.

Figure 3-8: Logical Architecture for Chilled Water System

This image shows the logical architectural complexity for a chilled water system.

If the line between the VCs shown in the image can be replicated in real

Rhinoceros, then the nodal diagram will be a stronger reference and the designer can

be more confident that the VC is in the correct orientation with respect to other VCs

in the same subsystem. The proximity matrix is present in SSM, which

mathematically holds the connectivity between VCs. A successful attempt was made

to read this proximity matrix, import the related connectivity information into

Grasshopper, and then create a line between the VCs to visually indicate the

connectivity in Rhino according to the logical architecture of the system.

Figure 3-9: Locust Code for VC Connectivity

The coding for this part of the tool is more complex than what is required for the

initial setup tool and will only be briefly described in this section. Although this code

has proven to run successfully in Grasshopper and interact with Rhino, there are two

critical problems with achieving the goal of showing connections between VCs. The

first problem is that some VC dimension values are equal to zero in SSM. It is

filtered from the initial setting tool as a zero value, however the VC is still included

in the proximity matrix and therefore the connectivity line is drawn to the VC which

has the zero dimension and is therefore invisible. This creates many connectivity

nodes inside the ship that sometimes have multiple connectivity paths that end up

being invisible VCs. Further complicating this issue is that the original configuration

of SSM has embedded zone locations for certain systems that do not have VCs

assigned to them. Figure 3-10 below shows the current state of connectivity in

Grasshopper. The hull has been concealed from this view to tidy up the port of view

of the Rhino.

Figure 3-10: VC Connectivity Path

This problem is intended to be fixed by a separate research team that is currently

in the process of overhauling the proximity matrix format. The second problem faced

in the design of VC connectivity tools is that there is no method to connect

connectivity paths to individual VCs found. This creates problems when VCs are

moved and their associated connectivity paths don't follow them. The immediate

solution to this problem is to automatically pair the connectivity path with the

centroid of each Rhino VC object. That way the connectivity path will move with the

centroid of each VC object, and the connectivity line that crosses it can indicate that

the arrangement is potentially inconsistent with the logical architecture of the system.

A further advantage is that it automatically places these stripes in an organized Rhino

layer that can help clean the Rhino display ports while actively working to set up the

system. Rarely does a system's physical architecture reflect the exact pattern of its

logical architecture, although this connectivity path can show further learning points

during the initial setup process by highlighting the complexity of routing connections

between components in order for the system to operate in very close proximity to

each other. Further research and design work is required to complete this part of the

initial setup tool in Grasshopper.

Article 4

Case Study for U.S. Navy Fleet

The conceptual design of the new U.S. Navy Fleet (FFGVT-2022) was completed

using the C&RE total ship synthesis process to provide a new platform to test

common setup tools at Grasshopper and support other ongoing research projects at

Virginia Tech. This chapter contains an edited description of the FFGVT design and

how the initial setup tool is used to verify the feasibility of the design. The following

description of FFGVT-2022 is taken from its ICD, the full ICD can be found in

Appendix B.

FFGVT will be a medium-sized surface combatant capable of carrying out

homeland strength and defense, and Intelligence, Surveillance, and Reconnaissance

(ISR). It is expected that the FFGVT will be able to operate independently, with the

Surface Action Group, with the Carrier Combat Group (CBG), and to support the

Expeditionary Strike Group (Amphibious Force) providing AAW, ASUW, and ASW

support. The Surface Action Group (SAG) will conduct a variety of EW and ISR

missions in addition to providing their own AAW, ASUW, and ASW defenses. The

ISR's mission will include the use of autonomous air, surface and subsurface

vehicles, and LAMPS.

The initial size calculation creates the destination range and threshold for the

physical size of the FFGVT as well as the initial estimate of the propulsion and

electrical power required.

Table 4.1: FFGVT Initial Size

The design parameters shown above classify FFGVT as a medium-sized surface

combatant according to US Navy standards. In order to achieve all desired mission

areas, threshold values and objectives for operational and combat systems, combat

capabilities are created and shown in table 4.2.

Table 4.2: Design Parameters of FFGVT Combat System

To ensure that the design can be capable of carrying out this mission, the

following Combat System Configuration is incorporated into the Synthesis Model

Design Parameters and Design Variables worksheets in the synthesis model.

Table 4.3: Design parameters of the FFGVT combat system

Design Parameters and Design Variables were incorporated into the Model

Center Experimental Design tool to produce 200 representative hull shape variants to

visualize the design space and analyze the effect of hull shape DV on hydrostatics,

marine maintenance, and propulsion performance [5]. T h i s D O E d a t a i s t h e n

c o n v e r t e d i n t o R S M a s d e s c r i b e d i n C h a p t e r 2 . M u l t i -

O b j e c t i v e o p t i m i z a t i o n w a s c o m p l e t e d s e p a r a t e l y f r o m t h e

D O E , a n d c e r t a i n d e s i g n s w e r e s e l e c t e d b y t h e r e s e a r c h t e a m

t o p r o c e e d . T h e o p t i m i z a t i o n r e s u l t s i n c l u d e P S Y S = 7 ( H E D ) ,

A A W = 4 , A S U W = 6 , a n d A S W = 7 , w h i c h a r e p r o p u l s i o n p l a n t

a n d c o m b a t s y s t e m c o n f i g u r a t i o n s t h a t p r o v i d e t h e b e s t r a t i o

o f o v e r a l l s i z e e f f e c t i v e n e s s v s . c o s t . F u r t h e r e x p l a n a t i o n o f

t h e e x p l o r a t i o n o f t h e d e s i g n s p a c e a n d t h e r e s u l t s o f

o p t i m i z a t i o n w i l l n o t b e d i s c u s s e d i n t h i s p a p e r . N o w t h a t a l l

e n g i n e e r i n g a n d c o m b a t s y s t e m V C s t o b e i n c l u d e d i n t h e

d e s i g n a r e k n o w n , a n e w i n i t i a l s e t u p t o o l i n G r a s s h o p p e r c a n

b e u s e d t o v e r i f y t h a t t h e d e s i g n c o n t a i n s

area and volume are

sufficiently regulated to be considered decent.

4.1 Hull Subdivision Using Orca V2.5

Once the optimization is complete, the focus of the design work is shifted back to the

three-dimensional hull model in Rhino shown below.

Figure 4-1: FFGVT Rhino model (half-hulled)

The hull was then subdivided using the Orca V2.5 Work In Progress module in

Rhino 7. One of the important steps required to complete this process is that the

designer must ensure that the hull is a closed poly surface to carry out the

functionality of the Orca V2.5. This can be challenging, and most problems occur at

the intersection point between the deck house and the hull. The locations for

bulkheads and decks are automatically calculated by the subdivision module and

their

locations are displayed under the profile view and the model perspective showing

the

completed subdivisions.

Figure 4-2: FFGVT Subdivision

Figure 4-3: FFGVT Subdivision (Perspective View)

Table 4.4: Location of FFGVT Bulkheads and Decks

In order to create the correct geometry for large compartments such as helicopter

hangers and all engineering spaces, compartment surfaces such as decks need to be

removed in order to open the compartments to the correct size and allow the right

space for large components to be placed. The naming convention for components is

taken from the "settings" worksheet in SSM, which shows

Compartment block diagram and assigned compartment name. This worksheet is not

updated automatically during the design process therefore manual changes will be

required to adjust the diagram for larger or smaller surface vessels. For the purposes

of this project, only transverse bulkheads and horizontal decks are placed into the

model, although the placement of longitudinal bulkheads is possible using the Orca

V2.5.

4.2

Initial Setup of Vital Components

The initial setup tool is loaded into the Rhino workspace, and the correct data range

is imported from the SSM to the FFGVT hull as shown below. As mentioned earlier,

Rhino objects are red at this point and are just sketches where VCs will be placed

automatically until they are baked into the model by Grasshopper.

Figure 4-4: VC made by Grasshopper and Placed into the Stomach

The initial setup for FFGVT begins with a VC listed outside the MECH plex of

PSYS=7 including one gas turbine main propulsion engine, cross reduction gears,

two second reduction gears, two electric propulsion motors, and associated bearings

and stern tube seals found along the shaft line. All other layers set by plex are turned

off to tidy up the port-view. Also included in this plex are the inlet and exhaust for

the main drive engine, which is one of the largest VCs. To account for the hull in all

engineering spaces, a temporary poly surface is added with a height of 0.5 meters

from the compartment body to ensure that all VCs are placed at least 0.5 meters from

the

deck to take into account the hull space. This temporary surface is then removed to

reduce clutter in the view-port. The most complicated challenge to set up the VC of a

propulsion system is to determine the angle of the shaft to Main Engine Room 1

(MMR1) or the farthest point that the shaft into the boat must reach from the

propeller. A very important design point is the need to determine the correct

propeller tip clearance between the top of the propeller blade and the bottom of the

hull, as this will help determine where the shaft line will fall into the engine

compartment. The clearance of this tip can be measured from the center of the top

surface of the Rhinoceros object representing the propeller to the bottom of the hull.

In this case, the shaft is of the same length and both end up on the thrust bearing

located in MMR1. It is driven by the GTM forward cross reduction gear which is

placed on the center line because the two outputs of these cross reduction gears must

be at the same shaft angle. For ship classes with different shaft lengths such as DDG-

51 or CG-47, different shaft angles will be present and cross reduction gears cannot

be done unless the main drive can be set between the waterproof bulkheads. The

angle of the FFGVT shaft is 3 degrees and is measured using the "angle" command

in Rhino by drawing a line through the center of the shaft, and another along the XY

axis. The angle between these lines is the angle of the shaft. Due to the deadlock of

the shaft against the thrust bearing, this is generally the next component that can be

adjusted, followed by the reduction gear, and the main drive. Since the angle and

location of the shaft are known, the line shaft bearings, stern tube seals, and support

bearings can now also be adjusted. Supporting calculations for the location of the line

shaft bearing can be used to further improve the accuracy of this setting. The line

shaft bearing is placed evenly along the shaft in this example and rotated to the

correct shaft angle three degrees.

Figure 4-5: Plan View and MECH plex Setup Profile View

Figure 4-6: Perspective View of MECH plex Settings

As seen in the image above, there are several view-ports that help in executing

the general settings. Through practice, it has been determined that the most effective

method of conducting regulation is to utilize the "Plan View" (waterline view in

naval architecture) viewing port to control transverse movement in the XY plane, and

"Profile View" to control vertical movement in the X-Z plane. Both the "Ortho" and

"Osnap" commands are very helpful to the designer in controlling

VC movement and improve design symmetry because VC movement is limited only

in the orthogonal direction. Once the appropriate transverse and vertical movements

have been made, it is useful to check these changes in the view-port "Perspective"

using the new Orca V2.5 clipping box feature, which can cut out parts of the hull to

reveal interior compartments. The perspective view should only be used for

situational awareness, as it is very difficult to move the Rhinoceros object in three

dimensions and will almost certainly cause unwanted movement of the object. These

view-ports are advantageous in identifying interference between VCs quickly

because the other three view-ports are two-dimensional and therefore become very

crowded with objects that seem to interfere with each other, but in reality can be

separated by vertical or transverse distances that cannot be seen in two dimensions.

Selecting the problematic VC in the perspective view ensures that the right VC is

selected and ready to be moved, and the designer can now move back to the profile

view or plan to make the necessary changes to address the disruption. The "Body

Plan" view of the Y-Z plan is also useful in some situations, but generally becomes

too dense with lines from other VCs and the hull.

The initial setup process then continues for other VCs whose previous layers were

turned off. The process used is to work with the layer that holds the most VC first,

and then progress to the layer with the fewest number of VCs, ensuring that the

finished layer is locked before the new VC layer to be set is brought to the front. The

temporary poly surfaces that represent the grate decking inside the engine

compartment are used to place the smaller VCs in the middle and upper levels of the

engineering space just as they would be on top of a real fighter. These grids are then

removed and not displayed to remove image clutter and to minimize the number of

active layers, but can be left inside the model or hidden if desired.

Figure 4-7: Complete Setup of all Engineering Critical Components

Figure 4-8: VC arranged in the Main Engineering Room

Figure 4-7 above shows the initial setup that has been completed for all engineering VCs.

The Rhino layer menu is displayed on the right side of the image and shows the layers of the

hidden AAW, ASW, and ASUW combat systems. These layers are now brought forward one

by one and the process continues to complete the initial setup of the FFGVT. The AAW plex

contains most combat systems, VCs and large objects such as a 32-cell VLS. VC ASW and

ASUW contain fewer objects. The full setup for the VC combat system is shown below. All

engineering VC layers are hidden in this view.

Figure 4-9: Initial Setup of VC Combat System

The initial setup for all VC engineering and Combat systems has now been

completed and the focus is now shifted to verify that there is no interference between

any VCs. It was found that most of the problems occurred around the inlet/exhaust

for GTM and diesel generators, and it was advantageous to leave the MECH and

ELEC layers on during the initial setup process to ensure that the VC was not placed

on the shaft line or into the inlet/exhaust stack.

Figure 4-10: FFGVT's Preliminary Indictment

Figure 4-10 above shows the FFGVT hull with all VC layers turned on, and

locked. At this stage the initial setup is completed and the design can move forward

in the C&RE process.

Chapter 5

Conclusion

Incorporating the proven design process of C&RE tools into the 2N program

provides a meaningful first step away from ASSET as a primary design tool and

eliminates the problems students face with the Distro A information found in

ASSET. This tool allows designers to dive deeply into important areas of design

while ensuring that other parts of the design process do not suffer. The C&RE tool

was built by the latest naval officers and architects with modern warship designs. The

tool will positively influence 2,705 future design projects, and these same projects

create a positive feedback loop into the synthesis model.

5.1

Further Research and Recommendations

The project has paved the way for future collaborative research between 2N and

Virginia Tech's naval architecture program that could continue to improve many of

the capabilities of C&RE tools. Incorporating Grasshopper into this project was

groundbreaking, and the creation of the initial setup tool showed what was possible

to create a better three-dimensional model of the ship in Rhino. Many engineers are

working to create plug-ins and more powerful upgrades to the Grasshopper, which

can be incorporated into the tool as well to create piping, conduits, or electrical

connections between Vital Components. When the VC reshuffle

The proximity matrix in SSM is complete, connectivity between VCs may be

possible in Grasshopper. This path should be explored, as it will greatly improve the

accuracy of the initial setup tool, and build the experience of learning to complete the

challenging setup of the Vital Components.

The C&RE research team has discussed the possibility of creating a new VC that

can represent components on the top side of the ship, such as small boats, capstans,

and equipment used for recharging at sea. This is recommended, as incorporating the

topside design into the Rhino model will further build on the battleship design

learning experience.

The ongoing collaboration between MIT and Virginia Tech at the graduate level

raises the likelihood that the C&RE tool will continue to improve and could become

the primary warship design tool used in academic settings.

Appendix

Guide to Using the Initial Setup Tool

This attachment will explain in detail the coding of Grasshopper behind the initial

setup tool and how to use the tool effectively to read Excel, create VCs, and organize

them into Rhinoceros Layers. Each part of the coding will be explained to help with

any potential troubleshooting required. Users should always ensure that the latest

Rhino update is installed as this will also automatically update the Grasshopper

accordingly. The McNeel Forum has been very helpful in resolving conflicts in

Rhinos and Locusts. A quick response to the issue can be expected on this forum and

is highly recommended for tool development as well.

Grasshopper is already installed into Rhino versions 6 and 7. To access

Grasshopper, Grasshopper needs to be added to the Rhino command list and

Grasshopper can also be opened by typing it into the Rhino command line. Many

references such as Parametricbydesign.com and food4Rhino.com have excellent

reference documents including video tutorials on how to successfully upload

Grasshopper and related plug-ins.

The plug-ins required to operate the initial setup tool are Elefront version 5.1.2 or

later and Bumblebee 3.0 or later. These plug-ins are updated regularly and their

capabilities are improved. The following figures are screenshots taken from the

food4Rhino website.

Figure A-1: Required Elefront Plug-ins

Figure A-2: Required Bumblebee Plug-ins

In Grasshopper Coding, Bumblebee reads and imports VC information from a

synthesis model that creates a data tree in Grasshopper. Elefront allows attributes

such as name, assigned compartments, and colors to be embedded with the Rhino

object, and "bakes" or makes the VC as a Rhinoceros Object that is organized into

layers and is free to move. These two plug-ins will be described further in this

appendix. The Locust Code section circled in Red as shown will now be explained

and the code block will be referenced by the numbers seen above the individual

block as seen on A-3.

Figure A-3: VC Info Read from SSM using Bumblebee

The purpose of this part of the code is to read the SSM Excel worksheet and

import all the information needed to create and deploy the VC into Grasshopper. In

the upper right corner of A-3, the icon used in Bumblebee is highlighted. There are

two ways to put new coding into Grasshopper, you can select the icon from the toolbar,

or you can double-click to the Grasshopper workspace which will open a small

command line where the user can type commands just like you can in Rhino. All

code blocks must be wired to flow through each other as shown.

Block 1 is an Excel Application, this must be rotated by placing the Boolean =

true switch for Bumblebee to be executable. During troubleshooting situations, it

would be helpful to disable the entire app by creating the Boolean = false switch.

Block 2 is the "load workbook" command in Grasshopper (from Bumblebee).

There are two inputs to this block, Application and P. Application is an Excel

Application from block 1, and P is the path of the file and there is a small block

labeled Path next to the input P. This is created using the "path" command in

Grasshopper. By right-clicking on this Path block, a single file can be selected from

anywhere in the user directory. This file path needs to be traced to SSM in the exact

location where it is stored and it is important to be careful with version control in

SSM that is updated or moved in the directory.

Figure A-4: Tracing the File Path to SSM

Now that the file path to SSM is entered, block 3 is the "Get Worksheet"

command in Grasshopper (from Bumblebee). The input to this block is "Wbk"

(workbook) which is connected to the output of Block 2 (reading the entire SSM)

and "N" (worksheet). This block reads specific Excel worksheets from SSM as

desired. To capture all the VC info, a ShipSYSnew worksheet is desired. A panel is

created, and the exact format of the ShipSYSnew text is copied from the Excel tab

that contains the worksheet name, placed into this panel, and connected to N.

Figure A-5: ShipSYSnew Worksheet from SSM Read by the Locust Panel

placed on the output of each Locust code block will show you

The current state of the data sent to the next block. This is a very useful way to build

tools and ensure that the desired information is connected to the appropriate inputs

for other blocks of code.

Blocks 4 and 5 are the "Read Excel" command in Grasshopper. These two blocks

are used to extract all the necessary VC information from SSM and import it into

Grasshopper. Block 4 is used to read Columns A to F of the new ShipSYS tab of

SSM.

Figure A-6: AF Column, and KO-KQ Imported into Locust

Table A.1: VC information required from SSM

As you can see in figure A-6, Block 3 should be connected to Block 4 and Block

5. The Boolean toggle for each block must also be equal to "True". Input -A in a

block refers to the exact range of Excel Cells that the code will read. In this case,

Block 4 reads all the values from SSM From cell A5 to cell F403. Block 5 reads all

cells from O5 to Q403.

Blocks 6 and 7 are "flip" commands that place the data into the correct format to

be organized into the data tree. It can be thought of as swapping rows and columns

into matrix-like data. The panel on the right shows the output from Block 4 and

Block 5. This pane is a data tree that contains all the imported Excel information, and

its branches are organized by Excel data columns. In the top right corner

from the panel, 0 is displayed. This indicates that the first column of Excel

information is labeled zero and as you can see is the plex information contained in

the Excel column

A. It is important to remember that the first branch in all Locust data trees is labeled

as zero. After completing this step, all the information needed to create the VC is

loaded into Grasshopper and can be used for other commands. It is also possible to

right-click on the XL reader and select "internalize data" which saves the data into

the locust worksheet itself and no longer requires SSM to find the data. This is useful

for times when it may be desirable to send Grasshopper code to other users who may

not have access to SSM.

A.1

Creating and Placing Critical Components Boxes

The following details describe the part of the locust code circled in blue as shown

below in figure A-8. I n t h i s s e c t i o n o f c o d e , e a c h b r a n c h o f

i n f o r m a t i o n i s e x t r a c t e d f r o m a d a t a t r e e i m p o r t e d f r o m S S M

u s i n g a n X L r e a d e r . A b o x r e p r e s e n t i n g t h e V C a n d a d o t

r e p r e s e n t i n g t h e c e n t e r o f t h e s u b d i v i s i o n b l o c k a r e c r e a t e d .

Figure A-7: Locust Code for Creating and Placing VCs (circled in blue)

In this section of code, each branch of information is extracted from a data tree

imported from SSM using an XL reader.

Figure A-8: Locust Code for Creating and Placing VCs

Blocks 8-10 show the branch information extracted from the first data tree of

excel data imported from SSM. Block 8 has branch 2 which is location X for the

center of the subdivision block, and blocks 9 and 10 are locations Y and Z for the

center of the subdivision block. These branches are incorporated into Block 11 which

is the "Create Points" command in Grasshopper. It is the red cross seen in the

Rhinoceros display port, and is the centroid of all subdivision blocks. Blocks 13-15

are individual branches of the second data tree imported from the second range of

excel values which are X, y, and Z dimension information to create the VC box. This

data is plugged into block 19 which is the "Middle Box" Locust Command and has

been renamed to "Create VC Box" for the purposes of this tool. Blocks 16-18 are the

mathematical operators that divide the dimensions

information from blocks 13-15 becomes two. This is necessary because the "Middle

box" command will make the Rhino object twice as large as desired because the

dimensional information is measured from the center of the box.

Block 20 is the Locust's command "Brep", which designates the newly created

box as a (Boundary Representation) that can later be converted into a Rhinoceros

object. Block 12 is the Locust Command "Move". It is connected to block 19 as

shown, which moves the center of the box to the point created by block 11. This is

how VC objects are placed in the appropriate location and why many VCs are placed

on top of each other. In this Code of Locusts, 399 boxes are created by block 19, and

399 moves are executed by block 12. The information in each panel other than

blocks 8-10 and 13-15 is numbered 0-398 for a total of 399 values listed in each

panel. By checking this, users can be sure that all VCs have been taken into account.

A.2

Assigning Attributes to Rhino VC Objects

The Locust Code circled with Green, Black, and Orange is described in this section.

This part of the code assigns the attribute (information) to the VC box that has been

created. The end result is that the VC is "baked" into Rhino as a Rhino object (orange

part), with a layer and color assigned (Green Part), and an assigned node name and

compartment information (black part).

Figure A-9: Locust Code for Assigning Attributes to Rhino Objects

This description now focuses on the part circled in Green that creates the indi-

vidual layer set by Plex for each VC, imported from the previous SSM.

Figure A-10: Locust Code for Creating and Organizing Rhino Layer Block 21

shown above is a branch extracted from the original data tree. Ini

according to column A of the ShipSYSnew tab in SSM (Plex). The panel on the right

shows the extracted plex information. The relay wire is connected from block 21 and

runs over blocks 21-25, this will be explained further in the last section of the Locust

code. Block 22 is the Locust command "Sort Duplicate Values". What this command

does is read the branch information to the left, and set the number of unique values

present. In this case, the number of unique values is equal to the number of different

Plexes that can be found in SSM. Block 23 is the Locust command "List Length",

which calculates the number of values in the list. This gives the number of individual

plexes present, which in this case is 18. Figure A-11 below shows the output panel

placed next to blocks 22 and 23.

Figure A-11: Plex Information Organized to Create Individual Layers Blocks

24 and 25 assign a color (color) to each plex. Colors are carried out-

Domly is selected from a range of 0.05 to 0.95 and is attached to each unique plex.

These colors can be changed to the user's preferences later in Rhino. The purpose of

this section is to set the color so that when VCs are loaded into Rhino, they don't all

have the same color, which will be grayed out by default in Rhino.

The Code of Locusts circled in black in figure A-9 will now be explained.

Figure A-12: VC Vertex Name and Compartment combined

Similar to the other parts of the Locust Code described earlier, blocks 26

and

28 shown above are branch information extracted from a larger data tree retrieved

from

SSM. Block 26 holds branch 5 which is the Compartment. Block 28 has branch

1, which is the name of the node. The panels to the right of block 26 and block 28

show this. In order for the node and compartment names to be combined into

single list, the "Flatten" Locust Command (blocks 27 and 29) is used to remove branch

information from the output of Blocks 26 and 28. It organizes the data for the "combine"

command shown in block 30. A semicolon is used to separate the values

from the two

lists, and the panel on the right shows the results of the Concatenate command.

The end result is that a list of 399 node names and compartments correlated with

399 VCs is now present in the worksheet and is ready to be placed as input for

the names of Rhinoceros Objects.

A.2.1 Bake VC Boxes with Attributes into Rhino

The Locust code circled in orange in image A-9 is the last part of the Grasshop-per

code that executes the ultimate goal of "baking" the Rhino object into the Rhino View-

port.

Figure A-13: VC Box Assigned Final Attributes and Baked into Rhino

All of the Grasshopper code blocks in this section come from the Elefront plug-

in. The most important block in this section is block 36 which is an attribute of

Rhino. With a focus on Block 36, the inputs N (Name), L (Layers), and C (Colour)

can be seen. Blocks 32, 33, and 35 provide information for these inputs. These three

blocks are connected by the section of code described earlier. Block 32 provides the

name of the object, Bock 34 provides layer information, and block 35 provides color.

The wire relay indicated by block 31 is connected to Block 22 which is a Sort Value

command. This function provides the number of objects categorized under each plex

and it ensures that the input data is set correctly before going into block 36.

Block 36 is connected to input A (attribute) of Block 37. As shown Block 33

provides Brep (VC Boxes) to input G (Geometry) to block 37. Now, all the necessary

information is there, and the user can select the "Activate" button located at the

bottom of block 37. All Rhino objects are now baked into the Rhino layer.

INCORPORATING AND APPLYING CONCEPTUAL DESIGN TOOLS FOR NAVAL WARSHIPS

Students also viewed