Requirements and Standards: Deliverable D3.1

Ref.
Ares(2017)1056589 - 28/02/2017
Holistic Optimisation of Ship Design and Operation for Life Cycle
Horizon 2020 - 689074
Requirements and Standards

Deliverable D3.1
February 2017
Authors:
A. Ginnis, G. Zaraphonitis, J. Brunswig, R. Broglia, G. Schellenberger, P. Hooijmans, F. Sprenger,
Qiuxin Gao, E. Boulougouris, G. de Hauteclocque
1 Deliverable D3.1
DISCLAIMER
This project has received funding from the European Union's Horizon 2020
research and innovation programme under grant agreement n° 689074.
The information contained in this report is subject to change without notice and
should not be construed as a commitment by any members of the HOLISHIP
Consortium. In the event of any software or algorithms being described in this report,
the aforementioned Consortium assumes no responsibility for the use or inability to
use any of its software or algorithms. The information is provided without any
warranty of any kind and the HOLISHIP Consortium expressly disclaims all implied
warranties, including but not limited to the implied warranties of merchantability and
fitness for a particular use.

COPYRIGHT 2017, the HOLISHIP Consortium
This document may not be copied, reproduced, or modified in whole or in part for
any purpose without written permission from the HOLISHIP Consortium. In addition, to
such written permission to copy, acknowledgement of the authors of the document
and all applicable portions of the copyright notice must be clearly referenced.
All rights reserved.
2 Deliverable D3.1
Document data
Document Title: Requirements and Standards
Work Package(s): WP 3, Task 3.1
Dissemination level: Public
Deliverable nature: Report
Lead beneficiary: NTUA
Responsible author: Alexandros Ginnis, NTUA

G. Zaraphonitis, NTUA, J. Brunswig, HSVA, R. Broglia, CNR, G.
Co-authors: Schellenberger, HSB, P. Hooijmans, MARIN, F. Sprenger, SINTEF, Qiuxin
Gao, TRITEC, E. Boulougouris, USTRATH, G. de Hauteclocque, BV
Apostolos Papanikolaou, NTUA; Philippe Corrignan, BV, Jochen
Reviewer:
Marzi, HSVA
Date of delivery: 27 / 2 / 2017
WP Partners Quality Assurance Group
Circulation:
Steering Group EC
Document history
Version Date Description
1 17/2/2017 First version
2 24/2/2017 Updated version
3 24/2/2017 Version for QC
4 28/2/2017 Revised final version
3 Deliverable D3.1
Contents
DISCLAIMER .................................................................................................................................................. 2
LIST OF SYMBOLS AND ABBREVIATIONS......................................................................................................... 8
1 EXECUTIVE SUMMARY........................................................................................................................... 9
1.1 PROBLEM DEFINITION .................................................................................................................................. 9
1.2 TECHNICAL APPROACH ................................................................................................................................. 9
1.3 RESULTS AND ACHIEVEMENTS........................................................................................................................ 9

2 INTRODUCTION ................................................................................................................................... 10
2.1 POTENTIAL FLOW CODE: ν-SHALLO ............................................................................................................. 13

2.1.1 Software tool description and functionality .................................................................................... 13
2.1.2 Input and Output data structure ..................................................................................................... 13

2.1.3 Robustness and quality of computational results ........................................................................... 14
2.1.4 Connection to CAESES ..................................................................................................................... 14
2.1.5 Licensing and System Requirements ............................................................................................... 15

2.2 RANSE-BASED SIMULATION CODE: FRESCO+ ................................................................................................. 16

2.3 GRID GENERATION TOOL: HEXPRESS ......................................................................................................... 19


2.3.4 Licensing .......................................................................................................................................... 19
2.4 REFRESCO AND XSHIP (MARIN)............................................................................................................... 20

2.4.1 Software description and functionality ........................................................................................... 20

2.4.5 Connection to VR platform .............................................................................................................. 21
2.5 SHIPX WORKBENCH (SINTEF) .................................................................................................................... 21

2.5.1 Software tools description and functionality .................................................................................. 21

4 Deliverable D3.1

2.6 AEGIR (CNR-INSEAN) ............................................................................................................................ 26



2.6.7 References ....................................................................................................................................... 27
2.7 WARP (CNR-INSEAN)............................................................................................................................ 27


2.7.7 References ....................................................................................................................................... 28
2.8 XNAVIS(CNR-INSEAN) ............................................................................................................................ 28


2.8.7 Reference......................................................................................................................................... 29
2.9 HOLTROP AND MENNEN’S METHOD (STRATHCLYDE) ....................................................................................... 29

2.10 PARAMETRIC ROLLING (STRATHCLYDE) ......................................................................................................... 30
2.10.1 Software tool description and functionality ................................................................................ 30
2.10.2 Input and Output data structure ................................................................................................. 31

2.10.3 Robustness and quality of computational results ....................................................................... 31
2.10.4 Connection to CAESES ................................................................................................................. 31
5 Deliverable D3.1
2.11 MAXWAVE_PROP (STRATHCLYDE) .............................................................................................................. 32


2.12 MAXWAVE_STEER (STRATHCLYDE) ............................................................................................................. 33


2.13 CAESES CONNECTOR TOOL FOR STARCCM+ (STRATHCLYDE) ........................................................................... 35

2.14 WAGENINGEN B-SERIES (STRATHCLYDE) ....................................................................................................... 35


2.15 STARCCM 11 (TRITEC MARINE) ................................................................................................................. 36

2.15.5 Licensing and System Requirements ........................................................................................... 37
2.16 NAPA (HSB) .......................................................................................................................................... 37

2.17 NEWDRIFT (NTUA-SDL) ........................................................................................................................ 38
2.17.1 CFD tool NEWDRIFT description and functionality...................................................................... 38

6 Deliverable D3.1

2.17.6 References................................................................................................................................... 40
2.18 NAPA MACROS FOR INTACT AND DAMAGED STABILITY (NTUA) ....................................................................... 40


2.19 HYDROSTAR (BUREAU VERITAS) .................................................................................................................. 42

2.19.4 Connection to Caeses .................................................................................................................. 43
2.19.5 Connection to VR platform.......................................................................................................... 43

3 CONCLUSIONS ..................................................................................................................................... 43
4 REFERENCES ........................................................................................................................................ 46
5 INDEXES .............................................................................................................................................. 48
5.1 INDEX OF TABLES ...................................................................................................................................... 48

5.2 INDEX OF FIGURES ..................................................................................................................................... 48
6 ANNEX I .............................................................................................................................................. 49
6.1 THE MARIN EXTENSIBLE MODELLING FRAMEWORK (XMF) ............................................................................. 49
6.2 THE GLOBAL APPLICATION ARCHITECTURE ......................................................................................... 49
7 Deliverable D3.1
List of symbols and abbreviations
Abbreviations
ASCII: American Standard Code for Information Interchange
CFD : Computational Fluid Dynamics
CGNS: CFD General Notation System (http://cgns.github.io/)
IGES : Initial Graphics Exchange Specification
RANS: Reynolds Averaged Navier-Stokes
RANSE: RANS Equations
SAT: Standard ACIS Text
STEP: Standard for the Exchange of Product Model Data (ISO 10303)
STL: STereoLithography (mesh format)
URANS: Unsteady Reynolds Averaged Navier Stokes
XDMF: eXtensible Data Model and Format (http://www.xdmf.org)
XML: eXtensible Markup Language
8 Deliverable D3.1
1 Executive summary
1.1 Problem definition

HOLISHIP WP 3 addresses hydrodynamic and hydrostatic analysis and optimisation of
ships and other maritime assets.
A significant number of numerical tools to predict and optimise both the stability and
hydrodynamic performance of maritime products shall be prepared for use in
integrated design platforms. The CFD tools to be used comprise methods for the
prediction of ship resistance and power demand, the assessment of manoeuvrability
properties and the seakeeping behaviour of the product. They range from very
simple statistical analysis tools suitable for a very early design stage (concept design)
to highly sophisticated software packages able to accurately predict specific
properties during later project phases (contract design).
In today’s practice the use of such tools is often time consuming and only loosely
integrated with other design processes.
The prime objective of WP 3 is hence to adapt a number of promising stability and
CFD tools and make them fit for use in the integrated design platforms which will be
developed in WPs 7 and 8.
1.2 Technical approach

A draft description of the preconditions that must be fulfil by the different tools in
order to be used in HOLISHIP has been presented in the DoA of the project. In the
framework of Task 3.1, this description should be refined in close collaboration with
the WP3 partners.
In order to collect the necessary feedback from the providers of the software tools a
standard questionnaire has been prepared and distributed to all WP3 partners. The
structure of the questionnaire is as follows: Brief description of each tool’s purpose,
capabilities, functionalities and underlying theory. Brief description of the tool’s
input/output data structure. Tool’s robustness and its quality of computational results.
Information regarding the necessary interfaces/wrappers that need to be
developed/used in order that a bidirectional connection with CAESES and/or the VR-
platform can be materialised.
The collected information has been compiled and presented in the present report.
1.3 Results and achievements

The current document presents the software tools that WP3 partners are contributing
to the project for the assessment of stability and hydrodynamic performance of ships
and other maritime assets with emphasis on reporting their input/output data
structure, the robustness and quality of the associated computational results as well
as the required actions needed for integration with the design and/or virtual
demonstration platforms.
9 Deliverable D3.1
2 Introduction
The prime objective of WP 3 is to adapt a number of promising stability and
hydrodynamic tools and make them fit for use in the integrated design platforms
which will be developed in WPs 7 and 8. These tools comprise numerical methods for
the prediction of ship resistance and power demand, the assessment of
manoeuvrability properties and the seakeeping behaviour of the maritime product.
They range from very simple statistical analysis tools suitable for a very early design
stage to highly sophisticated software packages able to accurately predict specific
properties during later project phases. Specifically, WP3 shall adapt and enhance
hydrodynamic software tools at three different design levels: i) conceptual design, ii)
(preliminary) contract design and iii) virtual demonstration.
The core of the integrated design platforms to be developed in WP7, is CAESES by
FRIENDSHIP SYSTEMS, a well-established Computer Aided Engineering platform.
CAESES platform in its current status provides functionality for communicating a
range of industry standard geometry formats, e.g., IGES Sat, STEP, STL, OpenNurbs, as
well as data formats, e.g., Tecplot, Vtk, Ensight, OpenFoam, FLUENT and ShipFlow. It
also provides tools for creating custom software connections through scripting. In
WP7 it will be further extended and enhanced for flexible and easy integration of
simulation and analysis software tools.
The Virtual Vessel Framework, to be developed in WP 8 and used as a virtual
demonstration platform, will be based on an existing software package in use in the
aviation industry, namely CPACS/RCE open source software by DLR. This software
tool will be adapted to and tested for maritime applications to result in the VVF.
Maritime modules requiring adaptation to the communication structure will be
updated
The current document presents the software tools that WP3 partners are contributing
to the project with emphasis on reporting their input/output data structure, the
robustness and quality of the associated computational results as well as the
required actions needed for integration with the design and/or virtual demonstration
platforms.
The following tables depict the collection of software tools proposed by the WP3
partners along with a short description of their purpose and capabilities. In this table
the software tools are categorised according to their functionality and their
underlying theory.
The presentation of each software tool, carried out in Section 3, follows the same
template which comprises 5 subsections. Firstly, a brief description of the tool’s
purpose, capabilities, functionalities and underlying theory is provided followed by a
report on the tool’s input/output data structure. Next, in subsection 3, evidence is
provided regarding tool’s robustness and its quality of computational results. Finally,
in the last two subsections information is provided regarding the necessary (if any)
interfaces/wrappers that need to be developed/used in order that a bidirectional
connection with CAESES and/or the VR-platform can be materialised.
10 Deliverable D3.1
index Software Tool Description Partner
RANS code for calculating
Tritec
1 StarCCM+ resistance, seakeeping and
Marine
maneuvering
RANSE Based CFD code for viscous
RANS & URANS codes
flow simulations. Used to determine

