Page 1 of 2

PROCESSES
One thing which is fundamental to MOSES is the concept of a process. Whenever MOSES performs a
simulation, the results are stored in the database by the process name. The name it uses is the "current
one", or the last one which was referenced. To alter the "current one", one should issue the following
command:
&DESCRIBE PROCESS, PRCNAM, -OPTIONS

and the only option is:

-EVENTS

When an &DESCRIBE PROCESS command is encountered, and the name for the specified process
is not already defined in the database, it will be added to the database with the name specified.
MOSES will then set the "current" process to be the one specified.
Here, by simulation results, we mean the initial and current configurations, the events for the process,
the activity status of the connections, the lengths of each mooring line, the load group multipliers, and
the load set multipliers. In other words, all events of a simulation, the initial conditions, and any of the
data defined by &COMPARTMENT, &CMP_BAL, &APPLY and &CONNECTOR commands
is stored by process name. By altering the process name, one can actually consider several different
connection situations using the same model. This is important, since one can also perform a structural
analysis for several processes with the same factored stiffness matrix.
Two types of data are stored by process name: constants and data which depends upon event. Most of
the data mentioned above are constants, and only one value will be associated with a process. The
data which is stored by event is the configuration, the forces acting on the bodies, and any results of
the &COMPARTMENT, &CMP_BAL, &APPLY and &CONNECTOR commands. The
constants are the results of the &ENV command. Thus, a given process can have only a single
environment.
When the process name is altered, the new process will have all of the same settings and initial
condition as the situation immediately before the name was changed, but the results of the previous
simulations will appear to be "lost". They are, however, not really lost. To recover them, one should
issue another &DESCRIBE PROCESS command to change the current process back to the name
under which the results are stored. Thus, the process concept allows one to have many different sets
of results available for further processing.
If one wishes to have the events of the previous process available in the new one, he can specify the
-EVENTS option when he created the process. Now, the new process is a true copy of the old
process, and it can be altered as desired.
Most processes will have events defined by either a time domain simulation (the results of a TDOM
or LAUNCH command) or an upending sequence. At the conclusion of a time domain or launch
simulation, MOSES will revert to the situation at the beginning. Thus, issuing &STATUS after a time
domain simulation will produce the same result as issuing it before the simulation. In some cases,
however, one may wish to construct a series of events which correspond to a set of equilibrium

Page 2 of 2

configurations with different ballast conditions. This can be accomplished by computing an

equilibrium configuration, and storing the results with a given event number via the command:
&EVENT_STORE, EVE_NUMBER

The results of this "simulation" can be post-processed as any other simulation in the Process PostProcessing Menu. Notice, if this command is used when a process already exists (a launch, time
domain, upend, etc.) then it will corrupt the existing data.
The string function which returns data for processes is:
&PROCESS(ACTION)

and ACTION must be either: PROCESS, C_EVENT, MAX_EVENT, or MIN_EVENT. Which

return the process name, the current event, the maximum event and the minimum event for the current
process.