PIAS Manual  2019
Program for the Integral Approach of Shipdesign
Layout: Design and utilization of the ship's layout
Layout is the PIAS module with which the internal geometry of the ship is recorded, managed and used. It goes without saying that that internal geometry can consist of bulkheads, decks, compartments and other spaces, but it may also contain additional data, like the weight group of the volume of a specific compartment, or the sounding pipe geometry. A description of the background of Layout can among others be read in the Compit'11 paper. Briefly, Layout offers the following modelling possibilities:

  • Defining compartments through compartment limits (equivalent to the manner in which in module Compart, at the precursor of Layout, compartments are defined).
  • Defining continuous bulkheads and decks, between which the compartments are formed.
  • Support by means of reference planes, to which compartment coordinates as well as bulkheads and decks may refer.
The first two methods are mutually convertible, which means that one is able to convert from bulkheads/decks to compartments as well as vv. Briefly, Layout offers, furthermore, the following functions in the field of internal geometry:

  • Calculation of tank tables, trim correction tables etc., in a variety of formats.
  • Output of a schematic tank plan and 3D views of compartments.
  • Conversion from and to the precursor of Layout: PIAS module Compart.
  • Definition of the layout of a 2D subdivision plan, and its output to paper, bitmap or DXF file. This subdivision plan may function as basis of the general arrangement plan.
  • Function as server of internal geometry, which is able to respond to requests of other software applications. So, for example, the shape of a deck or of a compartment can be made available to other (CAD)software upon request.
  • Import and export of the internal geometry in XML format.

Definitions and basic concepts


A plane is endless, and can have any position in the space, can therefore also be angled. But every cross-section of a plane is straight, so it cannot be curved or twisted.
Physical plane
A physical plane is a plane which can be limited, and can be the separation between subcompartments. As a rule, physical planes are used to model bulkheads and decks.
Reference plane
A reference plane is a plane to which the sizes of other entities can be normalized. The use of reference planes can be useful for later design modifications, but its use is not obligatory.
A compartment is a closed, liquid-proof space in the ship; as a result, one can pour water in a compartment and the water will not get outside of it. As for the manner of modelling, there is no distinction between a wet compartment, a dry compartment, a hold, an engine room or a closed quarter deck. In short, anything that is watertight is a compartment for PIAS. A compartment is built from one or more subcompartments.
A subcompartment is a ‘logical’ building block of a compartment. A subcompartment has no physical meaning, the concept has only been introduced to make it a bit orderly for people to define a complex compartment. A subcompartment can be positive or negative, in the first case the shape of the subcompartment is added to the others, in the second case it is deducted. A subcompartment can be one of three different types, which will be explained below:
With coordinates
A subcompartment of the type ‘with coordinates’ is simply limited by typed coordinates (which may refer to a reference plane). The user is free to define subcompartments of this type overlappingly, or to let holes exist between them. An example of a subcompartment of this type is depicted in the figure below, where with four coordinate pairs a part of the ship is ‘carved out’, which constitutes the subcompartment. Please see that the coordinates may very well fall outside the ship hull boundary, if that is the case the ship boundary is simply taken also as subcompartment boundary (by the way, if shell or deck are indeed a subcompartment boundary, than it is even beter to use ∞ as boundary than to exactly use the shell breadth or deck height. See also Intersection with the hull shape).
Space generated between planes
A subcompartment of the type ‘space generated between planes’ coincides with the space generated between physical planes. This type of compartments is unique, and cannot overlap between themselves.
External PIAS hull form
A subcompartment of the type ‘external PIAS hull form’ (a.k.a. external subcompartment) is meant for a subcompartment being too complex for one of the other types, for example because its limits are curved, such as those of a gas tank. Such a subcompartment can be defined with a PIAS shape design or definition module, as if it is a regular ship shape. Subsequently, that ‘hull form’ is indicated as subcompartment, after which it is integrally included in all following steps and calculations. See the example below, where a forty meter gas tank is defined as ordinary PIAS hull form — with Hulldef or Fairway — and subsequently positioned in the actual vessel, with a longitudinal shift of twenty meters and a vertical shift of one meter, which brings the tank to its real position.
From these definitions follows an important difference between a subcompartment of the type ‘space generated between planes’ and the other types. For those other types have their own shape definitions, that form one whole with non-geometric characteristics, such as their names and permeabilities. But a space generated between physical planes always has a shape of its own, also without a subcompartment being assigned to it. Normally, a subcompartment of the type ‘space generated between planes’ is assigned to such a space, but that is not necessarily so. When no subcompartment has been assigned to such a space, that is reported by the program as non-assigned space. Functions are available in the GUI to assign such a space to or to unlink it from a subcompartment. The last is simply done by removing the subcompartment from the tree view, the space between the physical planes will remain, however.
Subcompartment type ‘with coordinates’.
Subcompartment type ‘external PIAS hull form’.

Use of different types of subcompartments

There are three types of subcompartments, as defined above. They can be used interchangeably at random, the use of different types of subcompartments within one compartment is also allowed. Although the user is entirely free to choose the type, there are still a few directions to be given:

  • The use of physical planes is practical, firstly because the nomenclature can be made much faster with them, and secondly because the bulkheads and decks are known explicitly with them, which may be useful in the event of subsequent work or computer applications. The subcompartments that are genenerated between the planes are of the type ‘space generated between planes’, the word speaks for itself. Although this type of subcompartment in principle can be applied anywhere, it could be practical to limit its application to the larger spaces that are bounded by the primary physical planes. Suppose one would like to define, for example, a fuel oil day tank in this manner, then that would very well be possible, but then one would end with six physical planes. And in the event of a multiple of such tanks the number of physical planes will be very large, that large that one can easily lose track of the situation. Such a tank could perhaps better be defined as ‘with coordinates’, if neccessary using reference planes so that later design modifications can be processed faster.
  • The type ‘with coordinates’ can be used anywhere where the subcompartment boundary consists of the hull shape, combined with (maximally twelve) boundary points. This definition is conceptually simple, overlapping subcompartments can also be defined with this, by the way, which can be an advantage or a disadvantage, that is not relevant right now, but one should be well aware of this.
  • The type ‘external PIAS hull form’ is meant for subcompartments with non-flat boundaries. Subcompartments with flat boundaries (which may very well be angled) can be defined in a more practical manner with another type. By the way, subcompartments of the type ‘space generated between planes’ and ‘with coordinates’ are always trimmed by the ship shape, save that of the type ‘external PIAS hull form’.

Naming convention for compartments etc.

Names of (sub)compartments, reference planes and physical planes can be 50 characters long, while all visible characters are allowed. Compartment names must be unique, which is not a basic requirement in itself, but in order to keep a compartment collection orderly it has been decided upon to require this. Names of physical planes need not be unique, it might occur that there are planes with different shapes, but that they are still at the same position, so one can give them the same name. It is doubtful whether this is practical, but that is up to the user. Reference planes have infinite dimensions, so there is no need to have planes at the same position, and it may therefore be required that their names are unique. Subcompartment names only matter within one compartment, so it is not necessary that they have a unique name. When copying a (sub)compartment or reference plane, the copy gets the name of the original with the addition ‘(copy)’. At least, when there is place left for that and when that name is not yet in use, otherwise the copy keeps its original name.

Links to subcompartments

As mentioned at the definition of subcompartments, these can be positive or negative. It is not necessary, but a positive and a negative subcompartment are often used to model exactly the same space. For example, a fuel oil day tank in the ER as positive subcompartment, and exactly the same space as negative subcompartment which is deducted from the ER. It may be practical in such cases to define the shape of that subcompartment not twice, but only once, and to make a link to the second one. The advantage of this is that a geometry modification in one subcompartment is directly applied to the second one.

Such a link only applies to the shape and the name, not to the permeabilities (μ). There are sound reasons for that, because permeabilities may vary, like in our example where when the μ of the MK is 85%, that of the subcompartment to be deducted must also be 85%, because there would be more volume deducted than added. But the μ of the fuel oil day tank is of course 98% (or any other permability chosen by the user).

Intersection with the hull shape

Subcompartments of the type ‘with coordinates’ and ‘space generated between planes’ can be defined beyond the hull shape, typically to plus or minus ∞ (which can be defined by typing a <I> resp. <-><I> instead of a number, from infinite). In that case, the intersections between subcompartment and hull shape are determined automatically. The hull shape itself can be defined through frames (with module Hulldef) or as solid model (with Fairway). In the latter case, an entire planes model of the hull is available with which any subcompartment intersection can be made. But in the event of a frame model, there are only frames, there is nothing in between. That does not matter at all, PIAS has (traditionally) sufficient methods to arithmetically find an adequate solution, but for drawing the program must be driven back on interpolation of a subcompartment plane with those frames. In case of a longitudinal plane, such as a deck or longitudinal bulkhead, there will be in general sufficient intersections between that plane and the frames, so that a sufficiently accurate intersection line can be drawn. But in the event of angled bulkheads it is very well possible that there are only a few intersections with the frames. In theory, the intersection line can be drawn on the basis of these intersections, but as their number is small, its accuracy can be low. There are two options here, the first one is to give a shrug, because we are only dealing with a picture and not with the calculation results, and the second one is a more complete definition by means of more frames, that can be quickly generated, for example, with Fairway.

Popup menu for geometry of planes and points

Popup menu with parameters of direction and position of a plane

This menu is used to define the orientation, which is the direction and position, of a plane. Not only of a physical plane, but also of a reference plane. Here one can fill in:

  • The position in metres of the plane. Please see that this position — not only as given here, but also as can be given just below, in frames or relatively — can be constrained by other planes, as explained in Limited positioning of a physical plane.
  • The position in frames (when it regards a transverse bulkhead or transverse plane).
  • Possibly the relative position, which is the position in relation to a reference plane.
  • When the plane has been entered referrally, then the reference plan in question can be chosen in such expendable row, either by its abbreviation (left field) or by its entire name (right field).
  • As alternative for browsing through the reference planes list with those openklapbare rows the function [Find] can be used. For that one types the plane abbreviation in the left row (or in the right one its entire name) and presses the [Find] button.

Furthermore, this window consists of two functions in the upper bar:

  • [Edit refvlak], to jump to the reference plane menu, in order to add or adjust a reference plane.
  • [anGled] to change an orthogonal bulkhead or plane into an angled plane. See Angled planes for more details. This function is not always available though. For example, when one changes a reference plane this is lacking, since one would be able then to convert a reference plane, for example, from transverse to angled, as a result of which all references of other transverse planes to this reference plane would be senseless.
  • [Help reader], opens the familiar F1 help reader.
  • [Help]→[Keys], with which the list of shortcut keys appears that is applicable in this window:
EnterNext input field
TabNext input field
Shift TabPrevious input field
Ctrl-ASelect everything in box
Ctrl-DelRemove everything from box
Alt-ZFind reference plane
Alt-TTransverse bulkhead (only applicable to a new plane)
Alt-LLongitudinal plane (only applicable to a new plane)
Alt-DDeck (only applicable to a new plane)

So, this menu can be used to define the orientation of a plane, or to specify that a plane lies on a certain, fixed, distance from a reference plane. More os less the same menu is used to define points with respect to a reference plane. This popup menu is invoked by pressing <Enter> in the cell where a plane or point coordinate can be given. Two more remarks ons reference planes:

  • Those can be defined in the GUI, as well as in the alphanumeric table as discussed in List of reference planes.
  • If a coordinate is given relative, then in all input windows, in the status bar at the bottom, th erelative as well as the absolute value is presented from the cell where the text cursor resides.

Angled planes

Definition menu angled plane.

The orientation of an orthogonal plane, that is a transverse plane, longitudinal plane or horizontal plane, is entirely recorded with its type and one digit. In order to record an angled plane, however, more data are required. There are innumerable manners in which an angled plane can be recorded, but in Layout has been opted for doing this by means of three points in the space, because this is considered most intuitively. Those three points are in a menu, an example of which is given above. This menu essentially includes for any of the tree points a row, with in the columns the length, breadth and height coordinates of that point. As a matter of fact, these points are unrelated to any other point of the ship or its subdivsion — although the are fit to be linked to a reference plane. The last column contains the distance from that point to the angled plane. For the plane is not directly adjusted to the position of the three points, but for reasons of safety it has been chosen that the function [Generate] must be called upon there later on. Other functions that are available in the upper bar are:

  • [Shift]: shift this point to the plane, along the axis of this point. So, for example, for a height coordinate a vertical shift.
  • [Project]: project this point on the angled plane, according to the direction perpendicular to the plane.
  • [Orthogonal]: reshape this plane to an orthogonal plane that is most similar to this angled plane.
  • [Cancel]: leave this menu without saving the modification.

Limited positioning of a physical plane

The constellation of physical planes also fixes the nature and shape — or, put another way, the topology and geometry — of the enclosed spaces, the compartments. That's nice, but it also introduces a limitation because planes cannot be passed by their immediate neighbors; that would, after all, compromise the entire ‘logic’ of the subdivision. That can extent further than one might think at first glance, because planes can also indirectly (by means of reference planes) get a location. That's all internally monitored in Layout, and if one would place a plane beyond its topological limit it is pushed back to its extreme limit. No warning is given on that — that might in fact lead to rather long warning lists, from which nobody benefits — but at least you now know the reason if a plane does not pass a certain location.

Main menu

