Container Loading (CL)

8/23/2019 Container Loading (CL)

1/96 1992-2009 Napa Ltd. All rights reserved.

NAPA Online Manuals 2009.1

Container Loading (CL)


2/96



1992-2009 Napa Ltd. All rights reserved.

Table of Contents

1 Container loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Overview of functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Connection to other subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.4 Handling container loads under loading conditions (LD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.5 Steps involved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.6 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 General principles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Basic concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Parts of a container arrangement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.3 Properties of stacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4 Properties of blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.5 Properties ofcontainer types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.6 Numbering of container positions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.7 Management of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.8 Usage of alignment points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.9 Mixed loading of long and short containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.9.1 Long and short containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.9.2 General requirements for mixed loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.10 List of quantities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Defining container arrangements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 Defining a block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1 The BLOCK command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.1.2 Block defined for mixed loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.3 Defining the coordinates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.5 Adding vertical gaps with the ZCORR command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.6 Removing locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.7 SYM and REFLECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.8 Defining stack specific exceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.9 Auxiliary commands under block definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1.10 Finishing the block definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 Defining combined arrangements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.3 Defining stacks under table calculation (pilot). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4 Designating subsets of bays, rows and tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.5 Defining arbitrary subsets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Auxiliary definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1 Definitions related to the owner numbering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1.1 Defining the numbering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1.2 Defining the formal owner numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.3 Owner numbering range separating containers in hold/on deck . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.5 Copying the owner numbering system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 Various parameters (subtask ADM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2.1 Bay numbering convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2.2 Source of container types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2.3 Defining additional quantities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2.4 Checkmode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2.5 Criterion for separating long and short containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23


3/96




4.2.6 Criterion for accepting differing container dimensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2.7 Height tolerance for long containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2.8 Interpretation of real/formal bay numbers in loading commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2.9 Exit from block definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.3 Default template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.4 Default substance for LCA NEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.5 Defining container types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.6 Templates for controlling texts inside containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5 Loading functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.1 Role of the container arrangement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2 The container type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.3 Administrative commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.4 Definition of loads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.4.1 Creating a new container load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.4.2 The ADD, REDUCT and CHG commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.4.3 The ADD command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.4.4 Specifying container properties in the ADD command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5.4.5 General subset selections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.4.6 Summary of the ADD command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5.4.7 The REDUCT command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.4.8 The CHG command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.4.9 Changing the alignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.4.10 Loading containers occupying double bays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.5 Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.5.1 Checks done when loading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.5.2 Separate checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.5.3 The UNDO command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.6 Defining container loads under table calculation (pilot) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.7 Graphic information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.8 Description of a container load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.9 Listing data about a load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.10 Variables related to the current load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.11 Adaptation to changed arrangement and types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.12 Generating the lateral profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.13 Connection to loading conditions (LD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.13.1 Adding a container load to a loading condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.13.2 Changing a container load directly under LD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.13.3 Listing container data under LD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.13.4 Plotting under LD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.13.5 Entering container loading from the LOAD task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6 Drawing functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.1 Ways of drawing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.1.1 General projections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.1.2 Orthogonal projections, real geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.1.3 Orthogonal projections, modified geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.2 Drawing commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.3 The PLOT command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.4 Command PO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.5 The plot options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.6 Plotting individual containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.6.1 Selecting fill colour (FILL option) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.6.2 Using figures to represent containers (FIG option) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.6.3 Adding text information inside containers (MI option) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47


4/96




6.6.4 Combining information for long and short containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.7 Adding text information at the sides of a plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.7.1 Selecting the quantities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.7.2 Formatting the texts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.7.3 Position control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.7.4 Adding headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.7.5 Adding frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.8 The NG option (non-geometric) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.9 The PART option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.10 Controlling the drawing order for hidden lines effect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.11 Drawing into the SETUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.12 The general drawing functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.13 Drawing during block definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.14 Additional drawing examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.14.1 Example 1 - arrangement plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.14.2 Example 2 - not involving containers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.14.3 Example 3 - checking visibililty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7 Output functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.1 General basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.2 Listing commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.3 Listing by container . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

7.4 Listing by line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.5 Listing by stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.6 Listing by layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.7 Listing by container type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.8 Transfer of data to table calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.9 Auxiliary listing functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667.9.1 The bare LIST command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.9.2 Listing data for arrangements (INFO command) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.9.3 Listing data from container type definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.9.4 LIST .id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.10 Accessing container data in macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.10.1 Variables maintained . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.10.2 Calculator function CLINFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.10.3 Using the table calculation connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

8 Command specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

8.1 Commands on the main level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

8.1.1 Definitions related to containers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708.1.2 Output functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

8.1.3 Defining container loads. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

8.1.4 Various functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

8.2 Commands in subtask BLOCK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

8.3 Commands under ADM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89


5/96



1 (92)


1 Container loading

The container loading subsystem contains functions supporting the design of container arrangements and creating

container loads for use as such or as parts of loading conditions.

The potential locations of containers are defined as so-called container arrangements. Their role is analogous with that of

a compartment arrangement in ordinary loading, and forms the basis for the loading of containers.

The container arrangement has a function in its own right, for assisting the design of the ship. From the container

arrangement, the container capacity can be calculated and drawings can be prepared for showing the location of containers.

In generating the container arrangement, one can take advantage of the geometry of ship structures.

The functions of container loading can be applied to other cases of objects loaded at predefined positions in a more or

less regular pattern, for example cars on a car deck.

1.1 Overview of functions

The central functions related to container loading are

s definition of container arrangements

s drawing container arrangements as such or in arrangement plans

s output of container counts and other properties

s definition of container loads

s output data for container loads in table or graphic form

s adding container loads to loading conditions

1.2 Connection to other subsystems

Geometry (definitions):

Objects in the ship can be used for providing locations and for eliminating non-available positions in a container block.

Geometry (drawing):

Container arrangements and container loads can be drawn into arrangement plans or combined with ship geometry in

other ways.

Loading conditions:

A container load can be added as a component in a loading condition. Some output functions of CL are available directlyunder the main task of LD. For more details, see below.

Stability criteria:

A modified lateral wind profile can be generated from a container load.

1.3 Installation

Defining container arrangements can be considered part of the description of the ship, and belongs therefore to the ship

model, while loading containers belongs to loading conditions. However, from the practical point of view, defining

arrangements and loading them have much more mutual connections than with the main tasks mentioned, and have

therefore been collected into an single subtask CL. In order to account for the two aspects above, this subtask has been

installed both under SM (ship model) and under LOAD (loading conditions). The following map is shows how the CLsubtask is accessed


6/96



2 (92)


Installation of container loading

The map also shows the direct access to the drawing task, without leaving container loading.

A few commands belonging to container loading are available directly in the loading condition task: AC (add containers),

RC (remove containers) and CLA (container load administration).

1.4 Handling container loads under loading conditions (LD)

Containers cannot be added directly to load cases (except as ordinary mass loads), but are collected into container loads,

added as a whole. Defining a container load can be a fairly complicated process, and this task can be managed more

easily when done independently of loading conditions, and the result can be used repeatedly by combining it with different

'ordinary' load components or with different other container loads. This principle is also dictated by the need to minimize

the interdependence between the two large subsystems, LD and CL.

In order to provide some shortcuts when working under LD, the following functions are provided:

s the main container loading commands are available (add, remove containers)

s a loading condition can have an 'own' container load that is read and stored automatically with the load case

s some administrative functions of CL are available under LD

The listing and drawing functions of CL are available under LD.

1.5 Steps involved

This paragraph gives a short overview of the steps involved in analyses including container loading.

1. Defining container types

This function is not necessarily ship dependent and standard type definitions can be prepared.

2. Defining the owner numbering system

To some extent, a numbering system can be standardized, but there is likely to be ship specific exceptions requiring

adaptations.

3. Defining container arrangements

The potential container locations are defined, beginning with the basic components, which can be combined into

larger sets.

4. Defining container loads

Different ways of using the container positions are defined.

5. Independent analyses of container loads

Calculations and graphic presentations of the container loads can be prepared independently of other subsystems.

6. Analyzing loading conditions containing container loads

The behaviour of the ship as a whole is studied, when loaded with containers. This includes the effect on the wind

area in stability criteria.

Normally, the general ship geometry has been defined when container loading is done, but it becomes strictly necessary

only when loading conditions are involved.


7/96



3 (92)


1.6 History

Container loading was first introduced to NAPA in 1990. As demands on the system increased and a better understanding

on how it should work developed, the need to revise some basic solutions was recognized. In 1994, this revisions was

made and the first official release to include the revised system was 95.1.

The data structures are to a large extent incompatible, and for the transfer from pre 95.1 versions to the present one, see

CL.2, chapter Conversion.

2 General principles

2.1 Basic concepts

The central concepts in the subsystem are container arrangements and container loads.

A container-arrangement means a definition of the possible container positions. Its role in the loading process is similar

with the compartments in ordinary loading. This function is installed as subtask CL, which can be entered from the ship

model (SM) task or the loading condition task (LOAD).

A container load is formed by a set ofstacks. meaning a vertical set of containers loaded one upon the other. A container

arrangement describes the places where such stacks can be loaded. In connection with an arrangement, the word 'stack'

refers to such a place. As a way of defining many stacks at a time, there is the concept of block as described in the next

paragraph.

Defining a container load means placing containers into a container arrangement.

Container loads can be added as load components into a load case. The weight, center of gravity and weight distribution

are taken into account. Containers on deck are taken into account in criteria involving the profile. Container loads are

handled under task LOAD with the MASS command.

2.2 Parts of a container arrangement

Logically, a container arrangement is considered formed by a three dimensional matrix of spaces, oriented as the ship

coordinate system. The transversal layers are called bays, the longitudinal layers rows and the horizontal layers tiers.

These layers are numbered, and a container position can be designated by the bay, row and tier number.

Bay, row, tier and stack

A set of containers with the same bay and row number and physically connected, i.e. standing on each other, is called a

stack. This is the basic component from which the container arrangement is formed. A stack is always vertical, having

a fixed location in x and y. When containers of different dimensions are loaded, the alignment point controls the relativeposition in x and y so that the alignment point of a container is made coincide with that of the container below or that

of the stack. There may be several stacks in the same bay and row, normally one under deck and one above deck. These


8/96



4 (92)


are distinguished by their starting tier number. In most cases, the word 'stack' refers to a physical stack as presented. A

logical stack is the total set of containers with the same bay and row number.

Except for the stacks, the bays, rows and tiers of a container arrangement need not be geometrically aligned, i.e. a fixedcoordinate being associated with a given bay, row or tier number. However, there are usually subsets with this property,

and for taking advantage of this in the definitions, the block concept is available. A block is formed by a three-dimensional

matrix of spaces with fixed x-, y- and z-coordinates in each transversal, longitudinal and vertical layer, but not necessarily

with uniform spacing. Within the matrix, there may be positions not corresponding to possible container locations, which

are specified in the block definition, and taken into account when loading.

Example of a basic block

Example of a block with positions removed and non-uniform spacing

A set of stacks can also be defined directly, so that the relevant properties are defined directly for each stack (pilot level

only).

A block or a set of directly defined stacks can be used as such as arrangements. However, in most cases it is useful to

collect the arrangement from separately defined parts as a combined arrangement.

The following figure illustrates a combined container arrangement

Example of combined container arrangement

In order to give a preliminary idea of the definitions, the definition of the arrangement is presented below:

BLOCK IN-HOLD C1

X, 10, 6, 1, 6, 1, 6; Y 1.5 4; Z 0.3 5

REDUCT Y>HULL -0.4; SYMMETRIC

BLOCK ON-DECK C1, B1=4 T1=6

X, 22, 12; Y 0 4; Z 11.5 6; SYMMETRIC


9/96



5 (92)


COMBINE C-ARR1 IN-HOLD ON-DECK

2.3 Properties of stacks

The following properties are relevant for stacks. The symbols given below are the names of the quantities representing

the properties.

s container type (CTP)

The container type provides the basis for the spacing and the default for container loads. The type can be changed

when containers are loaded. Capacities referring to the arrangement as such are calculated as if the places are

occupied with containers of the default type.

s double size container type (CT2)

If the stack is such that it can be loaded in combination with its neighbouring stack by double sized containers, a

default container type is needed for this purpose.

s position in x, y and z (REFX, REFY,REFZ)

This information is stored as the location of the alignment point the default of which is the lower x-, y- and z-

coordinate.

s numbering, bay, row and tier (BAY, ROW, T1)

The bay and row numbers are fixed for the stack, while the tier number means the lowest tier in the stack.

s number of containers that can be loaded

The nominal capacity of the stack is expressed by the number of containers of the default type that can be loaded or

indirectly by the highest tier number (TN). This implies a maximum height, which is the actual limitation used.

s maximum height (ZMAX)

This places a limit on how many containers can be loaded. It is inferred from the container positions defined, as

presented above, but can also be defined directly.

s size, length in x, y and z (LENX, LENY, LENZ)

The size refers to the space reserved for the individual containers and is obtained from the default container type.s on deck/in hold (DH)

It is recorded whether the stack is on deck or in hold. Unless explicitly defined, the default is based on the tier

number.

s maximum stack weight (WSTMAX)

The maximum allowed stack weight places another limitation on the container load that the stack can have and is

used for check purposes.

s alignment point (LXAL, LYAL, LZAL)

The alignment point is measured from the lower x- and y- limits and defines a reference point that is made to

coincide with that of the container. By default, the alignment point is derived from properties of the default

container type.

s orientation, longitudinal/transversal (ORNT)

Containers are normally loaded as defined, i.e. with the x-dimensions longitudinally. By defining a stack to betransversal, the containers are turned 90 degrees so that x and y change place.

The height of the associated container type decides the vertical spacing, i.e. the height of the tiers. These heights will be

modified if the stack is loaded with containers of differing height.

2.4 Properties of blocks

A block is fast way of generating a set of stacks forming a regular matrix. The basic information on which the block is

dependent is a set of x-, y and z- coordinates defining the locations of the bays, rows and tiers. By separate instructions,

stack specific deviations can be defined. The numbering is always such that consecutive layers have consecutive numbers

in the internal numbering system.

Other stack properties are either derived from the default container type or common instructions in the block definition.However, individual maximum stack weights can be defined.


10/96



6 (92)


Comment. Presently, the only way to more directly define individual stacks is by way of a table, which is provided as

a pilot level feature.

2.5 Properties of container types

The main properties of containers are handled by defining container types. The definition of a container type gives some

fixed properties and some properties that are only defaults and can be changed in connection with loading. In addition to

the standard properties described below, the user can add own properties which can be used in output functions.

The role of the standard properties is the following.

s physical dimensions of the container

Since the system is not concerned with the detailed properties of the containers, these are presently not used, but

reserved for future functions, for instance in drawing. The physical container is assumed centered inside the logical

one.

s logical dimensions of the container (LENX, LENY, LENZ)These dimensions define the total space occupied by the container. It means the minimal distance between

consecutive containers, and decides the spacing of blocks and height of stacks. All local distances are measured

within the logical dimensions.

s local center of gravity (LXCG, LYCG, LZCG)

The local center of gravity means the (default) center of gravity of the container, measured from the lower limits of

the logical container.

s weight (W)

The weight defined for a container type provides the default when loading containers. In a given loaded container it

can be changed.

s minimum, maximum weight (WMIN, WMAX)

The minimum and maximum weights define the interpretation of relative weights, so that 0%=minimum and

100%=maximum. These are also used for error checks.

s fill colour (FCODE, LFCODE)

The fill colour can be used when containers are drawn so that types are distinguished by colouring The colouring

can be defined as colour or pattern indices (FCODE) or logical fill codes (LFCODE).

s alignment point (LXAL, LYAL, LZAL)

The alignment point is used for controlling the position of the upper container with respect to the lower. The lowest

container in a stack obeys the alignment point of the stack. The alignment point is defined with respect to the lower

limit of the logical container.

s descriptive text (DES)

The descriptive text is used for documentary purposes.

Illustration of some container properties


11/96



7 (92)


Other properties can be defined as needed. These will have no function in the calculations, but are available for output

purposes or for doing selections. A list of such properties are maintained in order to allow the system do some error

checking (command QNT under ADM).

The dimensions related to the container are presented using quantities referring to x-, y- and z, according to the normal

orientation of the loaded container. However, it is possible to load a container transversally, in which case the x- and y-

dimensions change place.

The properties of the container types are taken into account when generating the geometry of blocks. If the dimensions

are changed, the definitions of the blocks have to be repetated.

2.6 Numbering of container positions

Container positions are designated by bay, row and tier numbers. The numbering system is global, i.e. it concerns the total

set of containers. Each part of the arrangement must therefore be placed into the global numbering system.

In the internal processing, a numbering system is used that reflects spatial relations betweens the bays, rows and tiers.

Within this system, containers are numbered as follows:

s bays are numbered 1,2,3..., in the order the bays are encountered when moving from the bow to the stern.

The numbering order can be be reversed by defining a different convention in the installation parameters or

configuration parameters (see task ADM). The numbering range actually used need not start from 1.

s rows are numbered so that the center row has number 0, if any,with numbers 1,2,...on the port side and -1, -2 ... on

the starboard side. If a lefthanded coordinate system is used, the numbering is reversed.

s tiers are numbered 1,2,3... from below up.

It is not necessary that all internal numbers in a given range are occupied in a given arrangement.

The numbering system used in com mands and output. the so-called owner numbering. is defined separately. From

the system's point of view, this numbering system can be arbitrary, and works more like labels. However, there are thefunctions presented below where the numbering system is used for distinguishing bays with long and short containers.

The owner numbering is defined by associating each internal number with an owner number. This is the only place where

the internal numbering is visible to the user.

The numbering systems


12/96



8 (92)


The owner numbering system has a very central role in both input and output functions, and should be carefully

designed and complete before starting with the main definitions.

The bay numbering convention (aft or forward) must also be fixed in advance.

2.7 Management of changes

The following categories of data are involved in the system:

s the numbering system

s container types

s primary arrangement parts

s combined arrangements

s loads

This paragraph gives an overview of how the dependence between these categories are handled.

The numbering system is assumed to be fixed. At least to some extent an installation level standard should be useful. There

is no support for changes in the numbering system when the container definitions have been made. However, in many

cases a change of numbering may have no other adverse effects than that the output of the DES command is incorrect.

The geometric properties of container arrangements are decided when the arrangements are defined, and generated

according to the container dimensions valid at that time. Changes in the container dimensions can only be taken into

account by repeating the definitions. Other dependences of the container types are dynamic, i.e. applied as valid when

the system is run.

The dependence of combined arrangements on the parts is also handled dynamically.

A container load is stored in a way that tells what type of container is placed in a given position, expressed by bay, row

and tier numbers. If the arrangement is changed, the positions may disappear or change place and these changes will be

taken into account when the load is used. A load belonging to a nonexistent position is removed. Changes of container

types are also taken into account automatically. Note also that a container weight given as a relative one is converted to

an absolute weight and recorded this way.

If the container load has been affected by any of these changes, a message is given when reading it, telling the resulting

change in weight and container count.

2.8 Usage of alignment points

The purpose of the alignment points is to allow the system to load correctly containers of differing length, for example a

40 foot one on top of a 45 foot one. The location of the upper container is adjusted so that the alignment points coincide.The lowermost container obeys the alignment point of the stack.

This logic assumes that the alignment points on the bottom and the top of the container are the same. In other cases, the

difference must be declared in the loading command (quantities XCORR, YCORR).

This facility is primarily intended for the longitudinal direction, but for symmetry, the alignment logic is provided in the

y- and z-direction also. Alignment in the y- and z- directions is considered pilot level.

The alignment point is always measured from the lower coordinate in the current direction. There is no logic for, for

example, taking into account reflections of containers.

The following figure illustrates the alignment logic:

In the example, the two lowest containers are loaded normally. For the third container, a change of alignment is given.

This will automatically be inherited by the upper containers.


13/96



9 (92)


2.9 Mixed loading of long and short containers

In general, a stack is loaded by piling containers on top of each other, without affecting the neighbouring stacks. Under

the conditions presented below, it is possible to load a container so that it occupies two adjacent bays. Most frequently,

this occurs when loading 40 foot containers over two 20 foot bays. This following figure illustrates an arrangement loaded

with short and long containers:

Long and short containers

2.9.1 Long and short containers

For the purpose of mixed loading, a 'short' container means here one that occupies one stack, while a 'long' one occupies

two adjacent stacks. However, there may also be stacks designated for a single length. In order to control the effect of

loading commands in these cases, container types are also classified as long or short using a length limit defined in the

configuration parameters (see LCR/ADM). A stack is designated as long or short depending on the default container type.

2.9.2 General requirements for mixed loading

In the arrangement, locations intended to be loaded by either one long or two short containers are defined as two bays

of the short type. These must be defined in the same arrangement part - such pairs are not checked for between different

parts of a combined arrangement. The two short bays form the physical definition of the arrangement, for example, stackweights are relevant for these only. The long containers are treated as forming formal bays. in contrast to the 'real' bays

defined in the arrangement.

The arrangement part (block) concerned must have two alternative default container types defined. The longer type should

have (approximately) the double length of the shorter one, while the other dimensions are the same.

There must be a numbering system defined for the formal bays. For each formal bay, this numbering system tells the

bay number of the corresponding partial bays (command ON FORMAL). The figure above illustrates the formal bay

numbering.

Finally, the two short bays must be geometrically feasible:

s same y

s

same z, after taking into account possible lower containerss the x-distance is small enough so that both ends of the longcontainer are supported.

Whether a loading command gives rise to long or short containers is controlled by either


14/96



10 (92)


s giving an explicit container type

s giving a bay number belonging to the real or formal number set

The logic related to real/formal bay numbers in a loading command can be switched off (parameter RFMODE under

ADM).

The rules for this are explained in more detail in connection with loading.

2.10 List of quantities

The quantities used in the system are registered in the quantity standard and partially shared by other subsystems. The

following list gives an overview of the quantities used.

Available quantities

QUANTITY EXPLANATION

BAY bay number

ROW row number

TIER tier number

B1 start bay number

R1 start row number

T1 start tier number

BN last bay

RN last row number

TN last tier numberREFX,REFY,REFZ location of alignment point

CTP container type

CTP2 the alternative container type

FCODE fill colour (colour index)

LFCODE fill colour (logical fill code)

W container weight

WMIN container weight, minimum

WMAX container weight, maximum

WREL container weight, fraction

DH in hold (IH) or on deck (OD)

LXCG x-coord. of center of gravity, local

LYCG y-coord. of center of gravity, local

LZCG z-coord. of center of gravity, local

LXAL, LYAL, LZAL location of alignment point inside container

XCORR ... ZCORR correction to container position

XMIN...ZMAX extreme coordinates

WSTMAX allowed stack weight

DES descriptive text


15/96



11 (92)


NR number of container positions

NL number of containers loaded

PART name of arrangement containing a container

MASS loaded weight (note that W=weight of container)

XM, YM, ZM center of gravity of the load

VOLM volume of containers

CGX, CGY, CGZ center of gravity of the volume

These are the quantities relevant for the calculations. Other quantities can be added to container type definitions and load

definitions. These are available for output purposes and for doing selections. They must be declared in the configuration

parameters (command QNT/ADM).

3 Defining container arrangements

This chapter describes the definition of the components of container arrangements. At the end of the chapter, some

generally used syntaxes are presented, that also concern loading and output functions.

3.1 Defining a block

A block definition starts with command BLOCK, which is followed by a varying number of additional commands. The

definition is finished by command OK and optionally by a command not in the context (see command BLEXIT/ADM). In

addition to the definition commands, there are listing and plotting commands by which the partial results can be checked,

and the definition can therefore be done as an interactive process.

The shortest possible definition of a block contains the following information:

BLOCK name container-type

X x0 nx

Y y0 ny

Z z0 nz

The BLOCK command can contain options for specifying descriptive text and other properties, and records ADD,

REDUCT, SYM and REFLECT can be added with the effect described below.

The parts of the definition are described in more detail in the following paragraphs.

3.1.1 The BLOCK command

The BLOCK command starts the definition of a block.

The following parameters must always be given:

BLOCK name container-type

where

name:

in the name of block. In the data base, prefix CNTA* is added.

container-type:

The container type decides the geometric properties of the block and the default for loading. See also option T (transversal).


16/96



12 (92)


If the block is intended for loading of both short and long containers, an alternative container type is needed as presented

below.

The block can be placed in the bay/row/tier numbering system by giving the start numbers in the BLOCK command. All

three numbers can be given by the syntax .

(b,r,t): start bay row and tier

or separately by the options

B1=i: bay number of the first bay

R1=i: row number of the first row.

T1=i: tier number of the first tier

(As always, numbers given in commands are owner numbers). If not given, defaults are set so that bay=1, row=1 or 0

and tier=1 in the internal numbering system.

In addition to these parameters, the following optional parameters can be given:

T: transversal, apply the container dimensions so that x and y change place.

IH: defines the block to be in hold

OD: defines the block to be on deck default=from tier number

WST=w: maximum allowed stack weight, default=none

DES=text: the descriptive text

For the effect on row numbering by commands REFLECT and SYM, see below.

3.1.2 Block defined for mixed loading

If the block is intended to be used by both long and short containers, an alternative container type must be supplied:

BLOCK name short-type/long-type

for example

BLOCK B1 D20/D40

The long container type should be approximately twice the length of the short one (normally 20 feet/40 feet). This type

provides the default when loading long containers and its existence signals that pairs of adjacent stacks should be checked

for in order to give the potential locations of long containers. These pairs are determined according to the formal owner

numbering system (see ON FORMAL) with the additional requirement that the parts of the pair should be geometrically

compatible. For the parameters controlling this, see command PTOL in subtask ADM. The block can contain stacks not

belonging to any pair.

If the latter container type is shorter than the first one in the BLOCK command, their roles are reversed.

Mixed loading is not supported for transversal containers.

3.1.3 Defining the coordinates

The location of the block and the spacings are defined by commands X, Y and Z, each having the same form, here

represented by x:

X x0 nx

This form defines that the starting x coordinate is x0, and then follow nx intervals of the length implied by the givencontainer type, taking a possible option T into account.


17/96



13 (92)


x0 is at the start of the first bay, and the steps following are added in the direction of increasing bay numbers. Thus,

if the bay numbering is from fore to aft, x0 is at the upper x-limit of the block.

Additional spaces can be inserted the following way:

X x0 nx1 d1 nx2 d2 ...

where d1, d2 are additional steps in the x-direction and nx1, nx2 etc the number of container lengths between.

nx1 can be entered negative, meaning that the lower limit of the block is -nx1 container lengths behind x0.

The other coordinates are entered analogically. For y, there is the option C instead of y0, placing the first container centered

at the center line, for example:

Y C 4

This command places 4 containers so that the first one is centered at the center line.

In the z-direction there are no fixed locations except for the lowest one, because the height of a container is obtained

by adding the heights of those below, which need not have the default height. The locations given define the nominal

capacity and imply the total height of the stack, unless modified by option DH in the MODIFY command presented below.

Containers cannot be loaded over the total height defined this way (concerns also containers on deck). The spacings that

can be given between tiers represent gaps that are maintained for each tier regardless of the actual height of the loaded

container. See also command ZCORR below.

No other parts of the definition can be entered before the coordinates are defined. The coordinates can be changed by re-

entering the corresponding command, provided that none of the additional commands have been used.

The general syntaxes for referring to surfaces can be used, for example

Z #DECK1 4

However, there is no administration for handling possible subsequent changes, and updating of the block must be madeat the user's initiative.

If there is a repeated pattern in the container spacings, the following syntax can be used in the X and Y commands:

X ... m*(n1,d1,n2,d2,...) ...

This notation means that the syntax within parentheses is repeated m times. Note that the first item is a number of steps,

not an additional spacing d.

In the last repetition, the last spacing d is not used. If the definition continues, it must begin with a spacing.

Example:

X 10.5 3*(2,0.5) 0.8 2*(3,0.4)

giving the same as

X 10.5 2,0.5 2,0.5,2 0.8 3,0.4,3

3.1.4 Example

3.1.5 Adding vertical gaps with the ZCORR command

As an alternative to adding spacings to the Z command, gaps between tiers can be defined with the ZCORR command:

ZCORR d0,tier1,d1,tier2,...


18/96



14 (92)


Where d0,d1 etc are the spacings and tier1,tier2 etc define the places where the spacing changes. d0 is applied from the

start of the stack until tier1, below which the gap is d1 and so on. The following example illustrates ZCORR and the

equivalent Z command for a simple case:

BLOCK B1 D40 T1=1

...

Z 0 4

ZCORR 0 2 0.1 3 0.2

or

Z 0 2*(1,0.1) 0.2 2*(1,0.2)

giving

Simple block with spacings between tiers

If the block is loaded with lower containers than those defined in the BLOCK command, the number of tiers may be larger

than originally defined. The spacing defined for the highest tier is applied for the additional ones.

3.1.6 Removing locationsRemoving locations means marking part of the spaces within the initial matrix as not used.

Removing locations can be done by directly specifying bay, row and tier numbers, or by a geometric instruction, where

a forbidden area is designated with the aid of a surface.

Removing locations by explicit numbers is done by a command of the following form:

REDUCT bay-range row-range tier-range

Each range can be defined either by

n: a single value

n1...n2: numbers n1 to n2 inclusive

* the whole range

Examples:

REDUCT 1 1 1

Remove the position in the lower left corner

REDUCT 1...2 * 1

Remove the transversal lines at tier 1, bays 1 to 2.

For a more complete description of how to designate container positions, including graphic input, see below.

The geometric reduction is done in the form

REDUCT Y>surface


19/96



15 (92)


This means that container positions wholly or partly on the specified side of the surface shall be removed. Analogically,

one can use Y or Zsurface d

where the sign of d tells whether the translation is in the direction of the positive or negative half axis (negative in the

example below).

Example of geometric reduct

The reduction is done by making x-sections at the lower and upper end of each bay. If one wants to see what happens,

the option CHECK gives a graphic check, for example:

RED Y>HULL -0.5 CHECK

The graphic check shows the containers before and after the operation in combination with the sections used, as in the

figure above. This check is made separately for each bay.

When using the CHECK option, the projection is changed to X if not initially set. If the drawing has not been scaled in

advance, it is scaled according to the current block. If the graphic output is directed to the intermediate file, the result of

the check operation is organized as an independent drawing, where each bay is shown as a subdrawing. Note that any

previous graphic settings are replaced.

The geometric reduction is implemented in order to save manual work in the definition, but a permanent dependence on

the surface is not handled automatically. If the surface is changed in a way that affects the block, the definition must be

repeated.

The ADD command is analogical with the REDUCT command, but only explicit index ranges can be given. It can be

used to restore positions removed by REDUCT, but not to extend the initial range. It can be used if the geometrical reduct

removes undesired positions, or it can be practical to reduct a whole layer, and then add the positions intended to remain.

The figure below shows a block definition using the geometric reduct:

3.1.7 SYM and REFLECT

With the aid of commands SYM and REFLECT, the symmetry usually occurring about the center plane can be exploited.

The row numbering presented below concerns the internal numbering.

Command SYM makes the block symmetric by adding the reflected part about the center plane. Before entering the SYM

command, the block must either be entirely on the positive y side, or the first row may be centered at y=0. In the latter

case, this row will obtain number 0, otherwise the rows nearest the center plane get numbers -1 and 1. Correspondingly,

the initial starting row number must be 1 or 0.

The REFLECT command reflects the block about the center plane. The numbering is also 'reflected', i.e. the first and last

row numbers are interchanged and sign reversed.


20/96



16 (92)


These commands operate on the block as defined when the command is given, and the block can be subsequently modified

and, for instance, unsymmetric changes done. The following example shows two symmetric blocks, one of which is

transversal:

3.1.8 Defining stack specific exceptions

The stack weight, the location and the maximum height can be adjusted separately for given stacks, if the common value

is not useful. This is done with command MODIFY:

MODIFY bay-range row-range * symb=value,...

The range specification is done with the standard notation and specifies the stacks to be changed. The asterisk designates

the tier range which is irrelevant but included in the standard notation.

'symb' designates the quantity and 'value' its value. The following alternatives are available:

WST=w: allowed stack weight

REFX=x: new position in the x-direction. The symbol may be abbrieved to X. Similarly

REFY, REFZ.

DX=dx: change in the x-position. Similarly DY, DZ.

DH=dh: additional height above the highest container.

The height of the stack is by default calculated from the number of containers.

The option dh specifies an additional height that may be available if the stack is

loaded with containers of differing height.

3.1.9 Auxiliary commands under block definition

Information about the current block definition can be obtained with the following commands:

DES: same command DES on the main level. Without parameters, the current block

definition, as far as entered, is displayed.

LIST: lists data using the same LIST command as on the main level.

PLOT: same as the plot command on the main level. Commands SIZE, FILL COLOUR

and PROJECTION are available to support the PLOT command. Command PO is

also available, including option AUTO.

In the LIST and PLOT commands, the logic of plotting container loads is borrowed for separating places in the initial

matrix from those removed by REDUCT, so that places actually remaining are treated as loaded.

Using the standard LIST and PLOT commands as auxiliary output functions under BLOCK is a convenient way of

making a large set of output functions accessible, but it is not guaranteed that all options produce useful results.

3.1.10 Finishing the block definition

The block definition can be finished explicitly with command OK. Command SKIP finishes the definition and abandons

the result. Optionally, the block definition is finished when a command not known in the context is entered (see parameter

BLEXIT/ADM). Before the minimum block definition has been entered (commands X, Y and Z), it can be finished with

SKIP only.

3.2 Defining combined arrangements

Arrangements can be combined into larger sets with the COMBINE command:


21/96



17 (92)


COMBINE name part1 part2 ... DES=text

where 'name' is the name of the arrangement created

'part1', 'part2' etc are the names of the parts, which can be blocks or combinations of blocks.

'DES=text' is optional, and gives text used for documentary purposes.

Arrangements can be combined on several levels (i.e. the parts may also be combined). When read for use, the

arrangements are decomposed into the basic parts, and the intermediate levels will not be visible.

The blocks in the example ship and some combinations

The parts must not overlap each other, neither geometrically nor in the numbering. This is checked when a combined

arrangement is read for use and a warning is given telling the bay, row and tier numbers of the first place a violation of

this rule is encountered. The arrangement is accepted even if there are overlaps, but stacks containing common numbers

with a preceding one are removed.

3.3 Defining stacks under table calculation (pilot)

A container arrangement is internally treated as a set of stacks. This set of stacks can be presented as a table and treated

under table calculation. This possibility can be used as a pure output function, and it can also be used as a way of defining

container arrangements. In the latter possibility is presently implemented on pilot level only.

The table defining a container arrangement contains the following quantities, some of which are optional.

Quantities available for container arrangement


BAY bay number

ROW row number

T1 start tier number

TN highest tier number

CTP default container type

CL2 default long container type, default=empty

REFX x-coordinate of reference point

REFY y-coordinate of reference point

REFZ z-coordinate of reference point

ORNT orientation (L or T, default=L)

LXAL location of longitudinal alignment point measured fromthe lower limit (default 0)

LYAL,LZAL similarly for y, z


22/96



18 (92)


XMIN x-coordinate of lower limit (default=calculated)

XMAX...ZMAZ similarly for the other limits

Bay row and tier numbers are given as owner numbers. If the columns XMIN...ZMAX are present all values within the

columns must be given.

When used for defining arrangements, note the following:

The name rule is the same as for arrangements defined by other means, i.e. CNTA*name. Thus, the catalog will not show

directly what arrangements are defined under table calculation and what are defined otherwise. Arrangements defined as

tables can be separated by adding the selection criterion TYPE=19000.

An arrangement not defined as a table cannot be read directly under table calculation. However, in the main task of CL,

the command CNTA name; reads the given arrangement, converts it to a table and enters table calculation. If the original

definition was not as a table, the name is modified by appending .T.

3.4 Designating subsets of bays, rows and tiers

In various definition, loading and output functions, there is the need to specify ranges of bays, rows and tiers, for which

the following alternatives are provided.

When doing the specification numerically, the form is

(bay-range row-range tier-range)

where each one of the ranges can be specified in one of the forms:

n: single index

n1...n2: range from n1 to n2 (inclusive)

* the whole range

The numbers represent owner numbers. A range is interpreted so that the containers corresponding to the upper and lower

limit are taken and all between them in the internal numbering.

The parentheses belong to the syntax. They are optional in commands specifically designed for use with the range selection

(ADD, RED, MOD under block definition, ADD, RED and CHG commands of loading), but needed when used as options

in subset selections.

The ranges can also be given graphically, if there is a suitable drawing available. The drawing must be made in an

orthogonal projection, and the projection, scaling or plot options must be the same as when the drawing was made.

The bay, row or tier range is shown by pointing at the lower left and upper right containers in the range selected. In the

viewing direction, one cannot show the range, and it has to be entered numerically as the first item, using the syntaxes

above. It can be omitted if the whole range is selected.

Example: In an ADD command, a range of bays and tiers is shown in a side view, selecting rows 1...4 numerically. The

following is entered from the keyboard (note the colon):

ADD 1...4 :

then the lower left and upper right corners of the range are shown on the screen.

The ordinary data echo will show the graphic input as the coordinates pointed at, and an additional data echo will be

produced showing the input as interpreted to bay row and tier numbers.

The following unofficial service is available for arrangement plans if the name of the part used in the input has the form

BAY nr or BAY n1-n2

and similarly for ROW or TIER. When using such a plan part for graphic input, the range implied by the plan name isused in the result.


23/96



19 (92)


Formal owner numbers can be used for designating ranges, which will include both partial bays corresponding to the

formal number. In loading commands, additional interpretations may be done as presented later.

3.5 Defining arbitrary subsets

The most general subset selection is formed by the a combination of the following components:

brt-range special-options location quantity-criterion

The partial criteria are formed as follows:

brt-range: the syntax presented above, including parentheses.

special-options:

IH: only containers in hold

OD: only containers on deck

L: only loaded container positions

U: only unloaded container positions

A: both loaded and unloaded positions type (the name of a container type) only

containers of the given type

PART=name: containers in a given partial arrangement

location:

A location is given in the form axis=q or axis=(q1,q2), and selects the containers at least partly inside the given range.

Examples:

Y=0

X=(0,20)

quantity-criterion:

Quantity-criterion means a selection criterion formed using the available quantities and the general selection syntax

(see !EXPL SEL/GEN). The standard quantities are always available, in addition there may be own additional ones (see

command QNT in subtask ADM).

TYPE=T1

W=0...2

the quantities BAY, ROW and TIER are also available and provide an alternative way of selecting number ranges.However, the effect may be different than using the range syntax. The difference can best be understood by taking into

account that this criterion is in all respects similar with a criterion involving, for instance, the container weight.

As an example of several criteria combined, the following syntax selects all loaded but empty containers between bay

20 and 32:

(20...32 * *) L WREL=0

The dummy command SEL in the main task gives access to the explanation of the selection syntax (use !EXPL SEL).

Interpreting the general selection syntax is an own function. This is the reason for the need to separate this syntax from

others, for example in the PLOT command, where the distinction with respect to the plot options may feel unnatural. In

commands the keyword SEL is used for separating the selection syntax.


24/96



20 (92)


Examples of selections used with the DRW command

4 Auxiliary definitions

This chapter presents the auxiliary definitions, i.e. container types, owner numbering and other definitions not producing

container objects.

4.1 Definitions related to the owner numbering

The following subjects are related to the owner numbering:

s the actual numbering, i.e. the set of owner numbers

s numbering rule for real/formal bays

s number range of containers in hold/on deck

Command ON defines handles all definitions concerning the owner numbering, including some administrative functions.

4.1.1 Defining the numbering

The main part, the actual owner numbering, is defined separately for the three axes in the form:

ON axis i0 n1, n2, n3 ...

where

axis: X, Y or Z; defines the direction concerned

i0: first index defined (bay if axis=x etc)

n1,n2... owner number for index i0, i0+1, ....

If owner numbers are evenly spaced, the normal series syntax can be used.

Example:

ON X 1 3 6 (8 24 4) 26

defining owner numbers 3,6,8,12,16,20,24 and 26 for bays 1 to 8.

With option LIST, a list of corresponding user and owner numbers is printed for a given axis, for example ON X LIST.

For the example above, the result would be

X 1 2 3 4 5 6 7 8

ON 3 6 8 12 16 20 24 26


25/96



21 (92)


Make sure that owner numbers are defined for the whole range to be used.

Unused ranges in the internal numbering have no effect on other functions than plotting with the NG option, where the

internal numbering decides the coordinates plotted.

Without a complete owner numbering system, only some administrative functions are available.

4.1.2 Defining the formal owner numbers

For mixed loading of long and short containers, the formal owner numbering system controlling the location of long

containers is defined by the ON FORMAL command:

ON FORMAL p11/f1/p12 p21/f2/p22 ...

or

ON FORMAL ISO

The first form defines explicitly the relation between the real and formal bay numbers. Each triple

p1/f/p2

specifies that the pair of bays p1 and p2 together forms the formal bay f. p1 and p2 must be two consecutive bays.

The second form specifies the ISO mode numbering, which is equivalent with

ON FORMAL 3/4/5 7/8/9 11/12/13 ...

within the range of covered by the owner numbering system.

This definition cannot be entered until the bay numbering has been defined. When entering the definition, it is checked

that it is consistent with the bay numbering. This check is not repeated if the bay numbering is subsequently changed.

4.1.3 Owner numbering range separating containers in hold/on deck

For deciding whether containers (or more precisely stacks) are on deck or in hold, a default can be defined via the owner

numbering system. The command

ON INHOLD t1 t2

defines a tier range such that tier numbers from t1 to t2 (inclusively) are considered being in hold, while others are on deck.

4.1.4 Example

4.1.5 Copying the owner numbering system

The owner numbering can be copied from another project or version in the form

ON FROM A (copy from version A) or

ON FROM A/P1234 (copy from version A in project P1234)

The current owner numbering in the system can be stored in the system data base by the command

ON SAVE

It can copied for use in the current project by the command:

ON FROM SYSDB

If no owner numbering system has been stored in the project, the one in the system data base is used.


26/96



22 (92)


4.2 Various parameters (subtask ADM)

A number of properties of the system can be adapted to the local needs. The definitions are collected as subtask ADM

and the result is stored in a description named CL*CONTROL. When entering container loading, this description is read

from the project data base if available, else from the system data base. If none is found, built-in defaults are used.

Some of the parameters presented here belong to functions that will be presented in more detail in their respective contexts.

4.2.1 Bay numbering convention

Whether the bay numbering goes from fore to aft of or vice versa can be defined in the configuration parameters. The

default is fetched from the installation parameters (see document MN.2). The possibility to use the reference system (task

REF) is still available but is considered redundant and replaced by the own facilities of CL.

The bay numbering is defined by the command

BAYNR FORE bay numbering forward (lower numbers in the aftbody)

BAYNR AFT bay numbering aft (higher numbers in the aftbody)

Objects defined with a different bay numbering convention than the one currently valid will work incorrectly.

4.2.2 Source of container types

The name of the table providing the properties of container types is by default STD. Another name can be defined by

command CT.

4.2.3 Defining additional quantities

An overview of the standard quantities used in the system is presented in chapter 1 and more closely in their respective

contexts. These quantities are automatically available in the functions they are intended for. Additional quantities can be

introduced as properties of containers. Their values can be given via the container type definitions or in the container

loading commands.

In order to make the management of quantities easier and to allow for error checks, the additional quantities must be

declared with the QNT command:

QNT symb1 symb2 ...

where symb1, symb2 ... are the symbols used in the quantity standard.

4.2.4 Check mode

When loading containers, various checks can be done regarding matching container dimensions, correct loading of the

container below etc. By default, the checks are done with each loading command and a violating loading command is not

carried out. The options are to suppress the checks or to make the messages only, and these are set with the command ERM.

The mode is expressed by a combination of the following characters:

R: report error directly when loading (default)

N: do not report errors directly

S: no not carry out a loading causing the error (default)A: accept a container in spite of the error


27/96



23 (92)


4.2.5 Criterion for separating long and short containers

By default, lengths under 9m (appr. 30 feet) are considered short and lengths over 9 m long. This limit value can be

changed by command LCR.

When executing loading commands, long container places are (without error message) disregarded when loading short

containers and vice versa.

4.2.6 Criterion for accepting differing container dimensions

When it is checked whether a container matches the dimensions of the location designated, two factors are used:

If the container is shorter (in the x- or y-directions) by a factor LT1 it is considered too short. If the container is longer

by a factor LT2, it is considered too long.

Note the difference with respect to the preceding parameter, which is used for interpreting the intention of a loadingcommand.

4.2.7 Height tolerance for long containers

When loading a long container, it is checked that the containers below are at the same height by a tolerance ZTOL. The

built-in default is 0.1 m.

4.2.8 Interpretation of real/formal bay numbers in loading commands

As presented in connection with mixed loading of long and short containers, the way the bay number is given (real or

formal) may affect the interpretation of a loading command. If one prefers to control this aspect by using explicit container

types only, the real/formal interpretation can be switched off with command RFMODE. If RFMODE=OFF, bay numbersaffect the range only. The built-in default is ON.

4.2.9 Exit from block definitions

It is possible to select whether a block definition is considered finished when a command not belonging to the context is

entered, or whether an explicit OK or SKIP command is needed. The selection is done with the command BLEXIT, with

parameter AUTO or MANUAL. The built-in default is MANUAL.

4.3 Default template

When using the plot option MI (mark inside), a template can be used for controlling the layout instead of the built-in logic.

A default template can be given with the command TEMPL. The built-in default is to use no template.

4.4 Default substance for LCA NEW

In the main task of loading conditions (LD), a new container load can be created and added to the loading condition

with command LCA NEW. The substance recorded for the load (quantity LOAD) is by default CONT, i.e. the equivalent

MASS command is

MASS CONT name

This default can be changed with the command SUBS.

4.5 Defining container typesContainer types are defined under table calculation as tables where each line defines a container type. The tables have the

prefix CNTT*. The standard columns are listed below, and others can be added as needed. All table calculation facilities


28/96



24 (92)


are available, and for example, combined tables can be used for collecting data from several sources. Command CNTT

enters table calculation with subject (=table prefix) set to CNTT.

Commands for container type definition


CT identification of container type (key)

DES descriptive text (default=empty)

W default weight

WMIN minimum weight(default=0)

WMAX maximum weight(default=W)

CTLENX spacing in x

LENY spacing in y

LENZ spacing in z

LXCG local center of gravity (default LENX/2)

LYCG local center of gravity (default LENY/2)

LZCG local center of gravity (default LENZ/2)

LXAL length from aft end to alignment point (default 0)

LYAL length from -yend to alignment point (default 0)

LZAL length from bottom to alignment point (default 0)

FCODE fill code (integer)

LFCODE logical fill code, alternative to FCODE

FIG figure (for plot option FILL=CT)

The columns having a default can be omitted. FCODE, LFCODE and FIG can be omitted if the corresponding services

are not used (see plot options FIG and FILL). Other quantities can be added as desired. These are available in various

output functions, but are not taken into account in the calculations.

A model table named CNTT*MODEL is delivered with the system, providing the table structure and sample definitions.

When running the system, there is a single table of type definitions used. The built-default for the name of it is STD, but

it can be changed under task ADM.

When starting container loading, CL makes an own copy of the container type table. If the table is changed, this copy

must be updated, either by returning to task level or by using the command RESET !, which will return container

loading to its initial state. Any container objects in the run time memory will be removed.

4.6 Templates for controlling texts inside containers

When plotting containers, information in text form can be written inside the containers (plot option MI, mark inside). The

layout of these texts can be controlled with templates giving the position and text height relative to the container contour.

A template is defined as a macro, where the relevant information is expressed by drawing commands as in the task DR,

and a template can be used as drawing macro for showing the result. The name of the macro is given as parameter to

Container Loading (CL)

Documents