hull resistance and propulsion
2 FreSCo+ properties, behavior of ships in a HSVA
seaway (ship motions and added
resistance), maneuvering
capabilities etc.
RANS code for calculating ship
resistance, flow around the hull and
3 ReFresco MARIN
for determining maneuvering
characteristics.
Steady/Unsteady RANS based CNR-
4 Xnavis
solver INSEAN
Hydrodynamic Analysis Tools
Potential theory based BEM solver Tritec

5 ANSYS AQWA
for seakeeping calculations Marine
Potential flow 3D panel code for
seakeeping, motions, loads and
6 NEWDRIFT NTUA
drift forces on ships and floating
bodies in waves
Potential, strip theory based tool.

ShipX - Vessel
Seakeeping
Calculates ship motions and global

7 Responses SINTEF
loads, including short term statistics,
(VERES)
Potential Flow Codes
long term statistics and operability.
Potential flow 3D Panel code

(nonlinear/unsteady, time domain): CNR-
8 Aegir
seakeeping, added resistance, INSEAN
unsteady loads, 6DOF
Sea-keeping software based on

Boundary Element Method (BEM),
9 HydroStar BV
using linear and 2nd order potential
theory.
Fully non-linear, free surface
Wave Resistance
potential CFD code computing the

10 ν-SHALLO HSVA
inviscid flow around a ship hull at a
free surface
Potential flow 3D Panel code to
CNR-
11 WARP determine calm water resistance
INSEAN
and loads. Steady, 2DOF
Table 1: List of Software Tools – Potential Flow & RANS
11 Deliverable D3.1
index Software Tool Description Partner
Estimates the maximum wave
12 MaxWave_Prop height at which the ship is capable Strathclyde
to navigate in head waves
Predicts the maximum wave head
and the maximum available speed
13 MaxWave_Steer at which the ship is capable to Strathclyde
maneuver in adverse sea
conditions
Tool developed within CAESES.
Other Tools for Hydro Analysis
Hydrodynamic Analysis Tools
Performs level 1 and level 2 checks

Parametric
14 for parametric roll failure mode, as Strathclyde
Rolling
described in SDC 2/WP.4 IMO
guidelines
Calculation of calm water
resistance and performance in
ShipX - Ship addition to speed loss in waves.
15 Speed and Utilizes empirical methods , residual SINTEF
Powering resistance from database or model
test or regression of resistance from
SINTEF Ocean's database
Estimates the thrust and torque
Wageningen propeller characteristics using
16 Strathclyde
B-series Wageningen B-series data (Matlab
code)
Holtrop and Utilizes empirical methods for
17 Mennen’s resistance and propulsion Strathclyde
method prediction
XShip is an empirical maneuvering
18 XShip MARIN
simulation tool.
Naval Architecture Package
19 NAPA suitable amongst others for stability HSB
calculation (intact and damage)
CASD Tools
NAPA macros for intact and
20 NAPA macros NTUA
damaged stability calculations
Hexahedral volume mesh

21 HEXPRESS HSVA
generation tool
Suppleme-
ntary Tools CAESES
CAESES Connector tool for
22 Connector tool Strathclyde
StarCCM+
for StarCCM+
Table 2: List of Software Tools – Other Tools
12 Deliverable D3.1
2.1 Potential Flow Code: ν-SHALLO
2.1.1 Software tool description and functionality
ν-SHALLO is a tool for predicting the wave resistance of a ship hull. It is based on
potential flow theory (the flow is assumed to be incompressible and irrotational),
viscous effects are not considered. The user must provide a panelisation of the hull
geometry, the discretisation of the water surface is created automatically by the
simulation software. ν-SHALLO is a valuable tool in both concept and contract design
stages.
Figure 1: Graphical representation of ν-SHALLO results, planar view
2.1.2 Input and Output data structure

The input data required to carry out a ν-SHALLO simulation is provided in three
different ASCII files:
1. shallo.ctl
This file contains the physical setup of the simulation, like ship speed, draft at aft
and forward perpendiculars etc. Each parameter is always located at the same
place in the file, making the format easy to parse or create:
2. panels.pan (name can be different)

The discretisation of the hull form as a set of panels. The file starts with a list of
vertices, followed by a list of three to five-sided panels referencing the vertices.
3. nondef.opt
13 Deliverable D3.1
Non-default options, can be used to ‘tweak’ discretisation settings in more
difficult situations (e.g. for blunt bow shapes which sometimes cause numerical
instabilities). Post-processing options are also set in this file:
The output data created by ν-SHALLO are also ASCII files:

1. The text output to the console ν-SHALLO is running in, containing all relevant
information about the iteration process, hull forces etc.
2. Depending on the post-processing option output for
a. Gnuplot
b. ParaView (VTK files)
c. Tecplot
2.1.3 Robustness and quality of computational results

The software has been used successfully for many years at HSVA and their customers.
Due to its robustness and efficiency (a typical simulation only takes a few minutes), ν-
SHALLO will remain an essential tool in the hull design process. Seldomly encountered
numerical stability issues tend to be related to blunt bows, which is a typical
behaviour for potential flow codes, as these situations push the underlying theory to
its limits.
2.1.4 Connection to CAESES

CAESES already comes with a ready-to-use integration of ν-SHALLO. It isn’t built on the
generic (and user-driven) integration mechanism that all new tool integrations in
HOLISHIP will rely on. Instead, the interface to ν-SHALLO is coded directly into CAESES.
Therefore, the integration cannot be adapted to changed input requirements
without manual support from the platform provider. As a result of the existing
integration, the new generic tool integration is expected to be quite straight forward.
Since the shallo.ctl and nondef.opt files are simple ASCII files, they can be setup
easily to be parsed and created by CAESES. Furthermore, the panelisation file is
already a known format for CAESES.
A feature currently missing in the CAESES VTK reader is the ability to display data on
point clouds. This would be beneficial for quality-checking the source strength
distribution of a simulation case. Especially in situations where numerical difficulties
are encountered (e.g. blunt bow shapes), analysing the local source strengths can
give the user a good indication on how to solve the problem. Using Tecplot or
ParaView as a post-processing tool, this representation can be easily created, see
Figure 2.
Another feature often used in the analysis of a simulation result are (limiting)
streamlines on the ship hull. This can be done in ParaView or Tecplot, using the panel
velocities stored in the result file. To provide a seamless integration, it would be
beneficial to have such a feature inside the CAESES platform.
14 Deliverable D3.1
Figure 2: Graphical representation of ν-SHALLO results (including source strengths)
Figure 3: Graphical representation of ν-SHALLO results (including source strengths)
2.1.5 Licensing and System Requirements

ν-SHALLO is a commercial simulation code developed at HSVA. It is currently licensed
to a number of customers for a one-time license fee. The software can be tested and
used by HOLISHIP partners within the scope of research activities related to the
project upon request.
The simulation code can run on any Linux or Windows PC (reasonably recent
versions). It does not require special hardware for high performance computing.
15 Deliverable D3.1
2.2 RANSE-based simulation code: FreSCo+
FreSCo+ is a RANSE-based flow solver for a virtually infinite variety of simulation
scenarios. The code is of finite-volume type, the numerical grids can be fully
unstructured. Although the cells are allowed to be arbitrarily shaped (as long as they
remain convex), HSVA mostly relies on hexahedral grids with refinements. FreSCo+ is
entirely parallelised to efficiently run on high-performance clusters with many
thousands CPU cores. Depending on the problem size and the available computing
resources, the solution times range from hours to days.

FreSCo+ requires two sets of data as input:
1. The numerical volume mesh as CGNS file, at HSVA this file is usually created using
the semi-automatic mesh generation tool HEXPRESS
2. A case setup in XML format: controls.xml
This file defines which grid file is to be used and assigns boundary conditions to all
faces. Specific equations and features are enabled and configured in every
detail via controls.xml. It is important to note that FreSCo+ can be started using
quite small and simple controls.xml, because default parameters are used for any
value not explicitly defined in the file.
Output files which are generated (some depending on certain features to be

enabled):
1. The general output format of FreSCo+ for field data (physical values in each
computational cell) is HDF5; see https://www.hdfgroup.org/HDF5/. This is a very
efficient binary format. HSVA uses XDMF files as a descriptor to allow post-
processing with ParaView.
2. A report file in XML format: report.xml
This file contains all parameters used in the simulation including the ones omitted
in controls.xml. It also lists some statistics, integrated physical values etc.
3. If specific features of the tool are enabled, certain ASCII files are created, for
example:
a. Force monitor: forces.dat or similar
b. 6-DOF solver for motions of floating bodies: 6-MOS-motion.dat
c. Trim- and sinkage: trimSinkage.dat
d. Timestep adaptation: timestep.dat
Figure 3 shows an example for a result file written by the force monitor. Each line
represents the results for a specific timestep. It is important to note that time histories
of forces in FreSCo+ can be subject to fluctuations with significant amplitude (this is a
typical behaviour of viscous CFD). To obtain results as accurate as possible, an
averaging scheme is used instead of simply reading the value of the very last
timestep.
16 Deliverable D3.1
Figure 4: Example of FreSCo+ result file (time series of hull forces)

FreSCo+ has been used over many years in a great number of different research and
commercial projects. Details on the numerical procedure can be found here:
– www.hsva.de/our-services/software/fresco.html
– www.tuhh.de/fds/research/current-projects/fresco.html

FreSCo+ comes with its own pre-processor which converts CGNS meshes into the
HDF5 format the simulation tool can read.
With respect to creating the necessary input definition to setup a simulation case
through CAESES, no significant problems are expected, since XML files have a simple
and well-defined structure.
For post-processing, HSVA mainly uses ParaView, importing field data via the XDMF /
HDF5 interface. To facilitate post-processing and to ensure a constant quality level,
Python scripts are used to create standard views on specific types of simulation
results. These scripts connect to ParaView using its Application Programming
Interface (API). Such scripts could also be used to convert computational results to a
format that can be read by CAESES, e.g. the VTK format.
Because RANSE-based simulations usually take a significant amount of time to
complete, it would be quite beneficial if the platform could support the user by
offering the analysis of intermediate or preliminary results (instead of having to wait
for the finalisation of the computation). This could avoid wasting computation time in
case the simulation is unable to convert to a satisfactory solution, e.g. due to
problems in the case setup.
17 Deliverable D3.1
Another interesting platform feature would be a framework to run remote simulations
in a different computational environment, e.g. a high performance cluster. Such
functionality would not only solve the problem of (usually) limited local resources, but
could also open the possibility for other HOLISHIP partners to use a software tool they
do not own without installing it on their own hardware.

