PROCESSES 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 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 Post-Processing 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.