Having started up Layout, one enters the main menu, the various options of which are explained in more detail in the following sections.

Graphical User Interface of planes and compartments

GUI components


An example of the GUI (Grafical User Interface) is shown in Left mouse button and modus. The GUI can consist of eight windows:

  • Three orthogonal cross-sections, namely a transverse cross-section, longitudinal cross-section and horizontal cross-section.
  • A 3D (rendered) view.
  • A tree view window with a tree of compartments and subcompartments.
  • A tree view window with physical planes.
  • A tree view window with reference planes.
  • A constraint management tree view window in which design targets can be used. For the time being, this constraint management facility — from which goald en operation is discussed here — remains undiscussed in this manual. This feature will be released in the course of 2017.
The two orthogonal longitudinal sections here in the GUI are in the end derived from the ship hull shape, which as a rule will be a wireframe representation (cross sections, as defined in Hulldef). Other sections can theoretically not be created with guaranteed correctness, on basis of such a wireframe model, actually a solid model is required for this task. In order to create these kind of sketches, PIAS contains extensive algorithms which anticipates on quite some special situations. The result is that only by rare exceptions the longitudinal sections are not properly drawn. In such an occasion there is no reason for suspicion, for it is only a visual affair, the computation results are not affected.

Right at the bottom of the GUI window a status line is displayed, subdivided in five boxes:

  • The first box contains a short explanation of the function of the menu bar, when the mouse pointer stands on it.
  • The second box displays the selection mode (see Left mouse button and modus).
  • The third box dynamically displays the coordinate (L, B and H) of the pointer position in the orthogonal views.
  • The fourth box dynamically displays the name of the physical or reference plane that is closest to the mouse pointer.
  • The fifth box dynamically displays the name of the compartment and/or subcompartment where the mouse pointer stands above.

Furthermore, in the upper bar the GUI has a number of functions that have been subdivided in subfunctions. Those functions can either be carried out directly, or can be ‘hanged’ to the mouse button, which mechanism is discussed in How long stays a function assigned to a mouse button?. The function bars under [Compart], [Refplane] en [Plane] are subdivided by a horizontal dividing line. The functions above that line are only related to the tree view window in question, the functions under the line are generally applicable.

General operations and modus

Mouse buttons

The mouse buttons are used as follows:

  • The left button can be used for two things, namely a) the selection of compartments, physical planes and reference planes, or b) performing functions with it.
  • Pressing the right button and subsequently moving the mouse is for display. In the three orthogonal views that is choosing the intersection locations (unless one has opted for pan at the tool bar at the left side of that window). And in the 3D view that is default rotation (unless one has opted for another display function at the tool bar at the left side of that window, for example, pan or clip).
  • Shortly clicking the right button in the 3D view brings up a specific menu with which colors, translucency and lighting can be set, or a screen print or 3D model (in VRML-format) can be stored in a file, see Operation in the 3D subwindows for a more detailed explanation of the possibilities in the 3D view.
  • Keep on pressing the middle button and then moving the mouse is panning.
  • The mouse wheel is zooming, as well in the 3D view as in the orthogonal views.

Furthermore, one can carry out the (for MS Windows) usual actions in the tree view windows such as dragging of compartments, subcompartments, physical planes and reference planes. With function button <F2> one can change a name into such a tree view window.

Left mouse button and modus

The left mouse button is meant default for indicating or selecting of ship's items — compartments, physical planes and reference planes — but it is also possible to assign a function to it, which is carried out later when such ship's item has been indicated. When such a function (for example function [Plane], subfunction [Edit], with which data of physical planes can be modified) has been activated, it is shown in the second block of the bottom status row. When the box displays ‘Select’, this means that the left mouse button is in the default position: select. What is exactly selected depends on the selection modus, which can have four positions:

This is the most extensive position; herewith the nearest item is selected, which may be a compartment, physical plane or reference plane. At a physical plane, the <Alt> key can be used, see the discussion at ‘planes’ below.
With which only compartments are selected (see note below).
With ‘Planes’ only physical planes are selected. It may happen that physical planes are very close to each other and visually indistinguishable, in which case the left mouse button in combination with <Alt> can be used. Then a box will pop up with the (maximally four) nearest planes, from which one can be chosen.
Reference planes
Only reference planes are selected herewith.
In which the selection is restricted to piping systems. If subsequently a pipe line is double-clicked, that pipe is opened in the piping definition GUI, which is discussed in Pipe lines and piping systems. The piping is deliberately not included in the ‘Auto’ setting (from a few lines above); because the pipes cross everything else, they should be explicitly selected.
Instead of selecting a compartment, it could occasionally be desirable to select a subcompartment. However, in general that would be somewhat difficult, because in the 2D views compartments are shown instead of subcompartments. For this reason, in due time, the [view] option (see View) will be extended with the ‘subcompartment’ setting as an alternative to the current ‘compartment’ setting. The two will be mutually exclusive, so either the compartments are shown, or the subcompartments. And the object of selection at this point in the manual follows this view- setting. This mechanism may, however, induce a side effect: a single specific action will imply more or less a certain selection, for example if in the compartment tree a compartment is selected, then it might be obvious to select a compartment as well in the 2D views, mutatis mutandis for a subcompartment. However, such ‘logic’ might be in conflict with the present view compartment/subcompartment setting, and for that reason in such a case the program will switch automatically to the view setting which matches this action ‘logically’.

How long stays a function assigned to a mouse button?

This is no principal matter, it is a choice, Layout can be made thus that it is assigned once, or permanently, or otherwise, in principle this does not matter. But users may have different wishes, and that's why that can be set, in Layout project settings and function colors is explained how this works. There are three options:

Then the mouse function always remains attached to the left button (until one chooses another).
Cancel structural commands after use
With this setting, commands that cause an important modification in the arrangement structure (such as adding and removing of planes) are removed as mouse function after single use. This prevents that planes or compartments are unwantedly added or removed in the event of fast clicking.
Cancel all commands after use.
Herewith any function is removed as mouse function after single use, and therefore one has to assign any command to the mouse button repeatedly. Apart from that, at all times the user can detach the function from the mouse button with the key <F12>

Operation in the 3D subwindows

Three-dimensional sub window.

At the left side in each three-dimensional subwindow is a number of buttons that are specifically related to that subwindow. When the right mouse button is pressed permanently, the [rotate] or [pan] function is carried out, depending on what has been set. By pressing the right mouse button shortly, a popup menu appears with which one can carry out non-modelling operations witih the ship subdivision model. These are available in four groups, are being discussed in much more extent in Rendered views, but summarized their functions are:

  • [View]: herewith one can carry out the same operations as with the buttons at the left side, which have been discussed above. Besides, there is still the function [(in)visible], with which one can set which individual parts of a ship are (in)visible.
  • [Edit]: with this function the position and intensity of external light sources can be set. One can also change the colors, reflection characteristics and transparency of objects or background
  • [File]: with this function one can save the present picture to file (in VRML or BMP format), print with the printer or copy to clipboard. This function only regards the picture, it has nothing to do with the file saving of Layout.
  • [Setup] contains two obsolete configuration options.
With emphasis a tools is recomended which can assist to determine from which side an object is viewed. This is the orientation box, from which purpose and operation is discussed in View.

Shortcut keys

In order to speed up work it can be practical to use shortcut keys. The following are available for this:

  • In the tree view windows the <Insert> and <Delete> keys for resp. adding or removing of a (sub)compartment, reference plane or physical plane. After <Delete> at (sub)compartment, the (sub)compartment can be sticked in again (possibly at another position), so this button rather has the meaning of ‘cutting’ than of ‘removing’.
  • In the tree view windows the <Home>, <End>, <Page Up> and <Page Down> keys in order to jump resp. to the top of the list, to its bottom, to the upper line of the window and to the lower line.
  • In the tree view windows the <F2> to alter the name.
  • <F12> to detach a function from left mouse button (see How long stays a function assigned to a mouse button?).
  • As side-effect of Windows, any function in the upper bar can be called with the key combination <Alt><function letter>.
  • In due course, other <F> function keys will be assigned to the functions that are mostly used.

The shape of a plane (the green dots)

Defining the shape of a physical plane with the green dots.

An important function of Layout is the addition of planes. These not necessarily need to extend over the entire ship, but can also be in a part of it. This shape is entered by means of the plane contour, which is controlled by the ‘green dots’, as they are called in the manual. Its background is discussed here in more detail. This all takes place in a popup window as displayed in the above figure, where you can see that the shape of the plane has been recorded with only three green dots.

What is shown there is the cross-section of the plane, with the chosen contour indicated in purple (at least, that is the default color, the user himself can choose another color at the Setup menu, see also Layout project settings and function colors). The contour can stop at the intersection with other planes, so one does not enter coordinates here, one chooses to which other, already present, planes the contour extends. A topological definition has been obtained in that manner, from which results, for example, that when the position of another plane changes, this contour also changes. The main idea here is that a user can enter the desired contour by indicating points of these other planes, through which that contour has to go. By the way, one need not indicate all points, also in the event of only a few points the program itself chooses the most evident contour, see the example from the figure where the contour has been recorded with only four indicated points (the green dots). More precisely, indicating occurs as follows:

  • When one stands with the mouse pointer on or near a point, then the dot can be switched on or off with the left mouse button as ‘wanted’ (green).
  • When one stands with the mouse pointer near a connecting line between two points, then that piece of line can be switched on or off with the left mouse button as ‘wanted’ (green).
  • When one stands with the mouse pointer on or near a point, then the dot can be switched on or off with the right mouse button as ‘unwanted’ (red).
  • Idem for unwanted connecting lines (red).

In the event of a new plane, one can directly start to switch on/off. In the event of an already existing plane, there is protection against accidental modification, which is called the ‘contour modus’. That contour modus is initially ‘off’ (that is also reported in the status line at the bottom of the window) so nothing can be changed. With menu option [Setup], suboptie [Contourmodus] one can switch this on. Further options from the upper bar menu are:

  • Undo, undo the changes, and put the original contour back.
  • Abort, abort this action and stop with this contour changing window.
  • Continue, stop with this contour changing window and process the change in the ship's model. When one presses on the right upper cross of the window then it is clear that the user wants to stop with this window, but it is not clear whether the changes have to be included in the ship's model. When there actually are changes, that question is asked again.

GUI functions

The purpose and the operation of various functions to be chosen from the upper bar are discussed below. There are two types of functions, namely those with a direct effect (since nothing else has to be indicated) and those that are assigned to the left mouse button, because something has to be indicated later on to which this function is applied. At any function below is mentioned which type it is.


Clear action

The action that is attached to the left mouse button at that moment is removed from it with this. Type of function: direct.

Selection mode

Herewith one can choose one of the four selection modi, as explained in Left mouse button and modus.


Herewith one calls up the menu with program settings, which is discussed in more detail in Layout project settings and function colors.


Herewith one calls up the menu with which the colors of the various ship's components can be set. This is a limited version of a more general menu for setting ship's components, which is discussed in more detail in Names and color per part category.


First of all, one can indicate here which things you would like to be presented in the GUI. You may select from:

  • Planes, these are the physical planes and. When these have been made invisible, then the physical planes tree view window also disappears, because this has become useless. Likewise, functions related to physical planes cannot be activated then. Also a third choice exists, between on and off, which is separating planes on. With this choice only those parts of the physical planes will be drawn which constitute real separations between compartments (or, to be more precise, between subcompartments of type ‘space generated between planes’). This gives a more realistic picture, however, please bear in mind that this is a drawing switch only; in the underlying model the physical planes still extend, also if the separate parts of the same compartment. In ‘outside’ output, such as to the subdivision plan, always the separating planes on method is used — regardless the switch setting here in the GUI — because this is most genuine.
  • Reference planes, the reference planes. When these have been made invisible, then the reference planes tree view window also disappears, and functions related to reference planes cannot be activated.
  • Hull, the hull lines (or planes), only applies to the 3D window.
  • Compartments, applies to the 2D windows as well as the 3D window.
  • Piping, all pipe lines, from which the definition method is discussed in Pipe lines and piping systems, applies to the 2D as well as the 3D windows.
  • Compartment Colors, where the system of compartment coloring can be chosen; the options are:
    • Uniform, where all compartments get the same color. There may be a difference in color after specific program actions, such as in the event of a just cut or generated compartment (these colors can be set at Layout project settings and function colors).
    • Individual, where any compartment gets its own coulor (automatically determined by the program).
    • Per weight group, where a compartment is colored in conformity with the color that applies for the weight group assigned to the compartment. These colors can be set as discussed in Define weight groups.
    • Compartment Overlap, here the program conducts an overlap test between compartments, where one can deduce from the color whether the compartments have been defined uniquely and non-overlapping, as it should be:
      • Green: good.
      • Background color: this piece of a ship is not covered by a compartment, the compartment definition is therefore not complete.
      • Red: two or more compartments overlap here.


Here the menu options above the horizontal dividing line also apply to the tree view, and those under the line to the graphical windows. For the time being, the first group consists of only one function:


With this command the compartments in the tree view are sorted. This can be done on four criteria, namely on name, position, type and abbreviation. The sorting can be undone again with Undo. Type of function: direct.