FreSCo+ is a semi-commercial tool developed at HSVA and Hamburg Technical
University (TUHH), which has been used and extended in many collaborative
research projects over the last decade. Due to its feature richness on numerous fields
of CFD technology, FreSCo+ has grown to a quite complex tool to master. Neither
HSVA nor TUHH have the resources to provide professional support for FreSCo+ users,
so the software has been licensed to selected industrial partners only, having staff
who had worked with FreSCo+ before. Within HOLISHIP, sharing FreSCo+ binaries with
the partners would only be an option based on a case-by-case decision. HSVA’s
partner TUHH would have to be included in this decision process.
Although FreSCo+ runs on any modern Linux computer, the high computational effort
involved in typical marine applications makes a high performance computing
environment mandatory.
18 Deliverable D3.1
2.3 Grid Generation Tool: HEXPRESS
HEXPRESS is a semi-automatic tool to create unstructured hexahedral volume grids
around complex geometries. The software is a commercial development by
Numeca. It comes with an interactive graphical user interface, but it can executed
in batch mode alternatively. Therefore, it is generally eligible for integration into the
HOLISHIP platforms.

Although HEXPRESS offers some very basic functionality to create and modify CAD
geometry, the typical approach is to import the geometry in one of the following
formats:
- ParaSolid
- STL
- Colored STL
It is of great importance for the grid generation process to work properly that the
imported geometry represents a closed solid without any gaps. The difference
between STL and colored STL is that in the latter each triangle is assigned to a family
(=color), which greatly facilitates the definition of boundary conditions later in the
process.
HEXPRESS has its own proprietary file format for saving projects. This format is
considered to be irrelevant for the integration in the platforms.
The relevant output format is the computational mesh as a CGNS file. It contains the
grid vertices and the connectivity information of cells and their neighbours. Importing
these file types directly into one of the platforms is most likely not necessary (nor
feasible), but the mesh file is of course a required precondition for starting a FreSCo+
computation.

Mesh generation around complex geometries is a quite difficult task with many steps
that can go wrong. Most problems can be automatically be detected by HEXPRESS
(gaps and holes in the geometry, mesh snapping issues, cells with unfavourable
quality with respect to orthogonality etc.). Checks against further problems must be
carried out by the user, at least for the first of a series of similar grids, e.g. in the
context of a geometry variation / optimisation. The necessary user interaction can
be minimised, though, by defining standard views (of grid sections at relevant
positions) which are created automatically after the grid generation.
2.3.4 Licensing
This is a commercial software tool, developed by Numeca and cannot be shared
with the project partners. Partners wishing to use HEXPRESS should obtain the required
license from Numeca.
19 Deliverable D3.1
ReFRESCO and XShip (MARIN)
These tools are developed by MARIN
2.3.5 Software description and functionality

ReFRESCO is a RANS code (see enclosed documentation sheet and
www.ReFresco.org). It can be used in the early design stage for hull form optimization
and in the contract design stage for hull form evaluation, focusing in resistance, flow
around the hull and to determine manoeuvring characteristics.
XShip is based on the SURSIM empirical manoeuvring simulation tool. This tool should
be used as medium fidelity tool and is fast and therefore convenient for parametric
hull form or propulsor/rudder variations.

