THE MOSES MODEL THE MOSES MODEL

MOSES operates using a database philosophy. In other words, the commands to the program are instructions to perform some operation upon the information which currently resides within the database. Before one can obtain meaningful results, he must have a database upon which to operate, i.e. a model of the basic system must be defined for the program. This model is defined via commands in a modeling language described below. Although the distinction is somewhat arbitrary, it helps to think of the model as being composed of two different types of data: some which remain constant and some which change as the analysis proceeds. The constant part is the "basic" model and the remainder are settings which normally evolve. For example, the physical description of a barge will normally remain constant throughout an analysis, but the ballast configuration, the draft, trim, and cargo normally will not. Another way of viewing this difference is that the "constant" model normally consists of a relatively large amount of data, while the variable part is much smaller.

MOSES has two different menus for defining the constant part of the model: the INMODEL menu and the MEDIT menu. It was originally intended for the user to "read" in a model, and then "edit" to add some additional features or fix some mistakes. The situation has evolved so that now it is not necessary to first read in the model. One can define it in its entirety from the MEDIT menu. A small price must be paid, however. In the INMODEL menu, it is assumed that one starts with nothing and ends with a complete model. This allows MOSES to defer some associations until it completes reading the model. In the MEDIT menu, the assumption is that a model already exists and thus, it must be kept up to date. The difference in philosophy requires that in MEDIT, a piece of data must have been previously defined before it can be referenced. Also, defining a model with INMODEL is computationally more efficient.

Data defined via the INMODEL menu is input from the "INPUT" channel (a file root.dat) and the process is initiated with the command:


     INMODEL,   -OPTIONS

There are two options available here:


     -OFFSET

     -PROCESS, PRC_NAME

Here, -OFFSET will cause local axial offsets to be computed at the ends of any tubular member connected to a tubular joint, and -PROCESS allows setting the current process to be PRC_NAME after the INMODEL is complete. After an INMODEL command has been issued, it should be re-issued only if one wishes to substantially alter the model. Doing so will result in all previous results being deleted from the database. If you want to have a second INMODEL, a &DEVICE -AUXIN command must be re-issued.

During the INMODEL process, you can use two commands:


     USE_VES, VES_NAME

or


     USE_MAC, MAC_NAME

to load a predefined vessel model or macro. When one of these is issued, MOSES will look in a set of predefined places to see if it can find the specified name. By default, the order will be the current directory, the /ultra/data/local directory, and then the places where MOSES supplied vessel models and macros are located. You can use the command,


     &PATH, TYPE, ADDITIONS

to add places to be checked. Here, TYPE must be either VESSEL or MACRO and it defines which path is being altered. ADDITIONS is simply a list of new places to check. When this is done, the search order will be the current directory, the places specified by ADDITIONS, and then the previous places.

Defining or altering a model with MEDIT is initiated with the command:


     MEDIT,

and is exited via an


     END_MEDIT

command. All of the valid INMODEL commands are valid during MEDIT as well as several additional ones. In general, the extra commands are those which delete things, change things, and define connections. The restriction to MEDIT will be made explicit when these commands are defined.

Within either of these menus, the model is defined with a set of commands defining the primitives upon which MOSES will operate. Each of these will be discussed in detail below. During this discussion, we will also define the commands which alter the settings of some of the primitives. It should be remembered that even though one can issue these commands within a model defining menu (they are internal commands), it normally does not make sense to alter something until it has been completely defined. Also, remember that MOSES was designed to be an integrated program for both simulating a process and performing a stress analysis of the system during the process. To accomplish this integration, the model which one prepares for MOSES is conceptually different than one would prepare for a program designed for either of the two tasks alone. Thus, a model for MOSES is not simply a model of the structure of the system. Instead, it is a model from which MOSES can compute not only the stiffness of the system, but also the loads which act on the system.

The basic idea behind the modeling language is to convey as much of the needed information as possible with the minimum amount of description. Thus we have modeling commands which define the "physical" components of the system instead of defining only some aspects of it. Of course, one must have a method of overriding the built-in assumptions, and in some cases, there is no easy way to model what one desires.

The basic ingredients for performing a simulation are bodies which are considered rigid, and composed of parts. Bodies are connected with special elements called connectors. A part is the smallest entity upon which a structural analysis can be performed. In essence, a part is simply a named, connected subset of the model.

Most properties of the system are described by the attributes of the parts. In other words, every attribute of the system must be an attribute of some part of the system. Therefore, everything except bodies belong to some part. There is a special part which does not belong to any body, and it is in this part that elements which connect bodies reside. These elements, called connectors, are quite important. They define both the boundary conditions for a stress analysis, and the constraints on the bodies for a simulation. To avoid confusion, elements which connect parts (elements which are connected to nodes in different parts) must belong to a part with a type of PCONNECT. Thus, the only elements which can span parts are restraints, connectors or PCONNECTors. A PCONNECT part should not have any nodes which belong to it.

The geometry of the model is defined by quantities called points. Points all have names beginning with a *. The subset of the points to which structural elements are connected are called nodes. All other points are associated with some node. Both points and nodes are defined in a coordinate system which belongs to the part.

The structural attributes of the model are defined by a set of beam and generalized plate elements which connect the nodes. Since there are many elements in a structure which have common properties, MOSES allows one to associate a name with a set of properties. This set of properties is then associated with the applicable elements by specifying the name on the element definition command. The name associated with a set of properties is called the class name of the properties, and it must begin with the character ~. The concept of class is important in MOSES since it is used not only for defining properties, but as a way of associating elements for post-processing and redesign.