With this function one draws a plane interactively. The operation is as follows:

  • Choose this function.
  • Go to the orthogonal view where the plane must be perpendicular to.
  • Go to an endpoint of the plane and press the left mouse button. There will appear a cross-hair.
  • Go to the other endpoint, and press the left mouse button again. There will appear a second cross-hair, with a connecting line.
  • The bulkhead will be generated perpendicular to the view, through that line.
  • In general, the line will not fall in an orthogonal plane accurately, whereas that was perhaps intended. That's why the program offers the opportunity of fine-tuning. There one can choose from: - Consider the bulkhead to be orthogonal (through the mean location of the line)
    • Idem, but with the possibility to adjust the location exactly, by typing a size.
    • As drawn (possibly angled).
  • Afterwards appears a pop-up window with the ‘green dots’ (see The shape of a plane (the green dots)) so positioned that an as reasonable as possible part of the line is covered by the bulkhead. Is this not satisfactory, then one can still adjust the level of extension of the bulkhead by means of the yellow dots. Type of function: left mouse button, because the location and direction of the plane have to be entered later on by means of drawing.


With this function one adds a plane that extends over the entire ship (from stern to bow, or from bottom to top) at the beginning. Afterwards can be indicated through the ‘green dots’ (see The shape of a plane (the green dots)) that the plane extends over a more limited part. Type of function: direct.


With this function one adds a plane in one indicated compartment. Afterwards, one can still indicate through the ‘green dots’ that the plane extends over a larger part. Type of function: left mouse button, because the compartment where the plane will appear has to be indicated later on.


A plane is removed with this function. After the removal of the plane, excess subcompartments may remain. These are removed according to the order of the (sub)compartment list, i.e. when several subcompartments of the type ‘space generated between planes’ refer to the same space, then the first ones are removed and the last of all remains. Type of function: left mouse button, because the plane to be removed has to be indicated later on.

Plane A can be a boundary in another plane, plane B. If plane A is removed then B will become larger as a result, because it will lose its boundary. This change in B may in turn introduce other changes in other planes, for which B was the boundary. Etc. etc., that can result in a chain reaction of changes. It may be that the result of changes is unexpected, or even undesired. In that case one should manually adapt the changed layout to the human insights.


The features of a physical plane can be changed with this function, see Popup menu for geometry of planes and points for details. Type of function: left mouse button, because the plane to be changed still has to be indicated.


With this function the contour (and therefore the shape) of a plane is changed. Type of function: left mouse button, because the plane to be change still has to be indicated. After having indicated the plane, a window pops up with the shape of the plane, where one can change the contour by means of the ‘green dots’ (see The shape of a plane (the green dots)).

If a planeis modified in such a way that parts are discarded, then the remark given just above at ‘Remove’ is also applicable here.


Herewith one can copy a plane. Type of function: left mouse button, because the plane to be copied still has to be indicated. The operation is:

  • Choose this function.
  • Point at the plane to be copied.
  • A pop-up window of the copied plane appears, already filled with the copied parameters. Change the name and position in that window (NB the orientation (position of the plane) cannot be changed, so one is not able to copy a transverse bulkhead to a deck).
  • Press the OK button, and the copied plane is added to the model.


These menu options have been subdivided in two groups, those above the horizontal dividing line regard the compartments tree view, those under the line are applicable in the graphical windows. We start with the first group:

Compartments Tree view

The compartment tree contains the compartments in the main branches, and under each compartment the subcompartments. With this command one can collapse and expand all branches at once. Apart from that, one can of course also collapse or expand an individual branch with the + for each compartment. Type of function: direct.


With this command the compartments are sorted in the tree view. This is possible on two criteria, namely on compartment name, and on location (where the compartments are sorted in length, breadth and height direction). The sorting can be undone with Undo. Type of function: direct.


Herewith a new, and empty, compartment is added in the tree, just below the compartment that was selected at that moment. In order to control at which location in the tree the compartment is exectly added, this command can only be given from the compartment tree window. Type of function: direct.


Herewith a new subcompartment is added under the compartment that was selected at that moment. The subcompartment only has a default shape and type, which has no meaning, nor any connection with something else. Type of function: direct.


Cut a compartment or subcompartment. The type of function depends on the sub window from where the function was activated; in a compartment treeview the function has direct working, from a 2D window the function is assigned to the mouse button. By the way, the <Delete> key does exactly the same.


Paste a compartment or subcompartment. That object is then placed after the then selected compartment or subcompartment. Type of function: direct.


Undoes the cutting of a (sub)compartment. Type of function: direct.

Remove eMpty

Removes all empty compartments (those compartments that have no subcompartments). This function can be practically used after a number of compartments no longer has subcompartments after dragging (graphically, or in the compartment tree). Those can easily be removed in this manner. Type of function: direct.


This is the first function of the list that is applicable in the graphical windows, and therefore not in the tree view. With this function one enters the detail window of a compartment, which is discussed in more detail in Compartment definition window. Type of function: assign to left mouse button.


Compartments and spaces as they are generated between planes have been linked. This link is as much as possible maintained, so when, for example, a new plane is added then additional compartments will be generated for that, the name and other features of which can be adjusted later on by the user. But if one has removed a compartment with, for example, [Cut] or the <Delete> key the space in question still exists, but it is no longer linked to a compartment. With this function, [Assign], a new compartment is added that is linked to the space. That new compartment still has default parameters, such as name and specific gravity, but these can simply be changed later on. Type of function: assign to left mouse button, because the space to which a new compartment must be assigned has to be indicated afterwards in one of the orthogonal cross-sections.


When a plane is added that runs through a subcompartment, that subcompartment is divided in two parts, while the features of the original subcompartment are assigned to one space, and a new subcompartment is made for the second space, the features of which have to be filled in in more detail (except for its shape, of course). This choice is arbitrary, and it might very well be the intention of the designer that the original subcompartment is assigned to that second space. When this is the case, one can turn this assignment with this function, [Swap], again (and also turn it back again when one is mistaken). Type of function: left mouse button, since the space to be swapped still has to be indicated.


Subcompartments are hanging under compartments, and its organisation is completely up to the user. Particularly after the event of adding new planes, new spaces are made which are each assigned to a new subcompartment that is hanging under a new compartment. When one wants to change that subdivision, one can do that by means of dragging in the compartment tree view window. With this function, [Recombine], one can do the same in one of the 2D windows. So one can point to a subcompartment, press the mouse button, and drag to another subcompartment. When one releases the mouse button, and after confirmation, the subcompartment no longer resides under the original compartment, but under the newly indicated compartment instead. Empty compartments (i.e. compartments that have no subcompartments) can be arise in this manner, which is no problem in itself, but for overview purposes it may be practical to remove these, either manually, or with the [Remove eMpty] function, see Remove eMpty.


Here the menu options above the horizontal dividing line also apply to the tree view, and those under the line to the graphical windows. For the time being, the first group consists of only one function:



A new reference plane is added herewith. An input screen appears where one can put in the various data, see Popup menu for geometry of planes and points for more details. Type of function: direct.


With this function a reference plane is removed. Type of function: left mouse button, because the reference plane to be removed still has to be indicated.


The characteristics of a reference plane can be changed with this function, see Popup menu for geometry of planes and points for the details. Type of function: left mouse button, because the reference plane to be changed still has to be indicated.

Compartment list, calculation of tank tables etc.