The eXtensible Modeling Framework (XMF) is MARIN’s framework to develop
simulation components and simulator applications. It is suggested to use this
framework as input and output structure in HOLISHIP. The XMF framework will be the
input and output control mechanism. The advantage of the XMF framework is that it
can easily be linked to other (validated) simulation components.
Regarding the ReFRESCO (RANS) code, the following input and output data is
required and available respectively.
Input:
• CGNS file containing the 3D grid
• XML file containing the settings of the simulation
Both file types are industry standards and are not explained in further detail here.
Output:
• CGNS file containing the 3D solution
• ASCII files containing the convergence history and other monitors defined in
the input XML file
Both file types are industry standards and are not explained in further detail here.
Regarding the XShip simulation tool the following input and output data is required:
Input:
• hull file describing the hull in several strips (the hull file can be converted to
many hull form descriptions by using ConvertHullForm
(http://members.chello.nl/s.toxopeus1/ConvertHullForm/download-
index.html)
• ASCII/xml files describing propulsion and rudder configuration
Output:
• ASCII files containing the results of the simulations
20 Deliverable D3.1
The robustness and quality of the ReFRESCO code is described in many papers and
can be found here: www.ReFresco.org . The ReFRESCO code has proven itself in
many applications.
XShip is an empirical method and is medium fidelity. The hull form is described by
sections and quality of the results is as can be expected from empirical methods.

The interface to CAESES is suggested in an XMF framework environment. In this way
there is no need to develop a direct connection between CAESES and ReFRESCO
like MARIN’s potential flow code RAPID does have a direct connection with CAESES.
The advantage of the XMF framework is that it can run applications simultaneously.
CAESES can either use the ConverHullForm tool for the XShip simulations or provide
the .hul format directly.
2.3.9 Connection to VR platform

When ReFRESCO and XShip can be ran in an XMF framework environment, a
bidirectional connection with the VR platform will be easy to be materialised. A brief
description of the XMF framework is given in ANNEX I .

MARIN will make the software tools available for use in HOLISPEC/RCE and CAESES.
These tools can be used by the partners within the project and for the purpose of the
HOLISHIP project. However, tools will only made available upon request and clear
proof of the need for these tools. For HOLISPEC/RCE the use of the tools will be
established over the internet. For CAESES not.
The XShip application can be run on a standard windows PC.
ReFRESCO can be run on a Linux machine. The on-board memory will be the limiting
factor for the number of grids cells that can be applied.
2.4 ShipX workbench (SINTEF)

2.4.1 Software tools description and functionality
VERES
VERES is the vessel response plugin of SINTEF Ocean's ShipX workbench, which is
applicable from the early design stage to the operational phase of a vessel. This is a
strip theory program for the calculation of vessel motions (displacement, velocity
and acceleration) transfer functions at arbitrary locations in six degrees of freedom
for both, Fn=0 and Fn>0. Mean drift forces and added resistance in waves can be
either calculated by a pressure integration method or according to the radiated
energy approach by Gerritsma and Beukelman. Further, global wave induced loads
can be assessed. Beside the effect of the hull alone, the effect of bilge keels,
moonpools, roll reductions tanks and motion control devices can be modeled.
21 Deliverable D3.1
In the post-processor of the code, short-term and long-term statistics and operability
can be calculated for various relevant limiting motion criteria.
Ship Speed and Powering

The Ship Speed and Powering software is another plug-in in the ShipX workbench. This
software is used for calculating calm water resistance and performance in addition
to speed loss in waves. The resistance can be calculated by means of empirical
methods (Hollenbach, Holtrop etc), residual resistance from database or model test
or regression of resistance from SINTEF Ocean's database. Direct input of resistance
curves is also possible. Propulsion data is calculated by either utilizing the SINTEF
Ocean Propulsion Library, using standard propeller series or by using open water
propeller diagrams. Speed loss is calculated by including the added resistance in
waves calculated by VERES as well as wind resistance based on standard coefficient
for different ship types. A propeller optimization tool is also included in the software,
helping the user to find an optimum propeller for the vessel in question.

VERES
The minimum input required to run a VERES calculation is a hull description in ascii
format (*.mgf file format) and a description of the corresponding loading condition
through GUI input, which is stored in an ascii-file (input.veres) that is read by the
program. A second ascii-file (shipx_input.veres2) contains information generated by
the ShipX framework to be transferred to VERES. The format of the geometrical
information in the *.mgf file is presented in Figure 5.
Output data from VERES is also written in ascii-files. The number and types of files are
depending on the selected options for calculation:
- *.re1: Motion transfer functions
- *.re2: Added resistance, drift forces and yaw moments
- *.re3: Global wave loads
- *.re6: Dynamic pressure
- *.re7: Hydrodynamic coefficients
- *.re8: Wave excitation forces
Figure 5: File format for VERES Geometry Files
22 Deliverable D3.1
As the Ship Speed and Powering plugin is an early design stage tool that uses
empirical methods or coefficient based input to calculate the resistance, no hull
geometry is required. Only the main dimensions are required for scaling the
coefficients. An exception is the assessment of speed loss in waves, where added
resistance results from VERES calculations are used. To obtain this component, a
geometrical description of the hull in the *.mgf file format is required (see description
of VERES). The propulsion models require input depending which model is used, but
this is also typically general input such as engine type/power, propeller
diameter/pitch etc. Input that is given through the GUI of the plugin is stored in an
ascii-file (input.speedloss) that is read by the program.
Figure 6: GUI for Ship Speed and Powering input

Output from the calculations are written to *.mpl files (ascii format) to be plotted in
the ShipX Plot Program or to be read and used by other post processing software.

VERES
Due to the nature of linear, potential, strip theory, VERES is a very robust tool. The
three-dimensional hydrodynamic problem is reduced to a set of two-dimensional
problems along the hull. This makes VERES computationally efficient and robust. The
nature of the method and the underlying assumptions however imply some
restrictions for application. The theory is developed for moderate wave heights
inducing moderate motions on a ship with a length, which is much larger than the
breadth and draught. In addition, the change in cross-sectional area as function of
longitudinal position should be low. Consequently, large ship motions and large
wave heights will restrict the validity of the results. However, ship motions obtained by
the program show very good correlation with experimental results even at wave
23 Deliverable D3.1
conditions that are outside the limits of the theory. The most problematic scenarios
for this code are following sea conditions for Fn>0.
The quality of results is depending on the quality of input in terms of the geometrical
description of the hull (number of stations), especially in regions of cross-sectional
variation such as bow and stern, and the assumptions made for the loading
condition.
As the software uses coefficient based resistance, it is a very robust and efficient tool.
The accuracy of the results are strongly dependent on the quality of the input
provided by the user. The user can use generic approaches (database, comparison
ships) as input, or he can use data for a specific vessel to get even higher accuracy.

It is planned to connect some selected plugins of the ShipX database to the CAESES
platform. The following section gives a brief description of the data interfaces to be
developed.
VERES
The intention of the coupling of VERES and CAESES is to establish a methodology to
optimize the shape of an initial hull within given limitations with the goal to reduce for
example defined vessel motions, added resistance or increase operability. A typical
example for an offshore vessel could be the reduction of roll motions for an initial hull
design where the displacement and main particulars can either be fixed or varied
within given limitations. In the first case only local geometry variations would be
allowed.
In the simplest case, the initial geometry together with the set of relevant parameters
and target values (e.g. expected maximum roll motion in a given 3h sea state)
needs to be read by CAESES from ascii files that are written by VERES. In each
iteration loop, a new geometry would be written by CAESES to *.mgf format which is
again used for a new VERES calculation. When relevant hull particulars are altered
by CAESES, the new values have to be written into the VERES input files.
For more complex cases, where the vessel has for example bilge keels, roll reduction
tanks and a moonpool (typically offshore construction vessels), more things need to
be considered in this optimization loop:
- Bilge keels: damping contributions from bilge keels to normal forces and hull
pressure are included in the VERES calculation. Bilge keels are usually located in
the parallel midship region with a defined height above keel at each station. The
optimum position is either determined by streamline paint model tests or CFD
calculations. Since it is too complex to consider this in the optimization loop, a
more generic procedure is proposed: for a hull variant produced by CAESES, the
breadth of the bilge keels should be fixed and the overall length of the bilge
keels related to Lpp should remain constant compared to the initial design. The
height above keel should also remain constant and only the y-coordinates need
to be adapted to ensure the keel is attached to the hull at each station. The
bilge keel coordinates are stored in the input.veres file.
24 Deliverable D3.1
- Roll reduction tanks: in VERES, different types of roll reduction tanks can be
modelled, such as u-tube tanks or rectangular free surface tanks. VERES includes
a large experimental database of phase/moment curves for passive rectangular
free surface tanks that is used for interpolation. The input of tank parameters is
handled through a GUI and the input values are stored in the input.veres file. For
a new hull variant, some of these parameters need to be adapted, e.g. the ratio
of tank breadth to ship breadth should remain constant, the relative position of
the tank on the ship should be kept constant with respect to a reference point
such as [Lpp/2, CL, BL]. Another option could be to keep the fluid mass inside the
tank constant.
- Moonpools: VERES does not account for the full hydrodynamic effects of a
moonpool, but uses a simplified approach. The main intention is to consider the
correct hydrostatics and to ensure a better prediction of roll motion behaviour
(e.g. correct natural period) etc. This is achieved by subtracting the Froude-
Krylov forces at the bottom of the moonpool from the wave excitation forces.
These forces are calculated on a flat plate located at the bottom position of the
moonpool. Added masses in surge, sway and yaw include the mass of the water
in the moonpools. Dynamic effects due to water motion in the moonpools are
not accounted for. The input of moonpool parameters is handled through a GUI
and the input values are stored in the input.veres file. For a new hull variant
generated by CAESES, the initial moonpool should be scaled according to the
new dimensions of the hull to avoid for example the moonpool extending
beyond the new hull boundaries. When the draught is changed, the respective
descriptive parameters need to be adapted as well. Ship Speed and Powering
The idea for the coupling of the Ship Speed and Powering plugin and CAESES is to
establish a methodology to optimize the shape of an initial hull within given
limitations to reduce involuntary speed loss in waves. For this procedure, it is assumed
that a propeller has been selected and the propulsion data is available either
through standard series or direct input of propeller open water curves.
In order to determine involuntary speed loss in waves, the results of three different
calculations need to be combined: the calm water resistance, which is directly
estimated in the plugin by means of the methods described above, the wind
resistance, which is also directly calculated by the plugin as described above, and
the added resistance in waves that is calculated using VERES. While the calm water
and wind resistance parts do not require a complete geometrical description of the
hull, VERES requires the hull geometry in *.mgf format. Therefore, the *.mgf file as well
as the main particulars and the limiting parameters for the optimization study need to
be read by CAESES from ascii files provided by the Ship Speed and Powering plugin
through the interface. The vessel displacement and main particulars can either be
fixed or varied within given limitations. When relevant hull particulars are altered by
CAESES, the new values have to be written into the respective input files for the new
calculations.

The numerical tools from SINTEF Ocean, including ShipX are commercial software,
subject to licensing and they cannot be made freely available. Selected ShipX
25 Deliverable D3.1
plugins will be applied in defined tasks during the case studies. For this purpose, a
tailored ShipX version with a special temporary license could be located on the
same computer as the CAESES installation.
The software has no special demands on computational power, it can be run from
any recent notebook.
2.5 AEGIR (CNR-INSEAN)

AEGIR is a time-domain seakeeping code, based on a high-order boundary element
method (BEM) for the 3D potential flow. In the context of potential flow solvers, AEGIR
shares common concepts with WAMIT (high-order, geometry independent) and
SWAN (time-domain integration of free-surface conditions). AEGIR is specifically
tailored for ships, mono- and multi-hull. It encompasses models and numerical
methods for linear radiation, diffraction, Froude-Krylov forces and equation of
motion, as well as nonlinear Froude-Krylov forces. It also implements linear and
nonlinear body boundary conditions, linear and nonlinear steady state solution.
Transom stern conditions may be applied. The numerical solution is based on a
NURBS (non-uniform rational B-spline) representation of the geometry. Further details
of the formulation, numerical implementation, and validation of seakeeping
predictions may be found in Kring et al. (2008) and Datla et al. (2009).

Input files consist of 3DM files for the computational grid and text file for the
simulation setup. Output files include wave elevation and pressure distribution in the
form of Tecplot files, and text files with force coefficients and motions.

The tool has been proved to provide good results for the initial design phase with an
overall good validation against computational results. Details may be found in Datla
(2009).

Input output data are managed by in-house software, interfaces will be required if
the tool will be integrated with other software for geometry manipulation and
integration, optimization, structural analysis, etc.

Also for the integration in the VR platform, interfaces will be developed based on the
VR platform requirements.

AEGIR is available to CNR-INSEAN personnel and will be used within HOLISHIP project
activities. However, it cannot be distributed among the project partners.
26 Deliverable D3.1
Computer requirements: 16Gb RAM memory, windows system, no need of HPC site,
can be run both on the same computer as CAESES or not.
2.5.7 References
See Ref. [1], [2]
2.6 WARP (CNR-INSEAN)

Wave resistance computations are based on the linear PF theory (Bassanini et al
1994). The simplest linear formulation (Kelvin linearization) is obtained by assuming
that the actual flow is slightly perturbed from the free stream, and its potential
function is given by φ = Ux + φ
� , which provides the Neumann-Kelvin (NK) problem for
the Laplace equation. A further linearization, suggested by Dawson (1977), is based
on the assumption that the flow near the body is perturbed around the double
model (DM) flow, and its potential function is given by φ = Ux + ϕd + φ � . NK is usually
reasonable for slender bodies and high speeds, whereas DM is usually more suitable
for wider bodies and low speeds. Herein, once the flow is solved the wave resistance
is evaluated by both a pressure integral over the body surface and the transverse
wave cut method (Telste and Reed, 1994). The frictional resistance is estimated using
a flat-plate approximation, based on the local Reynolds number (Schlichting and
Gersten, 2000). The steady 2DOF (sinkage and trim) equilibrium is achieved by
iteration of the flow solver and the body equation of motion. Simulations are
performed for the right demi-hull, taking advantage of symmetry about the xz-plane.

Input files consist of parametric 3D (p3D) text files for the computational grid and
simulation setup. Output files include wave elevation and pressure distribution in the
form of Tecplot files, and text files with force coefficients and static motions.

The tool has been proved to provide reasonable results for the initial design phase
with an overall good validation against computational results. Specific attention
must be paid to the PF formulation used and the computational grid, especially for
very low and very high Froude numbers, and whenever flow separation is expected
to occur. Comparison with experimental data and RANS simulations in the context of
hull form optimization may be found in Serani et al. (2016a) and Serani et al. (2016b).

27 Deliverable D3.1
Also for the integration in the VR platform, interfaces will be developed based on the
VR platform requirements.

WARP can be made available under agreement with INSEAN.
There are no special computer requirements. Can be used at a linux machine, no
need of HPC, can be run both on the same computer as CAESES or not.
2.6.7 References
See Ref. [3] to [8]
2.7 Xnavis(CNR-INSEAN)
Xnavis is a general-purpose, second order, finite volume, multi-block, unsteady
Reynolds averaged Navier-Stokes Equations (uRaNSe) based solver, developed at
CNR-INSEAN (Di Mascio et al., 2006; Di Mascio et al., 2007; Di Mascio et al., 2009,
Broglia et al., 2014). The time variation of the fluid dynamics variables is computed as
interface flux balance of the control volume. In the numerical algorithm, several
schemes are implemented for the estimation of the convective fluxes, ranging from
the first order Total Variation Diminishing scheme, the second order Essentially Non
Oscillatory (ENO) scheme, the third-order upwind-based scheme and the classical
fourth-order centered scheme (for more details see Di Mascio, et al., 2009); the
various schemes have different convergence, accuracy and robustness properties.
Viscous fluxes are discretised by means of the classical finite volumes second order
formulation. Temporal discretization is done by mean of an implicit second order
scheme (three points backward). The mass and momentum conservation equation
are coupled through a pseudo-compressible approach the integration in the
pseudo-time is done with an Eulerian scheme coupled with an implicit factorization
approximated technique. The convergence in the pseudo-time is accelerated
through local-pseudo-time approach and an efficient multigrid technique. The free
surface effects are simulated through a level-set single phase methodology (Di
Mascio et al., 2007). Complex geometries and multiple bodies in relative motion are
handled by a dynamical overlapping grid approach (Di Mascio et al., 2006). High
performance computing is achieved by an efficient coarse/fine grain parallelization
which allows its use on different shared/distributed memory clusters. The code has
been widely applied for several naval hydrodynamics related problems, such as, for
example, manoeuvrability of surface vessels and underwater vehicles, sea keeping
studies of surface vessels, naval propellers and hydrodynamics of multihull vessels
(Broglia et al., 2015; Dubbioso et al., 2016; Muscari et al., 2013; Zaghi et al., 2011). The
tool is suitable to be used in the framework of contract design phase.
28 Deliverable D3.1
Input files consist of text files for the computational grid, initial conditions and
topology/connectivity/boundary conditions for overlapping blocks. Text files are
used for numerical parameters. The structure of the output files is similar.

The tool has been proved to be rather robust to all the simulations in which it has
been used. Particular attention must be paid in extreme cases (very tight
manoeuver, large motions, very high Froude number flows). Classical check on the
hull geometry (quality of the IGES file) and on the computational grid is performed
before the computation (quality, fulfilment of the requirements for the mesh spacing
at the wall and in the overlapping regions). Computational results are checked by
the analysis of the flow field and their verification (estimation of convergence
properties and numerical uncertainty); validation is performed whenever
experimental data are available.


Also for the integration in the VR platform, interfaces should be developed based on
the VR platform requirements.

Xnavis can be made available under agreement with INSEAN. This tool can be run
on several linux/unix machine/architectures, for large computations HPC is
mandatory, can be run both on the same computer as CAESES or not.
2.7.7 Reference
See Ref. [9] to [16]
2.8 Holtrop and Mennen’s method (Strathclyde)

The tool developed within CAESES® utilises Holtrop and Mennen’s method for
resistance and propulsion prediction. Each of the six aspects of the ship resistance
(frictional, appendage, wave, bulbous bow, immersed transom and model-ship
correlation) is calculated using the guidelines Holtrop and Mennen suggest. Then a
power calculation takes place using the proposed method to get estimation for the
shaft horse power.
29 Deliverable D3.1
Input: Length (Waterline) | Beam | Depth | Draft | Longitudinal centre of
buoyancy | Block, midship, prismatic and waterplane coefficients | Hull
volume | Propeller diameter | Propeller vertical position | Speed |
Gravitational acceleration | Nusselt number | Sea water density |
Propulsion constant | Number of propeller blades | Propulsion factor | Shaft
efficiency factor | Hull offset group | Appendage and frictional input |
Design waterline entrance angle | Immersed transom area | Wave
resistance constant | KG of bulb transverse area | Bulb transverse area
Output: Effective horse power | Total resistance | Shaft horse power | Wetted
surface

The feature created within CAESES® seems to be working properly. It has been tested
for a couple of containership cases for which an optimisation round has been run.
The results were as expected. Some of the required input may not be readily
available (such as the immersed transom area, the KG of bulb transverse area and
the bulb transverse area) and an assumption might lead to slightly altered results.

The feature is created within CAESES® so the use is straightforward. As long as the
input is known, the feature is run by the user and the results are automatically
presented in form of parameters.
2.9 Parametric Rolling (Strathclyde)

The tool developed within CAESES is responsible for the level 1 and level 2 checks for
parametric roll failure mode, as described in SDC 2/WP.4 IMO guidelines. Three
external software programmes are utilised to achieve the above; Maxsurf® Stability,
MS® Excel and Matlab®.
As far as the level 1 check is concerned, Maxsurf® Stability is used to produce the
metacentric height for specific wave properties. Calculations within CAESES® take
place to find the baseline value which is used to compare the one attained using
Maxsurf® Stability.
Level 2 is divided into two sublevels, namely level 2A and level 2B. Level 2A follows a
procedure similar to level 1. This means that Maxsurf® Stability is used to obtain
several values regarding the metacentric height for various wave profiles. As in level
1 case, calculations within CAESES® take place to find the baseline value, according
to IMO guidelines. The difference between level 1 and level 2 is mainly the number of
iterations for the calculations, since more parameters are taken into account (e.g.
phase offset, wave length, wave phase). In total, 16 iterations take place during level
2, compared to one during level 1.
30 Deliverable D3.1
Level 2B is more complex than the rest of the checks. Several features are used
during level 2B. These include features responsible for the Ikeda method calculations,
as well as features which connect MS® Excel with CAESES® or provide necessary
input for the connection of Matlab® with CAESES®.
As during level 2B calculations a differential equation must be solved, Matlab® is
utilised. A software connection is set up for that purpose. Matlab® is run in batch
mode. By reading .txt files produced using a feature within CAESES®; Matlab®
creates a .txt file which contains the required output values. The latter is read by
CAESES® and the check for the final level is performed.
Due to the complexity of the procedure, a single feature is created which contains
all the sub-features used for the whole process and ultimately, provides two values;
one for level 1 and one for level 2 checks. If the values are equal to 1, then the ship is
not vulnerable to parametric roll. If the value is equal to 0, then the ship does not
meet the criteria and is thus considered vulnerable.

Input: Mesh group for hull surface | Waterline length | Beam | Depth | Draft |
Block and midship coefficient | Bilge radius | Bilge keel properties | Volume
for specific draft and trim combinations (according to regulations) |
Waterplane area | Moment of Inertia for specific draft and trim
combinations (according to regulations) | Metacentric height
corresponding to selected loading condition | Location of AP and FP |
Lightship and deadweight particulars | Speed | Heading and wave
properties
Output: Level 1 and level 2 results (if the value is 1, then the ship is not vulnerable to
parametric roll, whereas if the value is 0, the ship is vulnerable to parametric
roll)

Given the complexity of the tool, the results seem to be as expected. Since there are
a few I/O files to be read during the process, the location path of each one must be
entered and checked before running the computation to ensure that the produced
results are correct (e.g. location of the MS® Excel file and .txt files used for Matlab®
calculations).

As mentioned in paragraph 3, a bit of pre-processing needs to be done before
running the computation. A batch file must be created to run Matlab®. Within
CAESES® the software connection platform is utilised to achieve the connection
between the Matlab® and CAESES®. Input and output files are in .txt format which
can be recognised by both programmes. Finally, the location of the MS® Excel file
must be entered correctly before running the appropriate feature.
31 Deliverable D3.1
2.10 MaxWave_Prop (Strathclyde)
This tool is using the method that was submitted in MEPC 70th session for the
estimation of the minimum required propulsion power for a vessel. This method has
been developed within SHOPERA project and it estimates the maximum wave head
at which the ship is capable to sail for a given speed in head waves.
This tool can be used during the preliminary design for the estimation of the minimum
required power for the ship’s propulsion. The estimated maximum wave height
corresponds to irregular head waves which is the worst condition for the evaluation
of minimum propulsion power requirement. The tool is able to predict the maximum
wave height both for fixed and controllable pitch propellers (FPP & CPP
respectively).

The tool is programmed in MATLAB coding. The required input data are the following:
• Hull wetted surface
• Hull form factor
• Total installed MCR
• Propeller rotational speed @MCR
• Number of propellers and rudders
• Shaft efficiency
• Gear efficiency
• Power take off
• Wind resistance coefficient
• Sea water density
• Air density
• Kinematic viscosity of sea water
• Wake fraction factor
• Thrust deduction factor on hull
• Thrust deduction factor on rudder
• Gravity acceleration
• Block coefficient
• Length between perpendiculars
• Frontal windage area
• Propeller diameter
• Propeller effective area ratio
• Number of Propeller blades
• Pitch over diameter ratio (in case of FPP)
• Type of propeller (FPP or CPP)
• Vessel’s speed
Propeller’s characteristics are calculated according to the Wageningen B-series

data.
This developed tool provides as an output the maximum height of head waves
where the ship is able to sail for the installed power and the given speed. In case of
32 Deliverable D3.1
controllable pitch propeller, the tool provides additionally the optimum pitch over
diameter ratio.

The validation of this tool can be performed only with comparison with other
detailed models or data from ship’s propulsion in real adverse conditions.
The tool has been tested in two different cases of ships equipped with fixed pitch
propellers and a sensitivity analysis has been performed, investigating the effect of
the propeller characteristics, resistance estimation and engine limits to the estimation
of the maximum wave height.

Input data are given as parameters into the CAESES platform through a .txt file.
Based on the MATLAB developed code, a batch file has been created that will be
able to call the corresponding function in the MATLAB environment.
2.11 MaxWave_Steer (Strathclyde)

This tool is using the method that was submitted in MEPC 70th session for the
estimation of the minimum required propulsion power for a vessel. This method has
been developed within SHOPERA project and it predicts the maximum wave height
and the maximum available speed at which the ship is capable to manoeuvre in
adverse sea conditions.
This tool can be used during the preliminary design for the estimation of the minimum
required power for the ship’s propulsion. The estimated maximum wave height
corresponds to beam waves and transverse winds which is the worst condition for
the evaluation of minimum propulsion power requirements during ship’s
manoeuvring. The tool is able to predict the maximum wave height and maximum
available speed both for fixed and controllable pitch propellers (FPP & CPP
respectively).

The tool is programmed in MATLAB coding. The required input data are the following:
• Hull wetted surface
• Hull form factor
• Rudder distance from propeller’s plane
• Total installed MCR
• Forward vessel’s speed @MCR
• Propeller rotational speed @MCR
• Number of propellers and rudders
• Shaft efficiency
• Gear efficiency
33 Deliverable D3.1
• Power take off
• Wind resistance coefficient
• Sea water density
• Air density
• Kinematic viscosity of sea water
• Wake fraction factor
• Thrust deduction factor on hull
• Thrust deduction factor on rudder in calm water
• Thrust deduction factor on rudder in beam seaway
• Rudder area
• Rudder area in propeller race
• Maximum lift coefficient on rudder
• Yaw forces ratio
• Thrust deduction factor on rudder
• Gravity acceleration
• Block coefficient
• Length between perpendiculars
• Frontal windage area
• Lateral windage area
• Lateral wind force coefficient
• Propeller diameter
• Propeller effective area ratio
• Number of Propeller blades
• Pitch over diameter ratio (in case of FPP)
• Type of propeller (FPP or CPP)
• Vessel’s speed
Propeller’s characteristics are calculated according to the Wageningen B-series

data.
This tool provides as an output the maximum height of beam waves and the
maximum available speed of the ship during manoeuvring. In case of controllable
pitch propeller, the tool provides additionally the optimum pitch over diameter ratio.

The validation of this tool can be performed only with comparison with other
detailed models or data from ship’s propulsion in real adverse conditions.
The tool has been tested in two different cases of ships equipped with fixed pitch
propellers and a sensitivity analysis has been performed, investigating the effect of
the propeller characteristics, resistance estimation and engine limits to the estimation
of the maximum wave height and vessel speed.

34 Deliverable D3.1
2.12 CAESES Connector tool for StarCCM+ (Strathclyde)
The tool connects StarCCM+® with CAESES® so that CFD runs can be performed
using the specialised software programme. The process starts with the creation of a
trimesh of a geometry defined within CAESES® (or imported to CAESES®). The trimesh
is used for STL export that is read by StarCCM+®. The next step is to set up the
software connector. Apart from the geometry, a set of java macros recorded within
StarCCM+® are needed in order to run the programme in batch mode. The output
files (in .csv format) are imported to CAESES®, along with images created in
StarCCM+® for post-processing of the results. Finally, the required arguments for the
initialisation of StarCCM+® are entered, along with the executable file.
It should be mentioned that both the input files (java macros) and the output files
(CFD results) can be accessed within CAESES® to produce specific parameters that
can be changed by the user for better control of the properties of each CFD run.

Input: Geometry/Trimesh | Java macros | StarCCM+® project file
Output: CFD results | Images for post-processing

The specific procedure is tested also by Friendship Systems® and is working without
any problems. However, the geometry should have no errors or abnormalities so that
the CFD computations are run successfully.

As described in paragraph 1, two processes need to be completed before running
the software connection. Firstly, a trimesh must be created based on the selected
geometry, which is used for STL export. Secondly, java macros must be recorded,
depending on the computations the user needs to run in StarCCM+®. These two are
the required input for the software connection.
Post processing includes images and tables created within StarCCM+®. The images
can be imported to CAESES® and configured to create visualisations of the results.
2.13 Wageningen B-series (Strathclyde)

Wageningen B-series (MATLAB)
This tool is using the Wageningen B-series data in order to estimate the thrust and
torque propeller characteristics. Main purpose of this tool is to estimate the propeller
characteristics during preliminary design phase, when only some main dimensions
35 Deliverable D3.1
and ratios of the installed propeller are known. Also, the correction for Reynolds
number (if Re>2.0E+06) is incorporated.

The tool is programmed within MAATLAB coding. The required input data include the
advance speed of the vessel, the pitch over diameter ratio, the blade effective area
ratio, the number of the propeller blades, the propeller diameter and the propeller
rotational speed.
The output data include the open water propeller efficiency, the thrust and the
torque coefficient of the propeller, as they are calculated by the B-series data.

For the validation of the tool, various propellers have been investigated and the
calculated thrust and torque coefficients have been compared with the available
graphs of B-series propellers. In case of error, a negative value is given to the open
water efficiency.
No further action is required for the calibration of the tool.

2.14 StarCCM 11 (Tritec Marine)

StarCCM 11
StarCCM is one of the largest commercial CFD solver, being capable of solving ship
hydrodynamic problems including resistance, seakeeping and manoeuvring etc.,
especially being powerful for motion problems with overset mesh. It will be used for
benchmarking study of ship hydrodynamic calculations.
ANSYS AQWA 17
ANSYS AQWA 17 is a powerful boundary element based marine and offshore
hydrodynamic solver, being able to solve motion and station keeping problems with
various options (linear, nonlinear, frequency domain, time domain etc.). It will be
used for benchmarking study of ship motions.

StarCCM 11
Input: Geometry file, loading condition, site and environment data
Output: field and integral quantities
36 Deliverable D3.1
ANSYS AQWA 17
Input: Geometry file, loading condition, site and environment data
Output: RAO, added mass, damping, wave drift loads, line tension etc.

Excellent performance of computational results

No special requirements

StarCCM and ANSYS AQWA are both commercial software tools and cannot be
made available to the HOLISHIP partners for free.
Computer requirements: on remote (HPC) site with distributed operation or on local
workstations.
2.15 NAPA (HSB)

NAPA: Naval Architecture PAckage (commercial software suite distributed by NAPA
Oy, Finland)
NAPA will be used for all hydrostatic calculations (intact/damage stability).
Applicable for both concept and contract design phase. For concept design an
adapted fidelity level for stability calculations with reduced input information and
limited calculation power will be provided.
NAPA will be run in batch mode. NAPA-internal macros will be used for processing of
data and performing the calculations.

Input:
IGES-files (hull form), ASCII-files (parameters defining main dimensions, subdivision, ...)
Output:
Tank plan (SVG-file) and tank list (ASCII), loading cases (ASCII, PDF), results of intact
and damage stability calculations (ASCII, PDF)

NAPA intact and damage stability calculation procedures are certified by Class
Societies.
NAPA macros developed within HOLISHIP and used for intact and damage stability
calculations will be verified for proper working on basis of proven projects.
37 Deliverable D3.1
Processing of IGES- and ASCII-files is a standard procedure in CAESES. Therefore, no
special connection/interface is required.

The macros developed by HSB for controlling the automatic analysis of intact and
damage stability scenarios in NAPA will be made available to interested partners of
the Holiship research project.
These macros can be used only by partners having a NAPA license: Naval
Architecture PAckage (commercial software suite distributed by NAPA Oy, Finland).
2.16 NEWDRIFT (NTUA-SDL)

2.16.1 CFD tool NEWDRIFT description and functionality
Computer Program for the Evaluation of First- and Quasi Second-Order Motions and
Loads, including Drift Forces and Mean Deviations in Regular Waves, Finite or Infinite
Water Depth, Arbitrary Frequency of Oscillation, valid for Arbitrary 3D Bodies at Zero
Speed and for Ships with Nonzero Forward Speed with Viscous Effects included (Roll
Motions).
NEWDRIFT is a fully three-dimensional potential flow theory, 3D panel code for the
analysis of the seakeeping behaviour of floating structures and ships with forward
speed under the action of regular incident waves. Added resistance in waves can
be also calculated using recently developed external software tools of NTUA-SDL
based on the far field theory or alternatively by use of semi empirical expressions.
These external tools are planned to be integrated in a new version of NEWDRIFT,
namely NEWDRIFT+. Wave bending moments and shear forces along the ship’s
length may be also calculated, provided that the longitudinal weight distribution of
the ship is given.
The development of NEWDRIFT is based on the distribution of zero-speed pulsating
Green sources over the vessel’s wetted surface for the solution of the related
boundary-value problems by application of Green's 3rd theorem and numerical
solution of a set of Fredholm integral equations. The code was initially developed for
the evaluation of first order motions and drift forces acting on zero-speed offshore
structures, but was later on extended to ships with forward speed, based on a
simplifying assumption for the free surface boundary condition according to slender
body theory to derive appropriate speed-depended correction terms for the added
masses, damping and excitation coefficients. The code has been extensively used
and validated for many years by NTUA-SDL and others (maritime industry and
universities) with very good results for offshore structures and ships of low to moderate
speed (Froude numbers up to 0.35), while results for semi-displacement high-speed
craft (Froude up to 0.70) proved also satisfactory.

The required input consists of the description of:
38 Deliverable D3.1
• The definition of the geometrical properties of the ship including the wetted
surface penalization.
• The details of the calculation case.
The wetted surface panelisation may be defined in two alternative ways:

• For each panel on the wetted surface, the coordinates of each the four nodes
are specified (old hullform description format).
• The coordinates of each node are specified one after the other and numbered
sequentially. Then, for each panel on the wetted surface, the identification
number of each of the corresponding four nodes is specified (quadrilateral
panels). The use of triangular panels is also permitted. In this case the third and
fourth node numbers are identical. When forming a panel, the nodes are
circumvented so that a right hand rule normal vector to an element is showing to
the fluid domain.
Apart from the wetted surface panelisation, the following geometrical data is
needed:
• The ship’s main dimensions (Length, Beam and Draught).
• The vertical coordinate of the centre of gravity (The corresponding longitudinal
and transverse coordinates are by default set equal to the calculated
coordinates of the centre of buoyancy).
• Roll, pitch and yaw radii of gyration, radii of product of inertia for roll-yaw, roll-
pitch and pitch-yaw.
• Width and longitudinal extend of bilge keels (if roll viscus damping is to be
included).
• Longitudinal weight distribution (if wave bending moments and shear forces are
to be calculated).
The details of each calculation case are defined by a series of variables, used to
define (among others):
• The range of wave periods or wave lengths.
• The range of wave headings
• The of wave amplitude
• The forward speed
• The water depth (finite or infinite)
• Sets of points for the calculation of velocity potential, fluid velocities and body
motions
• Selection of calculation method for the Green functions
The output of NEWDRIFT consists of a series of text files containing:

• The hydrostatic characteristics of the hullform up to the waterline under
consideration.
• The first order body motions, velocities and accelerations at the centre of
coordinates, the centre of gravity and at selected body points both in
dimensional and non-dimensional form.
• The exciting forces (Froude-Krylov, Diffraction and total) both in dimensional and
non-dimensional form.
• Added masses, damping and hydrostatic restoring coefficients.
39 Deliverable D3.1
• Wave bending moments and shear forces al selected cross-sections along the
hull.
• Drift forces and moments (zero speed case).
• Added resistance (nonzero speed case, NEWDRFT+)
• Velocity potentials, fluid velocities and body motions at selected sets of points (if
requested).
• Hydrodynamic pressures on the wetted body surface
• Depending on the calculation arguments, the output may be comparatively
brief, or extremely detailed, with detailed results for each panel on the wetted
surface, or even with the full matrices printed.

• Provided that the hullform panelisation is error-free, the code is robust and the
calculation proceeds w/o problems.
• The quality of the results may be affected by the presence of irregular
frequencies at high frequencies (short wave lengths/periods). Functionality is
included to detect the presence of irregular frequencies and warning messages
are included in the results.

For the integration of NEWDRIFT+ with CAESES, a special feature will be developed in
order to prepare the required input file with the panelisation required by NEWDRIFT.
Alternatively, the development of a special NAPA macro will be considered, in order
to integrate NEWDRIFT+ with NAPA.
An additional option to be investigated is to adapt NEWDRIFT in order to be able to
read the ν-SHALLO input files for the hullform, since ν-SHALLO is already integrated with
CAESES.
In its current version, NEWDRIFT may be used for the calculation of ship responses in
regular waves. If necessary, adequate pre- and post-processors will be developed in
order to enable the analysis of ship responses in irregular waves by use of standard
spectral analysis techniques.

NEWDRIFT may be used by the partners within the HOLISHIP project upon request and
for the purpose of the project.
NEWDRIFT can be run on a standard windows PC.
2.16.6 References
See Ref. [17], [20]
2.17 NAPA macros for Intact and Damaged Stability (NTUA)

NAPA macros for the assessment of intact stability of ships.
40 Deliverable D3.1
Once a series of loading conditions is defined, these macros maybe executed in
order to assess compliance with the requirements of A.749 Intact Stability Regulation
NAPA macros for the assessment of damaged stability of ships.
These macros maybe used for the calculation of the Attained Subdivision Index of
Passenger and Cargo ships according to the SOLAS 2009 requirements.

Input:
IGES-files (hull form), ASCII files (parameters required by the corresponding
parametric model for the definition of the detailed arrangement of a ship, its lightship
and loading conditions)
Output:
Arrangement drawings, loading cases, results of intact and damage stability
calculations.

NAPA intact and damage stability calculation procedures are certified by Class
Societies.
NAPA macros developed within HOLISHIP and used for intact and damage stability
calculations will be verified for proper working on basis of proven projects.

An IGES representation of the hullform will be transferred from CAESES to NAPA. The
necessary data required by the corresponding parametric model for the definition of
the detailed arrangement of a ship, its lightship and loading conditions will be
transferred using ASVII files.

NAPA macros developed by NTUA for the assessment of intact and damaged
stability of ships may be used by the partners within the HOLISHIP project upon
request and for the purpose of the project.
These macros can be used only by partners having a NAPA license: Naval
Architecture PAckage (commercial software suite distributed by NAPA Oy, Finland).
41 Deliverable D3.1
2.18 HydroStar (Bureau Veritas)
HydroStar is a sea-keeping software, using linear and 2nd order potential theory.
Resolution is based on Boundary Element Method (BEM). HydroStar computes all 1st
order quantities (fluid kinematics, ship motion, pressure on hull, hull girder loads) and
can assess 2nd order loads.
HydroStar can account for forward speed through the so-called encounter
frequency approximation. Besides, motion of internal liquid can be accounted for.
HydroStar computational cost is quite reasonable (a few hours at most) and is thus
suited for both preliminary and design phase.

HydroStar inputs are:
- Hull mesh (without appendages), composed of quadrangle and triangle.
- Ship mass distribution
- Wave data (in case spectral calculation is performed)
Optionally:
- Additional damping to account for viscous effect
- Additional stiffness matrix (to account for internal free-surface effect, for
instance)
- Internal tank mesh, to account for internal fluid motions dynamically.
HydroStar outputs are:

- Transfer function of
o Ship motion / velocity / acceleration
o Wave pressure
o Internal loads
o Hydrodynamic coefficient (added mass , wave damping and
excitation forces)
- Short-term / Long term statistics of
o Ship motion / velocity / acceleration
o Wave pressure
o Internal loads
Outputs are text files (which are usually displayed by a dedicated viewer included in
HydroStar)

Provided that the mesh does not show significant issue, is very robust. The consistency
of the mesh can be check with a module included in HydroStar.
42 Deliverable D3.1
2.18.4 Connection to Caeses
Pre-process should consist in exporting the data contained in the CAESES model to
text file compatible with HydroStar. (It is assumed that CAESES has surface meshing
capabilities). Similarly, getting HydroStar results into CAESES would consists in parsing
HydroStar output files. Alternatively, HydroStar viewer could be started from CAESES.

Pre-process should consist in exporting the data contained in the VR platform model
to text file compatible with HydroStar. Similarly, getting HydroStar results into VR
platform would consists in parsing HydroStar output files. Alternatively, HydroStar
viewer could be started from VR platform.

HydroStar is a commercial software but it will be made available for free within the
project.
Computer requirements: HydroStar works on any computer with windows7 or above
(in 64bits version). It is easier to have it installed on the same computer as CAESES
(although not mandatory).
3 Conclusions
In the present report, a series of software tools for the stability and hydrodynamic
analysis of ships and other maritime assets, offered by the HOLISHIP/WP3 partners for
integration with the design and/or virtual demonstration platforms are presented.
Emphasis has been given on reporting each tool’s input/output data structure, the
robustness and quality of the associated computational results as well as their
capability for integration into the WP7 and WP8 platforms.
The collection of software tools cover all aspects of stability and hydrodynamic
calculations necessary for both concept and contract design phases.
More specifically, for the hydrodynamic analysis of ships and floating structures there
are four RANS based tools that are capable of calculating a ship’s resistance and
propulsion characteristics, ship motions and added resistance in waves, and
manoeuvring characteristics (see Table 1). These tools, due to their complexity and
computational requirements are typically used during the contract design phase,
however they might as well be used – already - during the concept design given the
better integration and hence improved turn-around times anticipated with the
HOLISHIP platform.
In addition, there are seven software codes based on potential theory. Two of them
may be used for the calculation of calm water resistance, being more suitable for
application during the concept design phase. The remaining five software tools are
used for the evaluation of seakeeping characteristics, added resistance in waves,
wave forces etc.
43 Deliverable D3.1
Seven hydrodynamic analysis tools exploit empirical/statistical formulae for fast
predictions, being suitable for the concept design phase (Table 2). The NAPA
software package will be used in HOLISHIP mainly for stability calculations and for the
parametric modelling of the compartmentation of ships, both for the concept and
contract design phase. Finally two more codes are listed in Table 2 as supplementary
tools. These tools will be used for facilitating the integration into the design platforms
of the RANS codes StarCCM+ and Fresco+, respectively.
A tentative distribution of the involvement of WP3 partners in the Application Cases is
presented in Table 3.
Contact: Alexandros Ginnis, ginnis@naval.ntua.gt

44 Deliverable D3.1
1 5 8 19 23 24 27 34 38
HSVA Bureau Veritas CNR HSB MARIN SINTEF NTUA TRITEC USTRATH
Effort in WP 3
21 2 14 6 6 5 10 1 4
(PM):
Application AC AC
Case Leader WP Partner effort in Application Cases
2 PM 2 PM
WP No Lifting
AC 1: OSV RR-AS 0 0 0 0 0 0 0
9 hydrodynamics Operation
work planned (VERES)
2 PM
1 PM
AC 4: MP WP To be
DCNS 0 0 0 0 0 To be 0 0
Ocean Ship 12 defined
defined later
later
6.5 PM
CFD for rudder
AC 5: configurations;
WP
Merchant MARIN 0 0 0 0 manoeuvring 0 0 0 0
13
Vessel / VVF coefficients
(Empirical formula/
ReFresco)
6 PM
AC 6:
Bulbous bow
Merchant 1 PM
optimisation 0 PM 4 PM 6 PM
Vessel WP Trim calculations,
NTUA (nuSHALLO / 0 Seakeeping 0 Seakeeping Seakeeping 0 0
Design for 14 loading analysis
FreSCo+ / (Aegir) (VERES) (NEWDRIFT)
Life-cycle (NAPA)
Response
optimisation
Surfaces)
3 PM 8 PM
form optimisation 4 PM 2 PM Seakeeping 2 PM 3 PM
AC 8: RoPax 4 PM
WP (1 PM); CFD (3 PM) no calculations: Seakeeping To be
Design Uljanik To be 0 0
16 propulsion in Wave loads (1 hydrodynamic 1PM. Design & & CFD defined
Optimisation defined later
waves (1 PM), PM) work planned optimization: calculations later
aero (1 PM) 7PM
4 PM 3 PM
Form + Intact / damage
2 PM
AC 9: propulsion 2 PM stability
ELO- WP No
Double End optimisation Seakeeping calculations 0 0 0 0 0
MATIC 17 hydrodynamics
Ferry (calm water), Analysis (NAPA) and
work planned
manoeuvring, integration
(FreSCo+) concept design
Table 3: Involvement of WP3 partners in each Application Case
45 Deliverable D3.1
4 References
[1] Datla R., Kim H.Y., Stebe J.R., “Evaluation of a CFD Program AEGIR™ for Bare
Hull Resistance and Seakeeping Prediction Capability,” Technical Report
NSWCCD-CISD–2009/010, Naval Surface Warfare Center - Carderock Division,
July 31, 2009.
[2] Kring D., Milewski W., Connell B., Petersen B., “AEGIR™ Time-domain Seakeeping
Program: Main Executable and I/O User Notes,” August 13, 2008.
[3] Bassanini, P., Bulgarelli, U., Campana, E.F., Lalli, F. (1994), The wave resistance
problem in a boundary integral formulation, Surveys on Mathematics for
Industry 4, 151-194.
[4] Dawson, C.W. (1977), A practical computer method for solving ship-wave
problems, In: Proceedings of the 2nd International Conference on Numerical
Ship Hydrodynamics, Berkeley, pp 30–38.
[5] Serani, A., Fasano, G., Liuzzi, G., Lucidi, S., Iemma, U., Campana, E. F., Stern, F.,
Diez, M. (2016a). Ship hydrodynamic optimization by local hybridization of
deterministic derivative-free global algorithms. Applied Ocean Research, 59,
pp. 115-128.
[6] Serani, A., Campana, E.F., Diez, M., Stern F. (2016b). A Multi-Objective
Optimization: Effects of Potential Flow Formulation and RANS. In: Proc. 15th
International Conference on Computer Applications and Information
Technology in the Maritime Industries, COMPIT 2016, Lecce, Italy.
[7] Schlichting, H., Gersten, K. (2000), Boundary-Layer Theory, Springer-Verlag,
Berlin.
[8] Telste, J., Reed, A. (1994), Calculation of transom stern flows, Proceedings of the
Sixth International Conference on Numerical Ship Hydrodynamics, pp. 78-92.
[9] Broglia, R., Dubbioso, G., Durante, D. & Di Mascio , A., 2015. , Turning ability
analysis of a fully appended twin screw vessel by CFD. Part I: Single rudder
configuration. Ocean Engineering, 105, pp.275-86.
[10] Broglia, R., Zaghi, S., Muscari, R. and Salvadore, F., "Enabling hydrodynamics
solver for efficient parallel simulations", July 2014, Proceedings International
Conference on High Performance Computing & Simulation (HPCS),
10.1109/HPCSim.2014.6903770, Bologna, Italy, pages 803-810.
[11] Di Mascio, A., Muscari, R. & Broglia, R., 2006. An Overlapping Grids Approach
for Moving Bodies Problems. In Proceedings of 16th Int. Offshore and Polar
Engineering Conference. San Francisco, California (USA). 2006.
[12] Di Mascio, A., Broglia, R. & Muscari, R., 2007. On the application of the single-
phase level set method to naval hydrodynamic flows. Computers & Fluids, 36,
pp.868–86.
[13] Di Mascio, A., Broglia, R. & Muscari, R., 2009. Prediction of hydrodynamic
coefficients of ship hulls by high-order Godunov-type methods. J. Marine Sci.
Tech., 14, pp.19-29.
[14] Dubbioso, G., Broglia, R. & Zaghi, S., 2016. CFD analysis of Maneuvering
Characteristics of a Submarine Model. Accepted to Ocean Engineering.
[15] Muscari, R., Di Mascio , A. & Verzicco, R., 2013. Modeling of vortex dynamics in
the wake of a marine propeller. Computers and Fluids, pp.65-79.
[16] Zaghi, S., Broglia , R. & Di Mascio, A., 2011. Analysis of the interference effects for
high-speed catamarans by model tests and numerical simulations. Ocean
Engineering, 38(17), pp.2110-22.
[17] Papanikolaou, A., Schellin, T., Zaraphonitis, G., “A 3D Method to Evaluate
Motions and Loads of Ships with Forward Speed in Waves”, Proc. 5th Int.
46 Deliverable D3.1
Congress on Marine Technology, IMAEM 90, pp 452-457, Athens, May 1990
(Greece).
[18] Zaraphonitis, G., Papanikolaou, A., “On the Numerical Prediction of Seakeeping
and of Structural Loads of High-Speed Vessels”, Applied Ocean Research, 26
(2004), pp. 274-287.
[19] Liu, S., Papanikolaou A., Zaraphonitis, G., “Prediction of added resistance of
ships in waves”, Ocean Engineering, vol. 38, pp. 641-650, 2011.
[20] Liu, S., Papanikolaou, A., Zaraphonitis, G., “Practical Approach to the Added
Resistance of a Ship in Short Waves”, Proc. Ocean (Offshore) and Polar
Engineering Conference (ISOPE-2015), 21-26 June, Hawaii (USA).
47 Deliverable D3.1
5 Indexes
5.1 Index of tables

Table 1: List of Software Tools – Potential Flow & RANS ......................................................11
Table 2: List of Software Tools – Other Tools ..........................................................................12
Table 3: Involvement of WP3 partners in each Application Case ...................................45
5.2 Index of figures

Figure 1: Graphical representation of ν-SHALLO results, planar view ................................13
Figure 2: Graphical representation of ν-SHALLO results (including source strengths) .....15
Figure 3: Graphical representation of ν-SHALLO results (including source strengths) .....15
Figure 4: Example of FreSCo+ result file (time series of hull forces) ..................................17
Figure 5: File format for VERES Geometry Files .....................................................................22
Figure 6: GUI for Ship Speed and Powering input ...............................................................23
Figure 7: ReFRESCO summary description ............................................................................53
Figure 8: Typical examples of ReFRESCO graphical output ..............................................54
48 Deliverable D3.1
6 ANNEX I
6.1 The MARIN eXtensible Modelling Framework (XMF)

Introduction
The Extensible Modelling Framework specifies a software architecture using graph
technology for structuring the application code introducing a high level of flexibility
and extensibility. Because of the flexibility of graphs incremental design of new
applications and gradual restructuring of existing systems can be done. By using a
clear functionality layering the application can easily be integrated in other
simulation systems with minimal effort and without changing the core of the code
even facilitating the integration efforts. Throughout the design of the framework
extensive use of the Bridge, Composite, Visitor, Callback, Proxy, Facade, Factory and
Observer design patterns has been made.
Purpose
This document describes the architecture and design of the Graph Centric
Application Architecture which serves as the starting point for the design and
implementation of future simulation applications. The XMF defines the architecture of
a single simulation application and it does not specify anything about the
architecture of distributed simulations, although the XMF facilitates the software
engineer to integrate applications into larger (distributed) simulations. Simulation
systems are traditionally based on the classic edit-run-analyse paradigm, e.g. model
design, model execution and execution analysis. The semantics of the mentioned
three phases suggest that the execution of the three phases must be done in the
specified order. The Extensible Modelling Framework supports parallel execution of
the edit-run-analysis phases when it is required by a simulation application. The
Extensible Modelling Framework will not restrict to sequential execution of the edit-
run-analysis phases. Therefore, the choice between parallel or sequential simulation
phases is a system designer owned decision.
6.2 THE GLOBAL APPLICATION ARCHITECTURE

Introduction
The experience of the last 15 years of real-time distributed simulation development
leads to the observation that three different life cycles can be identified. The life
cycles of the business code, the persistent data and the communication
mechanism. The life cycle of the code containing the specific knowledge of a
company, the business code, will be driven by topics like improving functionality,
changing methods etc. The communication with other components of the simulation
will be based on standards like DIS, HLA, XMSF, or proprietary technologies etc. These
technologies have their own life time dynamics and the fact that some applications
must have the capability to be integratable into different simulators makes the
integration effort really difficult. The same applies to the persistent data that must be
loaded by a system. Database standards come and go in their own pace. Today,
XML is probably the norm but what about tomorrow? How do we integrate a new
49 Deliverable D3.1
application into an old one? And what about proprietary file formats? This leads to a
series of requirements
The business code must be independent of the used persistent data representations
and structure.
The business code must be independent of the used middleware and
communication software. The middleware glues the different components together
into the final product.
The business code must facilitate the middleware layer in connecting it to a
communication infrastructure.
The middleware layer must be as thin as possible since it will become the glue
between the different parts and has to be redone when the communication layer
changes.
These issues will be addressed by the three tier architecture which is presented in the
next section.
Three tier architecture
The three-tier architecture suggests a separation of an application into three layers,
the Presentation Layer, the Business Layer and the Data layer. In simulation
applications the following layers can be identified: the Business layer containing the
core functionality, e.g. the mathematical model code, the Data layer defining the
access to the persistent configuration data based on the generic file access
technology, the Communication layer handling the interaction with other
(distributed) applications of the simulation and the Middleware layer gluing
everything together. In general, multi-tier will be more suitable since a particular
application can contain several other layers as well.
The aim of multi-tier application architectures is to separate an application into
different appropriate abstraction layers with clear API’s and to hide the intrinsics of
the layers from each other. So, in terms of distributed simulation the communications
code should not be visible in the business code. The same applies to the
configuration database; the business code should not be exposed to the format of
the configuration files.
Data tier
When a particular simulation application is developed for a particular simulator,
which is the case most of the times, some kind of input file or database is developed
for that particular simulator also. If this application is integrated at a particular
moment into a larger simulation, that simulation probably defines its own integrated
input database. By disconnecting the in-core data structures of an application from
its persistent data structures and formats, applications can very easily be adapted to
access other data structures and formats. By using a Loader proxy technology this
knowledge of the data structures and formats can be defined outside the
application itself. At the top level of a generic loader proxy API a set of standard
functions are provided to read in files and convert databases of unknown type. This
functionality is designed with the notion of a database converter. A database
50 Deliverable D3.1
converter is an abstract entity that knows how to perform some or all of a set of
database format conversion functions with a particular database format. Moreover,
converters must follow certain API guidelines for standard functionality such that they
can be easily integrated into a simulation application in a run-time environment
without needing any prior knowledge of a particular converter’s existence. This run-
time integration is done through the use of dynamic shared object (DSO) libraries on
UNIX/Linux. On Microsoft Windows this is accomplished using Dynamic-link Libraries
(DLL).
Adding a new loader to read a new file format is adding a new DSO and or DLL that
understands the new file format without altering the code base of the framework
and application.
Business tier
The business tier is the software reflection of the core knowledge. Al the other tiers
have a peripheral function only. In general, the bulk of the code lives in the business
tier and must be designed independent of the final system(s) in which it will be
integrated. However, business tier engineers must realise that their code eventually
must be integrated into a final system and that they cannot design the business tier
neglecting that fact. To reduce the complexity of the middleware layer the business
tier must be designed in such a way that it facilitates the middleware design and
implementation as much as possible. This middleware tier must be designed and
implemented for every application and it would be very convenient when the costs
involved can be minimised. The next chapter introduces the graph centric
application architecture for the business tier addressing the issues mentioned.
Communication
The communications layer in the multi-tier architecture handles the data
communication in distributed simulation applications. Distributed does not
necessarily mean multiple interacting processes running on multiple hosts connected
in a network but also multiple processes interacting with each other running on a
single host. Traditionally this is handled by Distributed Interactive Simulation (DIS), High
Level Architecture (HLA), Extensible Modelling and Simulation Framework (XMSF) and
dozens of proprietary communication protocols. The communications layer is the
glue that allows the combination of simulations or simulation components,
interfacing and interacting with each other forming a larger (distributed) simulation.
Currently, the HLA is the standard, IEEE 1516, middleware for simulations especially for
military simulations. The HLA can be considered as the successor to the DIS standard,
IEEE 1278.1a, which was developed in the early years of the past decade. The HLA
was developed by the US Department of Defence to fill the need for an architecture
that can implement the vision of a higher level of simulation capability.
Interoperability and reuse of simulation applications is the main target of the DoD in
an era of shrinking budgets and increasing costs. The design of the HLA was based
on the following considerations:
It should be possible to decompose a large simulation problem into smaller parts.
Smaller parts are easier to define, build correctly, and verify.
51 Deliverable D3.1
It should be possible to combine the resulting smaller simulations, the federates, into
a larger simulation system, the federation.
It should be possible to combine the smaller simulations with other, perhaps
unanticipated, simulations to form a new simulation system.
Those functions that are generic to component-based simulation systems should be
separated from specific simulations. The resulting generic infrastructure should be
reusable from one simulation system to the next.
The interface between simulations and the generic infrastructure should insulate the
simulations from changes in the technology used to implement the infrastructure,
and insulate the infrastructure from technology in the simulation.
Fundamentally, the HLA is an architecture to support component-based simulation,
where the components are individual simulations. The architecture also supports
building simulations that are distributed across multiple computers. In standalone,
single process applications the communications layer probably does not exist.
Middleware tier
The middleware tier connects all the different components, business tier, data tier,
communication, together resulting in an executable that can either run standalone
or takes part in a bigger simulation application using some kind of communication
layer. Since the middleware must be designed and implemented over and over
again for all the different applications of the core model it must be as thin as
possible. To realize this, the business tier must facilitate the middleware tier in
achieving this.
52 Deliverable D3.1
Figure 7: ReFRESCO summary description
53 Deliverable D3.1
Figure 8: Typical examples of ReFRESCO graphical output
54 Deliverable D3.1

Requirements and Standards: Deliverable D3.1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Requirements and Standards: Deliverable D3.1

Uploaded by

Copyright:

Available Formats

Ref.

Holistic Optimisation of Ship Design and Operation for Life Cycle

Horizon 2020 - 689074

Requirements and Standards

Document Title: Requirements and Standards

Work Package(s): WP 3, Task 3.1

Dissemination level: Public

Deliverable nature: Report

Lead beneficiary: NTUA

Responsible author: Alexandros Ginnis, NTUA

Version Date Description

1 17/2/2017 First version

2 24/2/2017 Updated version

3 24/2/2017 Version for QC

4 28/2/2017 Revised final version

1.3 RESULTS AND ACHIEVEMENTS........................................................................................................................ 9

2.1 POTENTIAL FLOW CODE: ν-SHALLO ............................................................................................................. 13

2.1.2 Input and Output data structure ..................................................................................................... 13

2.1.5 Licensing and System Requirements ............................................................................................... 15

2.2.1 Software tool description and functionality .................................................................................... 16

2.2.2 Input and Output data structure ..................................................................................................... 16

2.2.3 Robustness and quality of computational results ........................................................................... 17

2.2.4 Connection to CAESES ..................................................................................................................... 17

2.3 GRID GENERATION TOOL: HEXPRESS ......................................................................................................... 19

2.3.3 Robustness and quality of computational results ........................................................................... 19

2.4 REFRESCO AND XSHIP (MARIN)............................................................................................................... 20

2.4.4 Connection to CAESES ..................................................................................................................... 21

2.5 SHIPX WORKBENCH (SINTEF) .................................................................................................................... 21

2.5.3 Robustness and quality of computational results ........................................................................... 23

2.5.5 Licensing and System Requirements ............................................................................................... 25

2.6.1 Software tool description and functionality .................................................................................... 26

2.6.4 Connection to CAESES ..................................................................................................................... 26

2.6.6 Licensing and System Requirements ............................................................................................... 26

2.7.1 Software tool description and functionality .................................................................................... 27

2.7.3 Robustness and quality of computational results ........................................................................... 27

2.7.4 Connection to CAESES ..................................................................................................................... 27

2.7.5 Connection to VR platform .............................................................................................................. 28

2.7.7 References ....................................................................................................................................... 28

2.8 XNAVIS(CNR-INSEAN) ............................................................................................................................ 28

2.8.1 Software tool description and functionality .................................................................................... 28

2.8.5 Connection to VR platform .............................................................................................................. 29

2.8.6 Licensing and System Requirements ............................................................................................... 29

2.9.4 Connection to CAESES ..................................................................................................................... 30

2.10.2 Input and Output data structure ................................................................................................. 31

2.11.1 Software tool description and functionality ................................................................................ 32

2.11.3 Robustness and quality of computational results ....................................................................... 33

2.12.1 Software tool description and functionality ................................................................................ 33

2.12.3 Robustness and quality of computational results ....................................................................... 34

2.13.1 Software tool description and functionality ................................................................................ 35

2.13.3 Robustness and quality of computational results ....................................................................... 35

2.13.4 Connection to CAESES ................................................................................................................. 35

2.14 WAGENINGEN B-SERIES (STRATHCLYDE) ....................................................................................................... 35

2.14.2 Input and Output data structure ................................................................................................. 36

2.14.3 Robustness and quality of computational results ....................................................................... 36

2.14.4 Connection to CAESES ................................................................................................................. 36

2.15.3 Robustness and quality of computational results ....................................................................... 37

2.15.4 Connection to CAESES ................................................................................................................. 37

2.16.4 Connection to CAESES ................................................................................................................. 38

2.17.1 CFD tool NEWDRIFT description and functionality...................................................................... 38

2.17.5 Licensing and System Requirements ........................................................................................... 40

2.18.3 Robustness and quality of computational results ....................................................................... 41

2.18.5 Licensing and System Requirements ........................................................................................... 41

2.19.2 Input and Output data structure ................................................................................................. 42