The remainder of the attributes of a part are used to compute the loads which act upon it. In general, there are four sources of loads which MOSES can consider: applied, inertia, wind, and water. Notice that there is a conceptual difference between the applied loads and the others in that the other loads arise due to the interaction of the system with its environment. Thus, for applied loads, one models the loads themselves, while for the other classes, he must model the physical attributes which give rise to the loads.

Of these sources of loads, the system/sea interaction loads are by far the most complicated. In fact, we will distinguish six different types of structure/sea loads: buoyancy, added mass, radiation damping, viscous drag, linear wave excitation, and wave drift force. To allow flexibility, MOSES employs three hydrodynamic theories: Strip Theory, Three Dimensional Diffraction Theory, and Morison's Equation. When Morison's Equation is used, viscous drag is computed, but no radiation damping. The other hydrodynamic theories, however, consider no viscous damping, but only radiation damping. Thus, if one wishes to add some viscous drag to a system using a diffraction hydrodynamic theory, he needs to define some Morison's Equation load attributes.

The primary objective of the MOSES modeling language is to minimize the number of additional load attributes which need to be defined. To ease the definition process MOSES employs two additional concepts: the load group, and the compartment. Compartments are used to define the loads associated with "vessel like" attributes, and load groups are used to define loads associated with "structural like" attributes. Compartments serve to define the loads which arise due to the interaction of the bodies with the water for things which cannot be adequately modeled with Morison's Equation. There are two classes of compartments: interior and exterior. The exterior compartments define the exterior of a body and the interior ones define subdivisions which may or may not be open to the sea. Interior compartments can also be ballasted, in which case, compartments define a part of the inertia of the system.

Since all of the model information in MOSES is stored by name, the names are of importance in conveying to others what type of data is associated with the name. Unfortunately, the limited space of a name often does not allow one to adequately describe things. Thus, all of the modeling commands accept two options -NOTE and -TAG. The first of these allows one to attach a 60 character description of the data. This is a peculiar option in that it must be specified by all five characters. One can then use an &STATUS command to report the name and the notes for selected types of data. No quotes are needed for this option to include blank spaces, but if you have a -, it must be escaped if it is not followed by a blank. The -TAG options allows one to define an eight character "tag" to the name. Tags can be used to select reports for a given class of data to only that which matches its tag. If a tag is not specified, then one which is the same as the name will be given.

There are several commands in MOSES which exports portions of the model: &EMIT, &EXPORT, &CONVERT, E_TOTAL, and E_PRESSURE. Each of these commands also accepts the -NOTE option. When the exported file is written, the TITLE, SUBTITLE, and the NOTE will be included in the exported file if they are not blank.

One important aspect of the MOSES language is the string function. Most of the string functions discussed previously performed simple tasks such as arithmetic. There is another class of function which "returns" information about the current model or configuration. These are extremely useful in automating certain tasks. Each of these functions will be discussed later, but one which is useful in generating loops is:


     &NAMES(QUANT, SELE)

which returns the names of database quantities. Here, QUANT is the category for which names is desired. This valid categories is defined in the section "Obtaining the Names of Quantities", or you can obtain it by issuing either:

     &NAMES NAMES

or

     &STATUS NAMES

The &STATUS gives not only the list of names, but also a brief description. The behavior here depends on if SELE is omitted. If specified, then all names of QUANT which match SELE will be returned. If SELE is not specified, then most of the time, all of the names for QUANT will be returned to the command line. For PARTS, ELEMENTS, COMPARTMENTS, LOAD GROUPS, POINTS, and NODES however, the results are returned only for the current body and part.

With the power of the MOSES language, users often want to emit the commands used to build a model to a separate file for later use. This can be achieved elegantly using &EMIT, which has the following syntax:


     &EMIT, -OPTIONS

where the options are:


     -BEGIN

     -BOX, COMMENTS

     -LINE, COMMENTS

     -END

     -SACS

Perhaps the best way to illustrate this command is with the following example:

     &EMIT -BEGIN
     &DESCRIBE BODY TEST
     &EMIT -BOX This is the main hull model
     PGEN HULL -CS_WIND 1 1 1 -CS_CURRENT 1 1 1
     PLANE 0 50 100 150 200 250 300 -RECT 0 20 90
     END
     &EMIT -LINE Cargo Wind Area
     PGEN CARGO -LOCATION 0 0 20 -CS_WIND 1 1 1
     PLANE 100 150 200 -RECT 0 40 100
     END
     &EMIT -END

The -BEGIN option causes MOSES to declare the units being used. The -BOX and -LINE options simply add comments to the resulting file, which is useful for documentation of a model. The -BOX options places a box around the comments, while the -LINE option places the comments at the end of a line. The -END option stops the emit process, and returns MOSES to parsing modeling commands as normal. If the program finishes without using &EMIT -END, MOSES will automatically include this command as part of closing all files.

The commands to be emitted must come through the input channel, typically the root.dat file. None of the modeling commands following &EMIT will be parsed as they normally would. Instead, the modeling commands, complete with comments, are placed in the post processing output file, typically root.ppo.

Finally, the option -SACS facilitates the emitting of SACS loadcases to the root.ppo file. Successful use of this option to emit loadcases is a three step process as follows:

Please note that the &EMIT -SACS command is meant to be used only with converted SACS models. The command must come before INMODEL in the SACS conversion .cif file so that MOSES will know to remember the proper SACS names for model data. Later MOSES will be able to emit SACS load cards on those model elements with their proper SACS names. To instruct MOSES to do so, the &EMIT command with -SACS option must be exercised again within the analysis .cif file. At that point, any load cases emitted through the standard LCASE command will be emitted as SACS cards.