A list of compartments turns up here, with twelve columns — for which the order can be set by the user, see Input window} — namely:

  • Selected: whether the compartment has been selected for further actions, like calculations or output.
  • Name: the unique name of the compartment. Although fifty characters have been reserved for the names in Layout, the input here is for the time being limited to 28, for the reason that this 28 still is the maximum in subsequent modules, such as Compart and Loading. When also those modules have been upgraded to the higher maximum, the input limitation will be removed.
  • Second name, please refer for its usage to Second name and abbreviation.
  • Abbreviation, of maximally eight characters.
  • Weight group: to which weight group the volume of the compartment belongs. The purpose of weight groups and its definition is discussed in Define weight groups.
  • The permeabilities (μ) of the compartment as tank, and as applied for damage stability calculations. Exactly the same as can be given in the compartment definition menu, see Uniform permeabilities and `space type'.
  • The design density (ρ), as discussed in Design density.
  • With computation scripts and output scripts should be used for the calculation and output of tank (sounding) tables, see Calculate and print tank tables).
  • Calculated, which indicates per compartment whether the tank tables have already been calculated. Besides ‘yes’ and ‘no’ it might also be indicated that the table is available, albeit outdated. That will be the case if the compartment shapes has been modified after the most recent tank table calculation. With <Enter> a sheet is opened with all calculated values. It is possible to modify these values, but please keep in mind that those will be lost on re-computation. The table can also be modificied by the addition or deletion of lines, however, no more than the original amount of lines will be accepted. If tables for multiple trims are computed the menu bar functions [Nexttable] and [Prevtable] can be used to traverse these tables.
  • Convertible. A compartment can be ‘convertible’, see Convertible for an explanation of this concept. In this column one can enter the ‘convertibility’ of all subcompartments of the compartment.

The upper bar contains some specific functions:

  • [Manage], with the following sub-options:
    • [Copy] and [Paste] will speak for itself. One might wonder why these options are not included in the general copy/paste under [Edit], as common in PIAS. The reason is that over here also a [Paste Link] option exists, which is not facilitated in the regular [Edit]. In this respect Layout is an exception. Perhaps unnecessarily: the [Edit] options — as discussed in Copy, paste etc. — only exert on the visual cell values, which can e.g. be exhanged with a spreadsheet, while the copy/paste here under [Manage] concern all compartment data, including all underlying subcompartments.
    • [Paste Link], see the explanation at Subcompartment functions.
    • [Move], which can be used to move a compartiment up or down in the compartment list.
    • [Sort], herewith the compartments can be sorted according to column (i.e. in the order of the data of the column on which the text cursor is standing), to position and to time of definition. The selection can be undone again with [Undo].
  • [tAnk tAbles], with which one can calculate and print tank tables, see Calculate and print tank tables.
  • A row of icons, which may be used to invoke some of the other upper bar manu functions. These icons are presumed to be self-explanatory, although additional assistance is given by hovering over the picture. When one has entered into a tank table, by means of <Enter> in the rightmost column, these icons are also present although they will obviously not be functioning here.

With <Enter> in any other column one enters the compartment definition screen, which will be discussed later on.

Compartment definition window

Compartment definition window.

Design of the compartment definition window

The compartment definition window consists of the following items:

  • Top left a list of compartment characteristics, such as name or sounding pipe data. These are explained in detail in Compartment data.
  • Bottom left a 3D view of the compartment. In this window one can call up a number of functions with the right mouse button as they have been discussed at Operation in the 3D subwindows. By the way, mouse wheel is zooming in-out.
  • Left of centre an drop-down list of compartments, from which one can choose another compartment (one can also type a name here, but nothing happens then). Choosing the previous and next compartment can also be done with the two buttons at the right of this list.
  • At the right three subscreens related to subcompartments, and which have the same purpose as the three subwindows discussed above.
  • At the bottom a status row, with explanations and/or sizes related to the cell where the text cursor is standing on.

Changing between compartments and subcompartments can be done through indication with the mouse pointer, but also with the <Tab> key. Subsequently, there is still a number of functions to be called up in the upper bar, which are discussed below. The upper bar also consists of the + and - functions, with which one can jump to the next or previous compartment (when the text cursor is standing on the left window) or subcompartment (when the textcursor is standing on the right window). These functions have been included so one can quickly go through the (sub)compartments with <Alt><+> and <Alt><->.

Reference planes can be used for all coordinates of compartments and subcompartments, so not only for the compartment boundaries but for example also for openings or the sounding pipe. A reference plan ecan be selected by pressing <Enter> in that particular cell. This activates a popup window that is further discussed in Popup menu for geometry of planes and points.

Copy/paste functions, as discussed in Copy, paste etc., are not implemented here. These input windows have such a variable structure that this will hardly fit.

Types of subcompartments ‘with coordinates’

A subcompartment of the type ‘with coordinates’ is always defined with an aft and a forward boundary, and in each of it a number of points which represent the horizontal and vertical subcompartment boundary. In general, this is a flexible definition, enabling considerable freedom of shape, but since the major part of the subcompartments does not need this flexibility, a number of subtypes has been defined in order to increase userfriendliness:

Simple block
A ‘simple block’ is a limited interpretation of the general subcompartment definition, namely with straight horizontal and vertical boundaries. This type can be recorded with six numbers (aft, fore, inside, outside, upper and bottom).
Four longitudinal ribs
This is a slightly extended interpretation, where the number of ribs N=4, but where the longitudinal boundaries are not limited to purely horizontal or vertical. This is the representation as it was also used in the predecessor of Layout, Compart.
Other than four longitudinal ribs
This type is even more extensive, here N≠4, and therefore three-sided, five-sided or multilateral subcompartments can be defined, where the corner sequence should be counterclockwise. An example of a subcompartment definition window for a five-sided compartment is presented below:
As coordinate also ∞ can be entered, in which case the outer hull is taken as subcompartment boundary. That is quite handy, however, please realize that such an ∞ should be used for (the corresponding coordinate of) both aft boundary and forward boundary. The reason is that interpolation between finite and infinite is undefined. With such invalid input the program prints the warning ‘corresponding coordinates of aft and forward boundary should both be finite or infinite’, and leaves it to the user to correct the input coordinates.

Compartment functions

Adding and removing will be obvious; With [Insert] a compartment is added that is included in the list of compartments before the present compartment, and with [New] after it. [Copy] copies the compartment data, including all subcompartments to an internal clipboard. With [Paste] the compartment data, including all subcompartments, are copied from that internal clipboard to the present compartment. All existing compartment data (including subcompartments) are transcribed thereby. The difference between [Paste] and [Paste Link] is explained in the following paragraph.

Subcompartment functions

The functions [Insert] through [Remove] are entirely analogous to those discussed at the compartments, we refer to the previous paragraph. The [Paste Link] is related to references of subcompartments, as explained in Links to subcompartments. With [Paste] the subcompartment data are copied to the present compartment, with [Paste Link] a reference is made from this subcompartment to the shape of the copied subcompartment.

Coordinates functions

These functions are related to a subcompartment of the type ‘with coordinates’. With subtype ‘other than four longitudinal ribs’, as discussed in Types of subcompartments ‘with coordinates’, there should be a facility to add or remove rows, in order to change the number of ribs. The first three functions ([Insertrow], [Newrow] and [removerow]) are meant for that. Because most subcompartments are prismatic (i.e. that the aft and front boundaries have the same shape), for practical purposes there is a [Copyaft] function, which will copy all coordinates from the aft boundary to the forward boundary. This function is also relevant for type ‘four longitudinal ribs’

View functions

Without a special setting, all subcompartments of a compartment are drawn interchangeably in the left bottom subwindow, irrespective whether they are positive or negative. Mutual connections of two (positive) compartments are drawn then, although one could argue that they do not exist in a physical sense, and could therefore be omitted. With the [visually composed] function active subcompartments are actually composed graphically, so that they render a more realistic image.

At this ‘visually composing’ of subcompartments, these are neatly cut off when they overlap. The shape of negative subcompartments is also deducted from those of the positive ones. This offers a good insight, but do remember that the calculation is based on the ‘bare’ subcompartment shape, so overlappings are calculated double, and a too large negative subcompartment may result in a negative compartment volume.

When the [Surfacemodel] function has been activeated, the (sub)compartments are not drawn as wire model (on frames), but as surface model. All this on the condition that either a surface model of the hull is available (TRI file, see Calculation methods and output preferences) or the (sub)compartment is not at all cut through the hull. If one visualizes a (sub)compartment with a surface in this manner, one can also switch on the [Transparent] function, with which the surfaces become partially transparent, so that also the sounding pipe remains visible. That renders such images:

Semi-transparent compartment with sounding pipe.

Compartment data


The (unique) name of the compartment.


Indicates whether this compartment has been selected for further actions, such as calculations and output.

Second name and abbreviation

These are supportive names that can be included in some output for cosmetic or explanational purposes. For example, the second name at tank tables, and the abbreviation, of maximally eight digits, at the tank plan (since too long names will soon mix up there through several tanks). One can also choose to have this second name generated permanently, please refer for that to the settings as discussed in Layout project settings and function colors.


Here one can indicate whether a subcompartment at the implementation of option 6.1 (see Generate physical planes from the totality of convertible subcompartments) must be included in the automatic conversion of the type ‘with coordinates’ to ‘space generated between planes’. Here are four possibilities:

Automatically at conversion
At the conversion is firstly considered whether the compartment overlaps another one (and complies with other requirements, such as the completene flatness of the boundary planes). If so, it will not be converted; if not, it will be converted.
Will be obvious
Is convertible
Define per subcompartment
Which is used when it cannot be recorded for the compartment as a whole whether it must be converted, but this has to be defined at the more detailed level of subcompartments, as described in Convertible.

Design density

Here the density (specific weight, in ton/m3) of the liquid for which this tank is intended can be given. This value is used as default in loading conditions. When such a value is not known or desired, one may also opt for ‘not specified’, then there is no default.

Weight group

Indicates to which weight group the volume of the compartment belongs. The purpose of weight groups and its defining has been discussed in Define weight groups.

Sounding pipe

Two sounding pipes per compartment can be defined. Each of them takes up one row, where can be defined:

  • The name of the pipe. This is initially a default name, depending on the selected output language at the moment the compartment is created, but these names can be changed manually.
  • With ‘selected/deselected’ in the right column one indicates whether this pipe has been selected for output, such as drawings and tank sounding tables. Besides being selected a pipe can also belong to a category (‘A’ to ‘J’), which enables the output script to identify the desired sounding pipes in the sounding tables (see Output scripts for details).
  • With [enter] a window pops up in which one can define the coordinates of the pipe, which can also be referred (via <Enter>) to the reference planes, a feature that might be useful in the event of future design modifications. The maximum number of coordinates is fifty, so that also curved pipes can be properly modelled. Furthermore, for verification purposes in the status line, right-under in the window, the total pipe length is represented. Finally, this window als has a [Selected] function which does exactly the same as the ‘selected/deselected’ of the previous line. As the rule a pipe will consist of two or more points, however, it is also possible to define a “pipe” with only a single point. Its effect will be discussed in Output scripts.

Special points / openings

Characteristics can be defined here of specific items that belong to the compartment. There are four predefined types of such items:

Open opening
This is an open opening to the outside, which is connected with the compartment, for example, an unprotected vent.
Weathertight opening
An opening to the outside which is connected with this compartment and protected such that it can be considered to be weathertight. Some authorities consider a vent cap to be sufficient protection to that end, others not.
Watertight ‘opening’
Obviously, this type has no effect. it is included for convenience, for example to be able to toggle an opening ‘off’, or to indicate that one has not forgotten or ignored a closable opening, but that it really securely closed.
Emergency exit
See Types of parameters, Emergency exits to be included.
Hopper edge or overflow
Are solely intended for open hopper compartments, from which cargo can pour out. Their details are discussed in Specify additional hopper properties.
Alarm sensor
In order to be able to process its effect in tank tables and maximum tank filling.
Pressure gauge
Its location is important for the calculation of pressure tables (i.e. the tables that indicate which tank filling belongs to a specific sensor pressure), and in order to be able to determine the corresponding volume at loading conditions and/or loading software at a known sensor pressure.

At [enter] a window pops up in which can be defined:

  • Whether the point has been selected is defined in the last column. Only selected points result in an action. When a point has not been selected, it is just as if it does not exist at all. So selection is intended to ‘throw away’ something as it were, while it can be restored later on. Some points can also be selected from a certain category, that serves the same purpose as with sounding pipes, as discussed just earlier.
  • The name.
  • Length, breadth and height coordinates of the special point.
  • The type of point, according to the definition list just above.
  • The piping network to which a point belongs.

Apart from that, ventilation openings are traditionally defined in PIAS in a separate list, managed by the module Hulldef. This list will remain because it also contains other types of points, such as those of the margin line. In order to prevent inconsistencies Layout completes this list again and again with (selected) openings of compartiments, but marks them such that they cannot be modified or removed in Hulldef. If one should wish to manage all openings of the vessel in a single overview list, the Layout option as discussed in List of openings and other special points is recommended.

Compartment is an open hopper

PIAS can compute the stability of hopper dredgers, which is discussed in Stability of open hopper vessels. Anyway, it must be specified which compartment(s) should be considered as open hopper for this purpose. That can be done by switching this cell to ‘yes’

Oil outflow parameters

  • Type of tank for oil outflow calculations: for the benefit of probabilistic outflow calculations (with Outflow) it must be known wheter a specific compartment is a fuel oil tank or a cargo oil tank (at least, within the meaning of the regulations involved). That can be defined here.
  • Tank adjacent to bottom: for that same outflow calculation it may be important whether a tank borders at the bottom on the plane, or on a non-oil tank. That can be defined here.
  • Overpressure of inert gas system: cargo oil tanks can be provided with inert gas systems. If such is the case, then it is of importance for the outflow calculations to define its overpressure here (in kiloPascal).

Uniform subcompartment sides

One action can record the side for all subcompartments here, see Side for the options.

Uniform permeabilities and `space type'

Permeabilities or space types can be defined here for all subcompartments in one action. See Permeabilities for further merits.

Subcompartment data


The name of the subcompartment, which has to be unique within the compartment.


A compartment has a permeability, which is commonly depicted by a μ. Here in PIAS there are two, namely the permeability where is calculated at the tank volume calculation, and the one where is calculated at the damage calculation. Physically, such a distinction can of course not be maintained, but naval architectural practice has shown that for tank volume calculations often a permeability of 0.98 to 0.995 is used, while the rules for damage calculations often prescribe a value of 0.95. The calculation of the actual grain heeling moments, as determined by module Grainmom, uses the ‘permeability as tank’. The permeability has been defined as the total volume, taking into account construction parts divided by the total volume without taking into account construction parts, and therefore as a rule has a value between 0 and 1.

Some rules, in particular the probabilistic damage stability SOLAS 2009, use a permeability that varies with the draft, and with the type of space. So one can choose at the option ‘type of space prob.damage stab. SOLAS2009’ from the types of spaces of SOLAS. Such ‘type of space’ does not make a definition of the ‘damage permeability’ superfluous, because the first is applicable to probabilistic damage stability, and the latter to deterministic.

Apart from that, it will only occur seldomly that permeabilities or types of spaces differ among subcompartments of the same compartment. When they are all equal, it is more practical to define these data at the compartment, since the permeabilities for all subcompartments are entered then by one action.

In the old Compart module such a ‘space type’ could only be assigned to an entire compartment. In this respect Layout is more sophisticated, because here each subcompartment can be assigned a different ‘space type’. However, it should be recognized that the damage stability modules of PIAS do not yet directly use the Layout capabilities, so converting through the Compart format is still required (please also refer to Compartment files. Therefore, this Layout sophistication is not yet effective, so one might just as well give the ‘space type’ for the whole compartment. When Compart has becomde fully redundant, this limitation will evaporate.

Shape type

The type of subcompartment. There are three types, as introduced in Definitions, namely ‘with coordinates’, ‘space generated between planes’ and ‘external PIAS hullform’.


Positive or negative, resp. whether this subcompartment has to be added to the subcompartment or whether it has to be deducted from it. This sign can not be filled in at subcompartments of the type ‘space generated between planes’, since they are always positive.


One can indicate here whether a subcompartment at the implementation of option 7.1 (see Generate physical planes from the totality of convertible subcompartments) must be included in the automatic conversion of the type ‘with coordinates’ to ‘space generated between planes’. This row only appears when one has entered at the compartiment at the ‘convertibility’ that this can be set per subcompartment (see Convertible).


An asymmetrical subcompartment that is only at SB.
An asymmetrical subcompartment that is only at PS.
A symmetrical subcompartment of which only the SB half has been defined, which is reflected to PS.
According to coordinates
Where the subcompartment is simply recorded by its coordinates, without specific symmetry assumptions. According to PIAS convention, the transverse coordinate is positive to SB, negative at PS.

Shape definition external subcompartments

File name and length, breadth and height shift, These are the parameters from the external PIAS hull form, a concept which is introduced in Definitions, where the file name from the PIAS shape definition (as recorded with Hulldef or Fairway) and the shift of the origin of that definition to its position of this subcompartment are defined respectively. The filename can, by using the &-symbol, also be specified as being located in the same folder as the hull form file. Indeed, this is encouraged, reference is made to Hullforms for some more detail.

Shape complexity

At a subcompartment of the type ‘with coordinates’ one can define here whether the subcompartment is a simple block, that can be recorded with six digits, or has a slightly more complex shape, for which more digits are required. One can choose here from the three types mentioned at Types of subcompartments ‘with coordinates’.

When a subcompartment shape is of the type ‘space generated between planes’ then the indication “cannot be displayed in coordinates” can occur. That does not mean that the shape is wrong or useless. Such a subcompartment shape is entirely acceptable, but it only cannot be displayed with longitudinal ribs that run from aft to front. It would be possible to further split up the shape so that displayable shapes are generated, but that increases the number of subcompartments, so it was opted for not to do that.

Subcompartment coordinates

The final part of the subcompartment definition window consists of the coordinates, so the aft boundary, fore boundary and the other breadth and height boundaries. Where it is not evident whether it concerns a breadth of height boundary, it is indiocated in text in the bottom bar, see the picture below. The coordinates are only shown at the types ‘with coordinates’ and ‘space generated between planes’. At the last type they are only for information purposes, and they can therefore not be changed (the borders are then after all entirely determined by the physical planes).

Indication, lower left, whether the cell contains a breadth or height boundary.

Calculate and print tank tables

The tank volume tables options are activated with the menu bar optie [tAnk tAbles]. It contains four suboptions that will be addressed below.

Setup: define computation scripts and output scripts

With a script the output of the tank tables is specified. Scripts come in two flavours, the computation scripts where arithmetical issues are specified, such as step size and trim range, and output scripts where quantities and units are specified. For the sake of flexibility for both types of scripts multiple versions can be specified.

Computation scripts

The computation script determines the way the tank tables are computed, by specifying:

  • The name of the script. Multiple scripts may be defined, and per compartment the appropriate one should be selected>, and this script name serves for identification purposes.
  • Which script is ‘default’. If a compartment does not refer to a specific script, this ‘default’ is used at the calculation.
  • The calculation step, which is the vertical step (in meters) on which the table is calculated.
  • The output step, which is the step on which the table is printed. If in a script table in the first column a distance-quantity is used (such as height, ullage or sounding) than the table is printed with this step size in meter. If an other quantity is used in the firstcolumn (such as volume) than the table is printed with a step size that roughly corresponds with the output step in meters as specified here. In order to prevent the combination of a large computation step and a small output step, in the end the maximum of the two is applied.
  • The trim, or trims. A single trim can be specified in this cell directly, for multiple trims a dedicated subscreen appears after pressing <Enter>.
  • Whether tables should be produced for all angles of inclination. If filled in with ‘yes’ then tables will be produced for all combinations of the trims as specified here in Layout, and the angles as given in Config (as is discussed in Angles of inclination for stability calculations). If the inclinations are modified inConfig then the possibly existing tank sounding tables are not declared invalid automatically. So, they should be explicitly removed with option ‘remove alle calculated tank tables’, please also consult Remove: remove alle calculated tank tables.

Output scripts

An output script specifies which parameters are to be included in a tank table and in which units. Those parameters are:

  • Height, which is the height of the level of the liquid related to the PIAS system of axes, see sketch below. When a tank table is computed with trim, large positive or negative ‘heights’ van occur, because the ‘heights’ are defined from baseline at Lpp/2. The first height is at a just empty tank, the last height at the tank just completely filled.
  • Ullage, this is, with a sounding pipe of at least two points, the ‘dry’ distance through that pipe between the last (=highest) point and the liquid level. As discussed in Sounding pipe, a “pipe” may consist of only one point. This is then the ullage reference point from which is measured downwards, and which is therefore intended to lie above or at the top of the tank. The ullage is then the perpendicular (i.e. taking into account trim and heel) distance between that point and the liquid level.
  • Sounding, which is the complement of ullage, i.e. the ‘wetted’ distance through the pipe between the first (=lowest) point and the liquid level. A “pipe” consisting of a single point defines the sounding reference point, from which is measured upwards, and which is intended to be somewhere at the bottom of the tank. The sounding is in this case also the perpendicular distance between that point and the liquid level.
  • Volume, weight, VCG, LCG and TCG will speak for themselves.
  • ITransverse and ILongitudinal are the transverse and longitudinal moments of inertia.
  • FSM's are the free surface moments.
  • Pressure, for which the corresponding compartment must be equipped with a pressure sensor, the position of which can be specified in the menu of Special points / openings. The pressure is, obviously, calculated perpendicular to the waterline (= liquid level in the tank).
Definition of `height' in a tank table.

Each output script has a name so for each compartment the script to be applied can be identified easily. Per script it can be specified which quantities should be printed, in which order and in which unit. Each script has an input screen the quantities and units. The first row of this screen will be the first column in the table, the second row corresponds the the second column etc., so you can specify freely the desired number of tank table columns. The last column of the script contains the label ‘category’, which is only applicable for the quantities sounding, ullage and pressure. This ‘category’ is a letter from A to J and its purpose is to identify the applicable sounding pipe or pressure gauge. For multiple pipes or sensors can be defined per compartment, and for each tank table it should be specified which of those to use. Pipes and sensors also possess such an A to J category, so serves as identification mechanism.

Calculate: compute the tank tables

With this option the tank volume tables of all selected compartmemnts are calculated, according to the specified computation scripts, and according to the setting ‘tables with everywhere the maximum free surface moment’ of Config and as discussed in Settings for compartments and tank sounding tables. With the tank tables also the computation time is saved, so a re-computation can be done rather efficiently, because only those tanks that have been modified since the last computation are actually re-computed. If an unconditional re-computation of all tanks is deemed neccessary, then all existing tables should be removed, this is discussed in Remove: remove alle calculated tank tables. By the way, with the switch ‘re-calculate tank tables automatically’here in Layout, see Layout project settings and function colors, the tables are being calculated whenever required, so with this switch set it will not be neccessary to calculate here explicitly.

Tank volume computations are, obviously, based on the shape of the tanks, but also on the location and shape of the hull frames (as defined in Hulldef). This implies that (even for tanks that do not intersect the hullform) the number of frames may have its effect on the tank computation result. For a discussion on the effect of the number of frames reference is made to Number of frames.

Print: print tank tables

Example of a tank table according to output script.

With this option tank tables will be printed, in a number of variants (from which three are included here as example in the figures):

  • According to the output script, which allows for a good control over layout and content of the tables. If sounding or ullage is included in this table, it may contain a remark that the sounding pipe is too short. This means that the tank can be filled to a higher level than the top of the pipe, and implies that at a reading at exactly the top of the pipe, the volume may have any value between the volume which corresponds exactly with that level, and the maximum volume. In order to have an indication of the maximum volume, that value is printed. However, an additional line may be printed which is valid for a level exactly through the top of the pipe (as well as an additional line with elucidation).
  • Litre tables, or sounding/litre tables, to put it more precisely. This table does not contain other data, so it is rather condensed.
  • Trim tables, where for a range of trims the volumes are depicted. Trim tables come in two fashions:
    • On basis of sounding and ullage, where at each line at the sounding (in meter) for each trim the corresponding volume can be read. If a sounding pipe contains more than one point, the corresponding ullage is also included.
    • On basis of pressure, where at each line at a certain pressure (in mm water) for each trim the volume can be read.
  • Correction tables, which represent the deviation in tank volume due to list and trim. These kind of tables are a bit outdated, for if the volumes are directly calculated at multiple trims (e.g. with the ‘trim tables’ option above) such corrections are not neccesary at all. Anyway, the modus operandi with the correction table is:
    • Find the tables of the intended tank (there are two tables for each tank).
    • Look up the first correction value in the trim table at the measured sounding/ullage and trim.
    • Look up the second correction value in the list table at the measured sounding/ullage and list.
    • Add those two correction values (which are in millimeters) to the sounding/ullage. This is the sounding/ullage that can be used to read out the tank volume at zero trim and list.
  • Summary, which produces a table summarizing maximum volumes and COG's etc.  of all (selected) compartments. Please bear in mind that maximums of volume and moments of inertia are really the maximum values that occur anywhere in the tank. They do not have to belong to the same filling level, e.g. with a U-tank the maximum volume is reached, obviously, with a completely filled tank, while the maximum moment of inertia will occur at partial filling, with the liquid level in the bottom part of the tank.
Example of a table of litres.
Example of a trim table.

Remove: remove alle calculated tank tables

With this option all calculated tank tables will be removed. Actually, there is no reason to do so, because the program keeps track of the tanks whose shape has changed since the last calculation, so the tank tables is known to have become obsolete and must be re-computed. Exceptions occurs if the switch ‘tables with everywhere the maximum free surface moment’ is toggled or the angles of inclination are modified in Config (and as discussed in Settings for compartments and tank sounding tables and Settings for compartments and tank sounding tables respectively). In those cases the existing tables have to be removed manually with this ‘remove’ option. And, if for whatever reason you wish to remove tank tables, this is also the option to use.

Areas: print table of outer surface areas

With this option the outer surface area of the (selected) compartments will be computed and printed, with the purpose to serve as approximation of the compartment's paint area. When applying this table one should realize that:

  • Construction parts in the compartments and on the outer walls are not defined in PIAS, so their areas are not included.
  • With compartments adjacent to the shell the computation is based on the envelopped frame lengths, so the accuracy is more or less proportinal to the number of frames within a compartment. Additionally, for these compartments the area computation will not be accurate if in an asymmetrical hull shape the frame locations — as far as falling within the compartment — of the PS hull are not the same as for the SB hull.

Pipe lines and piping systems

At this moment Layout is being extended with functions for pipeline modelling. When fully developped, PIAS can be equipped with the following functionality:

  • Integrated bulkhead & deck / compartment / pipe modelling and viewing.
  • Including the effects of pipes on damage stability.
  • Piping data exchange with engineering software.
  • Time-domain damage stability analysis.

The data structure and naming conventions of PIAS' piping is inspired on the ISO-15926 standard, which has an origing in the process industry. The primary entities are:

  • Equipment, which is a thing, not being a compartment, connected to a pipe line but not part of it. Such as an engine or a chiller. In the end, PIAS performs no actions with equipment, it is just defined in PIAS for the completeness of definition and drawings.
  • A piping system, which is an administrative collection of pipes of the same type, for example “ballast” or “HFO”. Such a system can optionally belong to a weight group — as also applied for compartments and weight items in PIAS, and as discussed in Define weight groups. A piping system can also be assigned a color, e.g. according the ISO 14726 standard.
  • A piping network, which is one closed system of connected pipes, which belongs to a piping system. A network is the core of the piping dada structure.
  • A piping segment, which is one branch of a piping network, and extends between two points without sub-branching inbetween.
  • A piping connection, which is a part located at the extremities of a piping segment. Such a connection comes in five types:
    • Joint, where multiple piping segments meet.
    • Opening, external (so, to the outside).
    • Terminator, which closes a dead-end segment.
    • Compartment, or, more precisely, a connection to a compartment at a certian location. So, a compartment may have multiple connections.
    • Equipment, or, more precisely, a connection to a piece of equipment at a certian location.
    For each connection also its position can be given, as well as the resistance coefficient, for which only the coefficient of flow resistance (friction and pressure) need to be given. The resistance due to the energy loss when flowing out of the end of a pipe is intrinsically taken into account.
  • A piping component, which is a part located in a piping segment. These come in two types:
    • Point components, located in a (virtual) point (from which als the coordinates can be given):
      • Waypoint, which is a geometrical point without further properties. Can be applied to define the pipe geometry.
      • Elbow.
      • Valve, including open/closed indication.
      • Pressure relief valve, including the opening pressure. An important reason to include this type is for the modeling of fire control bulkheads, which are considered to be watertight until a certain water level (=pressure), and collapse at higher levels.
      • Reducer, including the regular flow direction (from high to low pressure), as well as the regulared pressure at the exit. Its way of operation depends on the flow direction:
        • If the flow is in regular direction, then for the hydraulic calculations the set pressure at the exit is applied.
        • If the flow is in the opposite direction, the reducer is assumed to be closed if the pressure at the regulated side (=the original exit) is higher then the set pressure. Otherwise it is open, where the hydraulics arte being computed with calcuthe standard resistance coefficient.
      • Check valve, including the free flow direction.
      • Vent check valve, including the free flow direction.
    • Pipe components, which exist between two point components. This type has just a single member:
      • A pipe section, which is simply a straight pipe between two point components.
    Furthermore, for components also their resistance coeffcient can be given as well as their dimensions.

With this structure complex piping sets can be modelled, and connected to compartments. But also simple networks can be defined conveniently, for which purpose e.g. networks ir components can be defined without geometry. The latter can e.g. be used for a standard de-airation straight above a tank, in which case the exact location of the connection of the pipe at the compartment is not relevant (that is to say, if on eagrees that the geometry of the piping network is omitted in the damage stability calculation).

As illustration of this data structure, below two screensdumps of piping windows have been included. The empty sub window is used for modelling warnings.

Piping GUI.
Piping included in the rendered view.

Other lists, and program settings

List of openings and other special points

From each compartment its openings and other special points can be given, as discussed in Special points / openings (to which we also refer for the purpose of the input cells). However, it may be convenient to collect all special points in a single list, which is performed by this option, on which the following remarks can be made:

  • The sequence of points in this list is primarily that of the compartments and of the compartment points. The sequence can be modified, for example by inserting points, or by changing their compartment, however, such a new sequence will not be saved. In the end the compartment order prevails.
  • [+/-], the sign of the transverse coordinate will be toggled (so the point switches from PS to SB or vv., does unfortunately not work for an entire selected column).
  • With the [Sort] option points can be sorted on compartment, or on type of point. Also this order is temporarily, ultimately the compartment order still prevails.
  • Compartment openings, which are defined here, are also visible in Hulldef, please refer to Openings for a discussion. That Hulldef list may also contain other points, such as those of the margin line, which are not relevant here. However, it may also conntain openings which are not connected to a compartment, and although such points play also no role here in Layout, as a service they are still included in the list of this menu option. Their compartment indication is ‘–Not from a specific compartment’. Because their relevance is less than that of ‘real’ compartment openings, their place in the list is at the bottom (while in Hulldef they are listed at the top, that is not a matter of sloppiness, the reason is that the focus is just different). This type of openings will only be stored in Hulldef format if the setting “Always create conventional PIAS compartment files at save” (please see Layout project settings and function colors is switched on.

List of physical planes

Here a list appears of physical planes, with seven columns, namely:

  • Name and second name: the two names of the plane. Similar as with compartments, it can be set that the second name should be generated automatically, with the setting discussed in Layout project settings and function colors.
  • Abbreviation, of eight characters at maximum.
  • Abs.position: the position of the plane, in metres from App, CL or baseline. This position — not just as fixed by this column, but also by the next column – can be constrained by the presence of other planes, as explained in Limited positioning of a physical plane.
  • Rel.position: the position of the plane in relation to a reference plane, at least, when the plane has been relatively defined.
  • Orientation: longitudinal plane, transverse plane, horizontal plane or angled plane.
  • Locked CM: whether this plane will maintain its location if Constraint Management is going to adapt the plane positions.

In the upper bar of this list is, apart from the usual menu options, a number of specific menu options:

  • When adding a new plane, one directly enters the popup menu of Popup menu for geometry of planes and points.
  • [Geometry], with which one can change the shape of the plane. Directions are described at The shape of a plane (the green dots).
  • [Sort], with which one can sort the planes by columns, i.e. in the order of the data of the column where the text cursor is. This sorting can also be undone again with [Undo].

In all but the sixth column one can enter values directly. With <Enter> one enters a popup menu with data of the plane, and when one at the absolute or relative position presses on <Enter>, one enters the plane definition menu that is decribed below.

List of reference planes

This list contains all reference planes, and is concerning operation and content similar to the list of phisical planes, just above. However, there is an additional rightmost column which lists how often a reference plane is actually used. When entering such a cell a popup window appears with this information split out in compartments, reference planes and physical planes. On this info two remarks can be made:

  • The summation counts all parts which can be related to a reference plane, so not only the measurements of compartments and planes, but also those of sounding pipes and openings etc.
  • Although the subcompartment shape might externally be of different types (such as ‘simple block’ and ‘four longitudinal ribs’, seee Types of subcompartments ‘with coordinates’), internally it is always stored by means of its corners. This implies that certain shape definition measurements may be counted more than once. for instance if an aft compartment boundary has four corners, and that aft boundary is defined by means of a reference plane, it will be inlcuded four times in the reference plane count. Nothing to worry about, but it is good te be informed on this phenomenon.

So, in this menu reference planes can be defined. Letting points and other planes refer to a reference plane is discussed in Popup menu for geometry of planes and points. Apropos, a reference plane can be defined relative to another reference plane, etc.

Compartment tree

With this option there appears a popup box with the same compartment tree view as used in the GUI. Essentially, this tree contains no more information than the regular compartment list of Compartment list, calculation of tank tables etc., except for that it is shown here per compartiments and subcompartiments in one overview.

Layout project settings and function colors

Project settings.

With this option appears the above popup screen, in which a number of program features and colors can be set:

  • The cross-section position of the three orthogonal cross-sections is controlled anyway by clicking in such a cross-section on the right mouse button, then the position of the other cross-section is equalled to the position of the cursor at that moment. But apart from this mechanism, one may also opt for adjusting that cross-section position to a plane or compartment that has been chosen in the compartment tree or planes list. If you want this, then you have the put the first option on yes.
  • Allowance: It is useful when the reference planes are drawn slightly larger than the rest of the ship. That extra size, the allowance, can be defined here.
  • Threshold volume: at a conversion of a compartment configuration to a plane configuration, negative subcompartments can be included integrally. This may result, however, in a substantial increase in the number of used planes, which is not necessarily desired. That's why one can define a limit value (of volume, in cubic meters) here under which negative subcompartments are not included in the conversion to planes, they still exist of course, but simply as subcompartment of the type ‘with coordinates’.
  • Line thickness will be obvious.
  • At the time interval one can define per how many minutes the model is saved automatically. That can be useful in the event of failures, then you still have at least a recent model.
  • Automatic generation of the second name of physical planes or compartments. Compartments and planes have, obviously, a name. For additional identification also a second name may be given. For enhanced convenience, with these two options in wuestion it can be set that these second names are generated automatically, based on the location of the object, according to these systems:
    • Physical planes get a plane type, and their position. If frame spacings have been set (as discussed in Frame spacings) then longitudinal positions are not given in meters, but in frame numbers (with possible an offset in mm) instead.
    • Compartments get a combination of aft boundary, forward boundary, side (PS, SB or ‘over CL’) and the weight group as assigned to this compartment.
    This mechanism permanently updates these second names, so existing manually entered names will be overwritten.
  • As explained in Compartment files it is required for the benefit of subsequent calculations to convert the compartment data to a format that is compatible with Compart. That is possible, since the user is able to order Layout that such a file is generated (see Export compartments to PIAS' pre-2012 format). When one forgets to do this one thinks to be working at such a subsequent calculation with the most recent general arrangement plan, but that is not the case then. That's why one can define at the setting “Always create conventional PIAS compartment file at save” that the compartments always have to be saved in conventional PIAS format too when leaving the program. But do remember that the original PIAS file with compartments is overwritten then. This setting is applicable to the compartments as well as the openings.
  • With option [re-calculate tank tables automatically] the tank tables are (re-)calculated whenever neccessary, that is when the compartment geometry is jounger than the available table. This automatism may take some time, however, for the benefit of table consistency.
  • For the cancel regime see How long stays a function assigned to a mouse button?.
  • The colors will be obvious. The color of ‘rdesired contour points’ is for that of the ‘green dots’. The ‘just generated space color’ and the ‘cut space color’ are only used at a compartment color schedule ‘uniform’ (see for that View). The ‘draw’points color is as used with the draw function in the GUI, see Draw.

Names and color per part category

Names, colors and other part properties.

Herewith one can choose the colors of the various ship's items. In Layout project settings and function colors one could also configurate colors, but that was meant for program items, here we are talking about ship's items, of which seven features can be defined:

  • The first column contains the identification name of a category. This is mentioned here for the purpose of recognition, and cannot be changed anymore.
  • In the next two columns one can set the color as it is used in the 3D views, in the second column for a light background, and in the third column for a dark one.
  • Subsequently two columns in which one can set the color as it is used in the 2D cross-sections (the orthogonal cross-sections), also for light and dark backgrounds.
  • In the sixth column one can define whether this category must be included in the output of the 3D render model, the production of which is described in Threedimensional presentation.
  • In the seventh column one defines whether this category must be included in the DXF output of the general arrangement plan, the production of which is described in 3D-plan to DXF file.
  • In the eighth column one can define the layer name that is allocated to this category in such a DXF output. When defining the layer name one has to observe the conventions of Autocad, or another recipient CAD system. Thus a layer name can have, for example, a specific maximum length, or some signs may be forbidden. For the exact nature of these restrictions, you will have to consult the documentation of the recipient system.

The color of a ‘piping system’ is just the default, which is assigned to a new system. If desired, for each individual system an andividual color can be assigned, see Pipe lines and piping systems.

Define weight groups

With this option one enters a menu where features of weight groups can be defined. A weight group is a specific category of weight, of, for example, a ship or cargo. At the definition of compartments can be defined at the compartment what the weight group is of the volume for which this compartment is intended, for example potable water or palm oil. Color combination or output of loading conditions can take place per weight group. This menu is discussed in more detail in Weight groups.

Notes and remarks

With this option an input screen appears with which one can make separate notes. These notes are saved at the subdivision plan, and can always be altered later on.

Threedimensional presentation

Rendered view, with surface model of hull.
Rendered view, with sectional model of hull, including container slots.

With this option one can produce a three-dimensional rendered view, like in the above figure. In general, this is identical to the 3D view in the GUI, and naturally these functions are applcable, which are discussed in Operation in the 3D subwindows. It differs insofar as that in the GUI the functions must be called upon through a popup box, which is activated with the right mouse button, while the functions are in the upper bar here, so they are more accessible. When drawing such a rendered view, one has to be aware of two issues:

  • When the drawing of hull frame lines is switched off, such objects can sometimes actually be drawn. But those are the compartment frame lines, to be recognized by the color of the compartment.
  • Drawing hull lines and/or planes is only possible when such a model is actually present and when it has been activated in module Config, see Calculation methods and output preferences.

Subdivision plan


The layout of a two-dimensional subdivision plan can be recorded at this option, two examples of which are displayed above. Such a subdivision plan contains the geometric information of the internal geometry, and can be used as schematic general arrangement plan, tank plan or safety plan. The most obvious application is to have this subdivision plan serve as ‘underlayer’ for such other drawing, and to draw all additions (like deckhouses, masts, lights, valves) in other layers. When the subdivision changes later on, then only that underlayer needs to be replaced, and all other layers can be re-used. By the way, the modus operandi on this subdivision plan is somewhat similar to that of the lines plan in Fairway, please refer to Define and generate lines plan for those details. This subdivision plan section is subdivided into six sub options:

Configuration subdivision plan and DXF export

  • Color of the compartments, where can be defined whether any compartment gets an individual color, which is allocated per weight group, or that all compartments are drawn with the same color.
  • Desired container slot size, where can be defined which of the predefined container slots must be drawn in the subdivision plan. The slot size is defined in entire feet, for example 20 or 40.
  • Subdivision plan with color. Here is defined whether the subdivision plan is drawn with color or not.
  • Draw all, or only the selected compartments. If compartments are specified to be drawn in a section or a view, at this row it can be defined whether all compartments should be drawn, or only the selected ones. This setting only applies to the plot of the plan, not to the 3D-DXF file.
  • Coloring compartments in subdivision plan. Here is indicated whether the compartments that are drawn in the subdivision plan are also colored. The alternative is that only its circumference is drawn.
  • Additional margin framework (mm). When drawing the subdivision plan on paper, the available paper space is used as much as possible. At this option one can, however, define an additional free space along the paper edge, in millimeters.
  • Unit of measure of the 3D DXF file. Here one can define whether the unit of measure of the 3D DXF file is meter or millimeter.
  • 3D DXF file name, here one can type either the desired file name, or (with <Enter>) call upon the Windows-filebrowser to indicate the file name.
  • Texts drawing head. A subdivision plan that is printed on paper can contain a drawing head in the right-under corner. Here one can define how many rows this must contain, and which texts must be included.

Names and color per part category

This is exactly the same menu as discussed in Names and color per part category, which for the sake of convenience also has been incorporated in this menu, in order to be able to quickly adjust a configuration.

Subdivision plan layout

The layout of a subdivision plan can be specified here. It is possible to define multiple layouts (maximally four), so that, for example, a subdivision plan with several pages can be defined. When one has chosen this submenu then there firstly appears a window with those various layouts. There is little to say about this, any layout has a name, one can define which one is selected to be drawn later on, and, finally, with the Copy/Paste mechanism one layout can be copied to the other. With <Enter> one enters a window where the details ot that layout in question can be defined. One can define in that screen which views are included at which position in the drawing of the subdivision plan. The desired position of a cross-section is defined in meters shift in horizontal and vertical direction. One must imagine here that a 2D scale 1:1 drawing is made, where certain views are shifted horizontally or vertically over a certain distance (in real-size measures). The scale on which is finally drawn depends on the paper sizes, which are not yet known here, and does therefore play no role yet. Per view one can define the following:

  • The shift in breadth, in m, of this cross-section on the 2D scale 1:1 subdivision plan. This shift has no absolute meaning, but records the relative position of the view relative to other views. It is common practice that one view has no shift.
  • Analogous to the previous row: the shift in height, in m, of this cross-section.
  • The view, which may be a top view, side view or front view as desired.
  • The number of cross-sections that is drawn in this view. When one wants to change this number, one enters a deeper menu.
  • Whether an X-axis must be drawn with grade mark. The alternatives are: no X-axis, plain X-axis, X-axis with grade mark without legend, X-axis with grade mark and legend in millimeters, X-axis with grade mark and legend in meters, X-axis with grade mark and legend in frame number. This last option is only available at the top and side views.
  • Analogous to the previous row: whether a Y-axis must be drawn with grade mark.
  • The description, that is the name of this view, which is printed below the view.

As mentioned above, after choosing the fourth menu option, one enters a deeper menu, where details of the wished cross-sections of the view in question can be defined. Per view one can define here:

  • The position. At front views in m from App, at top views in m from base and at side views in m from CL, positive for a cross-section at SB side and negative for a cross-section at PS.
  • The side. At top views and front views one can define here whether the cross-section is located at one side (PS or SB), or extends over both sides.
  • Section/Contour. Here one defines whether it is a real (inter)section, thus a cutting, or a total view (a contour). The following details are applicable here:
    • A contour can only be defined for the hull, sounding pipes, piping systems and special points. It makes no sense for other objects.
    • At a contour of the hull many points of it are projected in the view plane, and its envelope is determined. Substantial steps in the contour view can be possibly cut as a result. When this occurs, so be it.
    • Pipe lines, sounding pipes and special points can perhaps best be drawn in ‘contour’, because they are all shown then. Mostly there is little to see at ‘cross-section’, because the probability that such a pipe or point is exactly in that section is small (although the program uses a certain tolerance around the section).
  • Hull. In this column one defines whether the hull must be drawn in the view in question.
  • Transverse. Indicates whether transverse bulkheads must be drawn.
  • Longitudinal. Indicates whether longitudinal bulkheads must be drawn.
  • Deck. Indicates whether horizontal bulkheads (decks) must be drawn.
  • Angled. Indicates whether angled bulkheads must be drawn.
  • Compart. Indicates whether compartments must be drawn.
  • Pipe line, indicates whether piping systems (zie Pipe lines and piping systems) must be drawn. Because the subdivision plan would be much to crowded if all piping systems would be drawn in, in the “regular” plan only the intersections between pipe and desired section are drawn — with a ‘section’ anyway. Subsequently, for all piping systems which are selected with ‘separate subdivision plan per piping system’ a separate plot will be produced, containing the entire subdivision plan plus that single piping system. This only aplies to output on paper or file, not to output on screen. In order to emphasize tge pipe lines in those plots a bit, the compartments are drawn somewhat more pale.
  • Sounding pipes. Indicates whether sounding pipes as defined within the compartments (see Sounding pipe) must be drawn.
  • Sp.point. Indicates whether the special points of the compartiments (such as openings, see Special points / openings) must be drawn.
  • Contain. Indicates whether the container slots must be drawn. Note: The container slots must be defined in order to be drawn. That can be done with PIAS module Cntslot.

All physical planes (bulkheads and decks) are being drawn as far as they constitue a separation between compartments, because this gives the most realistic impression. So, this is according to the separating planes on switch which can be defined in the GUI, please refer to View for the discussion. However, this GUI switch has no effect on the plot of the subdivision plan here.

Subdivision plan preview

With this option the subdivision plan is drawn on the screen. It is intended that this preview option is integrated in due time in the definition options of the subdivision plan, so that definition changes are directly and interactively made visible.

Subdivision plan to paper or file

The subdivision plan, that was drawn on the screen at the previous menu option, can be printed by the printer or plotter with this option. When one wants to make a file that contains the subdivision plan, then one can use the mechanism where output of PIAS is rerouted to a file. This can be defined at option ‘Output to’ (see Calculation methods and output preferences), which offers the choice out of three formats:

  • Rich Text Format, RTF, to generate a bitmap that, for example, can be read in MS Word.
  • Encapsulated PostScript, EPS, to generate a file with vector data. Vectors can be displayed much more sharply than a bitmap.
  • Drawing eXchange Format, DXF, to import the general arrangement plan in a CAD or drawing system. With this format one can choose whether the unit of measure is meters or millimeters. The thus generated DXF file consist of line types of the DXF type polyline.

3D-plan to DXF file

Also with this option a DXF file is made, but one that contains the complete 3D model. This file has the following features :

  • Lines are of the type DXF polyline.
  • Bulkheads and decks are displayed by means of a closed, but further non-filled contour.
  • Possible angled planes, for example of the hull, are first divided in triangles, and subsequently saved as wireframe model.
  • Any category, such as hull, decks and 20' containers, comes in its own layer, of which one can define the name at [Names and colors per item category], see Names and color per part category.
  • Only those elements are included of which at [Names and colors per item category] the column DXF has been placed on ‘yes’.

Print compartment input data

Print input data of selected compartments

The input data of all selected compartments will be printed with this option. The aim of this table of inpuit dat is to inform an outsider on the shape and core preperties of the definee compartments. For thi sreason only raw measurmenets are being printed, and not auxiliary definition aids such as distances to reference planes, neither do bulkhead or deck definitions belong to the output.

Three-dimensional views of selected compartments

With this option all selected compartments are printed subsequently, where for eacht compartment the same viewing angle is applied as used in Compartment definition window.

Difference between internal and external geometry

With this option a graph is drawn, where on many cross sections the difference between sectional area (derived from hullform) and the sum of the compartment areas (derived from compartment definition) is displayed. This difference, which should be zero theoretically, may indicate the presence of lacking or double compartment definition. For probabilistic damage stability calculations this check is recommended. Besides, small differences may occur due to properties of the numerical methods used. The configuration ‘difference internal/external geometry with external hullforms’, as discussed in Settings for compartments and tank sounding tables, is applicable to this area comparison.

Define views/sections of compartment plan

With this option views and sections of the compartment plan can be specified, please refer to Sketches of tanks, compartments and damage cases for further discussion and an example.

Draw compartment plan

With this option the compartment plan, as specified with the previous option, is drawn. A compartment plan contains a number of views or sections which are printed one by one. This gives a fairly well insight in the compartment definition, and is fit to be included in stability booklets for that purpose. However, for a more versatile output method reference is made the the subdivision plan, as discussed in Subdivision plan. Such a plan can also contain other items, such as bulkheads, decks and openings.

Conversion, and import and export of subdivision data

Generate physical planes from the totality of convertible subcompartments

This option does four things. First, an overlapping check is carried out, which is entirely identical to the second option in this menu (see Apply advices on converting to physical planes), where subcompartments of the type ‘generated between planes’ can be converted to the type ‘with coordinates’. At this test is also checked whether subcompartments overlap, and if so, the convertibility of one of the two, namely the smallest one, is switched off, so it is omitted at the conversion. Subsequently, all physical planes are removed, after which a new collection of physical planes is generated on the basis of the subcompartments of the type ‘with coordinates’ that mutually constitue exactly those subcompartments. Finally, all those subcompartments are converted to the type ‘generated between planes’. It is not compulsory to use all available compartments at this action; through the setting ‘convertible’, which can be defined in the compartment list (see Compartment list, calculation of tank tables etc.), at the compartment definition (see Convertible) and the subcompartment definition (see Convertible) one can exactly indicate which (sub)compartments are included in this conversion and which ones are not included.

It is advised to use this conversion option tactfully. It may be tempting to convert a complete ship, with all its compartments and tanks, to the combination of physical planes and the subcompartment type ‘space generated between planes’, which is possible and allowed, but one may end up with a large amount of physical planes, without any overview, as a result of which it is useless in the end. It is probably wiser to confine oneself at the conversion to compartments that belong to the main division of the ship, and is also stimulated to do so because the maximum number of convertible subcompartments is 150 (which is not a principal limit, but a practical one). Please also consult what has been written at Use of different types of subcompartments.

Apply advices on converting to physical planes

This option is meant to support the generation of physical planes from subcompartments of the type ‘with coordinates’ (see Generate physical planes from the totality of convertible subcompartments), since that is only possible with non-overlapping subcompartments. First of all is considered here whether there already are subcompartments of the type ‘space generated between planes’, and if so, then the user is asked whether these have to be converted to the type ‘with coordinates’, because the generation of physical planes is only possible on the basis of this type of subcompartments. Subsequently is tested which subcompartments overlap. A report is given of this (when this is very long, it can be cut and pasted to word processor for further printing or further study). At all compartments of which has been defined that their convertibility is ‘automatic at conversion’, is filled in at the smallest subcompartment of the two overlapping ones that this may not be included in the conversion of option 8.1 above.

Clean pre-2012 PIAS compartments

In the old PIAS compartment module Compart subcompartments could only be limited by eight vertices. Apart from that, there was the requirement that they must be convex, and in the test on convexity vertices were not allowed to converse precisely. That resulted in defining vertices for, for example, three-sides or tapered compartments with differences of millimeters. Here, in Layout, this is no longer necessary, and being more serious, those differences of millimeters are counterproductive, because when Layout is constructing physical planes, then there is actually made a plane of one millimeter, and that does not make for overview. The present option detects those differences and almost converging vertices are actually contracted. One must realise, however, that this option does not repair all anomalies, so that manual adjustments might be necessary, for example in the event of:

  • Larger differences than two millimeters. The algorithm would be capable of that of course, but it remains to be seen to what extent a program must change the data imported by the user autonomously.
  • A limiting plane of a subcompartment that is warped (not purely plane). Within a subcompartment of the type ‘with coordinates’ cannot be objected against it, but this cannot be used to generate physical planes (for they have to be entirely straight).

Import PIAS compartments from pre-2012 format

With this option compartments in the format of the former PIAS compartment module Compart are read in, and converted to Layout compartments of the type ‘with coordinates’. The user is supposed to indicate such an old file, its file extension is .cmp. Only “recent” Compart files are recognized, files from before about 2003-2006 are of an elder format and should be converted with Compart (which is done automatically by Compart upon reading the files).

Export compartments to PIAS' pre-2012 format

With this option all Layout compartments are converted to a format that is useful for Compart, and PIAS modules that (still) use that format. See for further explanation Compatibilitity with the former compartment module of PIAS, where it is also emphasized that openings connected to compartments are exclusively managed in Layout, which implies that such openings in the list of Hulldef are being deleted and overwritten at this conversion to pre-2012 format. The conversion is not just on file level, also some internal representations are converted, such as:

  • If a subcompartment in Layout is bounded by more than four points, then that is automatically subdivided in the Compart format in multiple subcompartments of four points, because Compart was designed for that amount.
  • In Define/edit sub-compartments the warning is included that a ‘double’ subcompartment is not allowed in conjunction with an asymmetrical hullform. From Layout this warning can be neglected, because ‘double’ subcompartments are at conversion automatically split in SB and PS parts. Obviously, that only happens with an asymmetrical hull, so if you change a symmetrical hull into an asymmetrical one, you should re-export the compartments to pre-2012 format.
  • If in Layout tank tables have been calculated, at export to Compart the results will also be stored in that format, so it is not neccessary to re-calculate tank sounding tables in Compart.

In order to avoid mistakes, it is recommended always to save the compartments in pre2012 format, as can be set with the option “Always create conventional PIAS compartment file at save” as discussed in Layout project settings and function colors.

Export decks and bulkheads to Rapid Prototyping format (STL)

With this option bulkheads and decks are converted to STL format, which is suitable for Rapid prototyping (or 3D printing). This option is still experimental, and only available to SARC. On www.sarc.nl/images/publications/appendix_swz2012.pdf is an example of how to use such STL file in order to print a ship's subdivision three-dimensionally.

Export to Poseidon (DNV•GL)

With this option data from PIAS are converted to and written to a file in the format of Poseidon, the rules program of DNV•GL. The purpose of this conversion is to transfer the data as available in PIAS to some degree of completeness. The created Poseidon file contains the following data:

  • Main dimensions and other general numerical data. For this purpose, please do not forget to define the ‘auxiliary particulars’ as well, see Auxiliary main particulars. The minimum drafts aft and fore, which must be communicated to Poseidon, are derived from the draft marks. So, for a Poeidon file as complete as possible, at least two draft marks with a so-called ‘Tmax local’ must be given, see Draft marks and allowable maximum and minimum drafts for further guidance. Poseidon parameters for which no data are available in PIAS (such as GL register number and ice class particulars) are left void.
  • Table of frame spacings.
  • The hull form, represented by all frames of the PIAS model.
  • The shape of longitudinal bulkheads and decks.
  • The shape of transverse bulkheads, modelled as ‘transverse web plate’ for Poseidon.
  • Compartments.
  • Global loads: the (envelop of) longitudinal shear forces and bending moments.
  • Local loads: deck loads, compartment fillings and wheel loads.
  • Girders and webs.
  • Plating of shell, bulkheads and decks, with a default plate thickness.
  • Longitudinal and transverse stiffeners on shell, bulkheads and decks.
Ship with bulkheads and decks exported from PIAS, imported and vizualized in Poseidon.

Enter additional Poseidon data in Layout

Many details of geometry of hull and layout are already available in Layout, so these can be converted to Poseidon without additional effort. However, Poseidon also requires data that is not at all available in PIAS, such as local loads or structural data. Layout offers some alphanumeric input menus to enter those data. For that reason with this “Poseidon” export feature, an intermediate menu will open, from which the first option invokes the actual export to Poseidon. The other options open forms in which specific Poseidon parameters, which are not available in PIAS, can be specified. Some of these parameters are all of Poseidon, so for their meaning and application reference is made to the Poseidon manual. On data of a more generic nature the following elucidation is applicable:

  • For the purpose of Poseidons “Cargo and Decks” in one of the tables deck loads can be given. In the first instance you must specify a deck, for which one of the physical planes of Layout should be identified means of its abbreviation (one can actually give any kind of plane, including a transverse or longitudinal bulkhead, but that would be quite useless for deck cargo). The heart of the matter is that the deck cargo will be placed on that particular deck. Additionally, a compartment / subcompartment combination is given, which is used exclusively for the position and length of the cargo (the verification whether the deck is indeed adjacent to the subcompartment is up to the program user). An exception to this mechanism is a load on the upper deck. To this end one gives the Poseidon term “Tdeck” as ‘abbreviation’, as well as a compartment / subcompartment combination which is adjacent to the top of the hull. The fact that this subcompartment is located under deck instead of above does not matter, it is just used to indentify the location.
  • In addition to deck loads, for “Cargo and Decks” also tank fillings can be specified . These are automatically applied to the physical plane which is located at the bottom of a compartment. A combination of tank filling and deck cargo on the same deck is obviously not feasible. Would that be specified anyway, the the deck cargo prevails above the tank filling.
  • Webs (transverse girders) can be given per group, with for each group an aft boundary, forward boundary and spacing between two webs. For each web group a start and an end must be given. The orientation (from inside out, or from bottom up) is not constrained. Start and end are situated on the shell, or on a Layout plane, which can be either a reference plane or a physical plane. These planes are specified by the user by its abbreviation, or, alternatively, the Poseidon concepts “Tdeck” or “Shell” for deck or bottom/shell respectively. For start and end points are further given:
    1. The Layout plane on which (in which) it lies, or, alternatively, shell/bottom/deck, is the web is attached to that. This will be called plane 1.
    2. The position of this point in plane 1. Basically, a transverse or vertical coordinate, however, in order to maintain the coherence with the other components of teh ship layout, reference is made to another plane instead (or, alternatively shell/bottom/deck) — which will be baptized plane 2 — so that start/end point will be situated at the intersection of plane 1 and plane 2.
    3. The inner limit of the web, which will fix the girder height at that location. For this point a third plane (plane 3) must be given, which defines the inner limit at the intersection of planes 2 and 3. Additionally, an optional offset from plane 3 can be given. Alternatively, for the web a constant girder height is specified, in which case plane 3 is omitted. If start and end points share the samen ‘plane 1’, and if that is a physical plane in Layout, then with a constant girder height the inside will run parallel with the outside. In this way a web along the shell can be defined.
    With these parameters quite some variations in structural layout can be defined, as illustrated in Examples of defining girders and webs. With a web two Poseidon-related details are relevant:
    • It is not crystal clear how Poseidon determines at which side the girder height should be taken. In one instance it is at the left of ‘plane 1’, in another at the right. So it will require some experimentation to discover the rule behind.
    • From a web it can be specified whether it is situated at PS, at SB or at both sides. In Poseidon this is interpreted loosely, which means that a web shape is simply copied to the other side, even if the plane to which the web refers does not exist at that side.
  • Girders (longitudinal) are defined similar to webs, just the wording can differ now and then. A group of girders is given in transverse or in vertical direction, so angled directions are excluded. Transverse coordinates whould be given only positively; the switch PS/SB/Double determines the applicable side (this is, after all, the way Poseidon works).
  • Specifying webs and girders in PIAS is aimed at a quick — and integrated in the Layout structure of bulkheads and decks — definition of the primary structural elements and the most commonly used web/girder configurations. However, not each and every variant is supported by this PIAS mechanism.
  • Stiffeners on web plates are easily defined by giving the abbreviation of a Layout plane or Poseidon element “Tdeck” or “Shell”. Now define the start and end point of the stiffeners moulded line and the centre to centre distance and number of stiffeners. Now the only things left are, on which side the stiffener should be positioned and defining the type and dimensions of the stiffener and how it's positioned in regard to it's moulded line.
  • Transverse and longitudinal stiffeners on longitudinal plates are defined in a similar way as stiffeners on web plates. There two additions namely:
    • For transverse and longitudinal stiffeners on longitudinal plates one has to define a longitudinal start and end so instead of defining one begin and end point for the stiffeners moulded line there are now two, one on the longitudinal start and one on the longitudinal end. The begin and end point of the stiffeners moulded line will be interpolated in relation to the element on which the stiffener is located, decks and longitudinal bulkheads have a fixed interpolation direction but the Poseidon elements “Tdeck” and “Shell” can be set to vertical or transverse.
    • For the longitudinal stiffeners on longitudinal plates there is the extra option to define the rotation of the stiffener in relation to the moulded line of the stiffener. One can also define a rotation which is relative to the element on which the stiffener is positioned.
  • Defining the plate fields is achieved by giving the abbreviation of the Layout plane or Poseidon element “Tdeck” or “Shell” and then defining a standard plate's dimensions as well as the moulded line of the Layout plane or Poseidon element. The physical area of the Layout plane or Poseidon element will be split into a bunch of plate fields with the afore mentioned standard plate dimensions. This division is handled in a specific way for each element:
    • Longitudinally, from the aft to the front; Transversally, from the centreline to the outside; Vertically, from the bottom to the highest point.
    • The specific Poseidon elements “Tdeck” and “Shell” are handled in the same way as Layout planes but the specific geometric definition of these elements is outside PIAS's control.
Definition moulded line plane and stiffener.

Examples of defining girders and webs

Example 1: There are always two intrinsic planes present namely ‘Shell/deck’ and ‘maindeck’. And lets make, for convenience, ‘centreline’ (CL) also intrinsic. The web with fixed height H, as seen in the picture below, is defined by:

  • Begin point plane ‘Shell/deck’ on intersection with CL.
  • End point also plane ‘Shell/deck’ (this is neccessary because we are using a fixed girder height) on intersection with ‘maindeck’.
  • Fixed girder height H.
Definition girders and webs, example 1.

Example 2: Web plates A and B are defined separatly, as shown in the picture below. First web plate A:

  • Begin point along plane Shell/deck on intersection with CL.
  • At that begin point the inside of that web on height TT. For this the intersection of CL and TT is taken which is exactly what we want.
  • End point plane Shell/deck on intersection with TT.
  • At that end point the inside of that web on height TT. For this the intersection of TT and TT is used, which there are an infinite number off, but in this exceptional situation we will choose the intersection of Sheel/deck which is exactly what we want.

And web plate B:

  • Begin point along plane Shell/deck on intersection with TT.
  • At that begin point the inside of that web on breadth R1. For this the intersection of TT and R1 is taken and that is precisely what we want.
  • End point along platen Shell/deck on intersection with main deck.
  • At that end point the inside of that web on breadth R1. For this the intersection of main deck and R1 is used which is precisely what we want.
Definition girders and webs, example 2.

Example 3: Finally the construction, pictured below, with a deck and a longitudinal plate which both have been fitted with girders of different dimensions. There are four webs, web plate A is defined as follows:

  • Begin point along plane TD on intersection with CL.
  • End point along plane TD on intersection with LS0 or LS1.
  • Fixed girder height which belongs to A.

Part B:

  • Begin point along plane TD on intersection with LS0 or LS1.
  • End point along plaen TD on intersection with Shell/plane.
  • Fixed girder height which belongs to B.

Part C:

  • Begin point along plane LS0 on intersection with Shell/plane.
  • End point along plane LS0 on intersection with TD.
  • Fixed girder height which belongs to C.

Part D:

  • Begin point along plane LS1 on intersection with TD.
  • At that begin point the inside of that web (as well as) along plane LS1 on intersection with TD with an offset HD0.
  • End point along plane LS1 on intersection with maindeck.
  • At that end point the inside of that web (as well as) along plane LS1 on intersection with maindeck with an offset HD1.

Note that the parts A and C partially overlap. This can't be helped because of the design model where by not every detail is been shown. For the benefit of the simplicity of the data definition (and thus the definition speed).

As mentioned before a web can be streched along multiple planes. Take for example; that C&D have a fixed girder height H (and a fixed thickness etc...) this can then be specified as follows:

  • Begin point along plane LS0 on intersection with Shell/plane.
  • End point along plane LS1 on intersection with maindeck.
  • Girder height H.
Definition girders and webs, example 3.

Lastly a description on the term ‘Layout-plane’. Such a plane can be used for the definition of the positions of the webs, it's as simple as that. There are no further requirements on the presence or continuity of the planes. This gives a certain freedom which can be used as follows:

  • A reference plane. This is simple, they strech along the whole vessel.
  • A physical plane, which definitely can be used where it's located.
  • A continuous physical plane. In the end a physical plane is nothing else that an infinite plane including a certain closed boundary. Also outside this closed boundary the infinite plane continuous and this can best be used in terms of positioning. For example, the height of a girder can be referenced on the tanktop even in places where this tanktop is not present.

Modus operandi of the PIAS→Poseidon conversion

  1. Use this Layout option, which creates a text file, with .txt extension (as required for import in Poseidon).
  2. Gebruik deze Layout optie, waarmee een tekstbestand wordt aangemaakt met extensie .txt (zoals vereist voor de import in Poseidon).
  3. Start Poseidon, and select File/Open.
  4. Choose at Files of type: Poseidon TXT File (*.txt).
  5. Indicate the file just created by Layout.
Ship, layout, plates, girders, webs and stiffeners defined in PIAS, converted to Poseidon.

Design choices, limitations and conditions

The PIAS→Poseidon conversion has, in close collaboration with the leading customer, been designed for this anticipated use:

  1. Ship data and layout data which are intrinsically present in PIAS must be converted to Poseidon.
  2. It is the intention of this customer to ultimately manage data of hull, layout and structure from a central design system, and to convert those to Poseidon via PIAS.
  3. For practical reasons, it was decided that data types not included originally in PIAS (such as deck loads, girders and stiffeners) should, for the time being, be entered in PIAS in simple alphanumeric menus. These input menus lose their role once these data are included in the central design system. That is why these import menus are quite Spartan, and are not equipped with graphical input or feedback facilities.
  4. PIAS stores these additional Poseidon data in XML format. This makes it possible for that central design system to write out the same data in that format as well, so that they are immediately available in PIAS (and hence for conversion to Poseidon).
  5. The data that PIAS can supply to Poseidon is sufficient for that first customer with the current implementation. However, there are also things that are not included in PIAS and this conversion, such as pillars, man holes and welding details. For the time being, it is not the intention to extend the conversion with these components, although in specific cases extension can always be discussed with concrete users.
  6. Obviously, each user is free to supplement or modify the data that is imported from PIAS with the User Interface of Poseidon.
Poseidon‘s interface format has occassionaly very specific requirements and restrictions. In this conversion option of PIAS quite some effort has been put to meet them as much as possible, and the many tests show that the geometry from PIAS transfers rather well into Poseidon. However, in general, a flawless operation in Poseidon is not guaranteed.

On this conversion the following remarks and conditions apply

  • This conversion is tested with and valid for Poseidon version 17.0.8, (2018).
  • Poseidon is fully dedicated to construction frames, so it is of utmost importance to define the frame spacings properly in PIAS (see Frame spacings), including the position of the aftmost and foremost frames.
  • Angled transverse bulkheads are excluded from the conversion.
  • For Poseidon it is a prerequisite that frame 0 coincides with the APP (see chapter 2.2 of the Fundamentals manual of Poseidon).

In Poseidon a so-called longitudinal element is bounded by either another element, or the shell. However, in reality these boundaries may changed, for example the lower boundary of a longitudinal bulkhead, which may at the aft side be the tanktop and at the fore side the shell. For Poseidon this bulkhead should be split into two parts; an aft part which is bounded by the tanktop, and a forward part bounded by the shell. PIAS will detect such a phenomenon, and split automatically. However, there is a pitfall which is related to the split location which should be positioned exactly on the intersection between two internal planes and the shell. In our example the intersection of longitudinal bulkhead, tanktop and shell. This point can easily be obtained by interpolation, however, because PIAS and Poseidon apply their own independant interpolation methods it may very well occur that on the split position as determined by PIAS, Poseidon does just not find an intersection between bulkhead and tanktop. In such a case the split position will have to be modified slightly, manually in Poseidon. This phenomenon is intrinsic to Poseidons modus operandi, in particular to the requirement that a longitudinal element must be split, and can in principle not be avoided. However, in practice its occurrence is proportional to the interpolation neccessity, so, it is advised to include in PIAS as many frames as possible, preferably all construction frames (which can be generated conveniently with Fairway).

Write XML file

For the purpose of communication with other software, with this option one may export the ship's subdivision data to an XML file. At present this file contains data of compartment shapes, bulkheads & dekcs and reference planes. This data is limited to that which users have really needed up to now, and includes eg. shapes, names and location of the different entities, but not all the details. E.g. the second compartment name and the sounding pipe are missing. However, if required these data can be added, please also refer to Export naar en import uit XML. The name of the file written is PIASfilenaam.fromLayout.XML.

Incidentally, these XML data are not only available via a file, but also in direct and permanent comunication between computer programs. In this way, multiple persons can work with different CAD programs simultaneously on the same ship design. More details can be found in a paper, www.sarc.nl/images/pdf/publications/international/2015/Koelman%20Compit%202015.pdf, which has been presented at the Compit'15 conference.

Read XML file

With this function, an XML file with ship's internal layout can be imported into Layout. All comments made in the previous section, on exporting, also apply here. The expected file name is PIASfilenaam.toLayout.XML.

File and backup management

Backups of the ship's subdivision can be made and restored here. Here is also the option ‘Stop without saving’. See for the details Data storage and backups.

Compatibilitity with the former compartment module of PIAS

Around 1985, the PIAS module Compart has been developed, with which compartments could be defined and tank tables etc. could be calculated. More details can be found in chapter 210 of the former PIAS manual. The module Layout, which has been developed in the years 2010-2012, has the same purposes, but is much more extensive, and disposes of a GUI. This transition from Compart to Layout has two consequences, which are set out below:

Compartment files

At this moment, PIAS is in a transitional phase as far as the compartments are concerned; the compartments can be designed and/or imported with Layout, but many follow-up calculations (such as tank volume, intact stability, grain and tonnage calculations) still have to be carried out with PIAS modules that have not yet been adapted to the file format of Layout. That's why for the benefit of these calculations a file format has to be made from the Layout data that is compatible with Compart. That is possible in two manners, see Export compartments to PIAS' pre-2012 format and Layout project settings and function colors, option [generate PIASs compartments when saving]. One should be aware, however, that the follow-up calculations are carried out with the most recent internal geometry model, which can be done, of course, with module Compart. This involves the risk that one, in the heat of the moment, makes a change in Compart, which is not implemented in Layout, and which gets lost when one regenerates Compart files from Layout later on. Therefore, with compartment files which originate from Layout, Compart only can act as a viewer, which implies that the compartments can be inspected, but can no longer be modified.

An similar mechanism applies to openings. Openings that are connected to a compartment are exclusively managed by Layout. For compatibility and overview reasons, they are visible (colored gray) in the opening list and overview plots of Hulldef, albeit unmodifyable. In order to avoid confusion, if one or more of such Layout managed openings exist, Hulldef will not allow that any unconnected opening will be connected to a compartment.

Functional enhancements of Layout

Compared to Compart, Layout has many enhancements. In due course Layout will be made available as update, free of charge, of the Compart user license(s). However, some of the specific Layout enhancements require an additional user license. These enhancements are:

  • The use of physical planes, and anything related to it.
  • The use of subcompartments of other than four vertices (in Compart, namely, a subcompartment could only have four vertices in the cross-section).
  • The second sounding pipe at the compartment, as well as the use of more than one pressure gauge.
  • More than one computation script or output script.
  • Drawing of (sub)compartments in the ‘visual composing’ mode, as discussed in View functions.
  • Three-dimensional rendering, see Threedimensional presentation.
  • Saving or printing of three-dimensional, rendered pictures.
  • The subdivision plan, see Subdivision plan (which is a separate extension, not linked to the others as listed above). Apart from that, a number of functions of Layout are available as additional option:
  • Export to Poseidon, see Export to Poseidon (DNV•GL).
  • XML communication, see Write XML file and Read XML file.
  • Generation of 3D printing files, see Export decks and bulkheads to Rapid Prototyping format (STL).