next up previous contents
Next: Output Up: Overview Previous: Overview   Contents

Input File Structure

The input is divided in blocks. This is a consequence of the fact that almost every module of the code needs data and each module is responsible for its data input. So it is natural to make each module read and interpret its data starting from the input phase.

Every statement (or `card') follows the syntax:

    <card> ::= <description> [ : <arglist> ] ;
<arglist> is a(n optional) list of arguments, that is driven by the <description> that identifies the card. The keyword can be made of multiple words separated by spaces or tabs; the extra spaces are skipped1.1, and the match is case insensitive. The arguments are usually separated by commas1.2. A semicolon ends the card.

Many cards allow extra arguments that may assume default values if not supplied by the user. Usually these arguments are at the end of the card and must follow some rules. A check for the existence of extra args is made, and they are usually read in a fixed sequence. Optional args are usually prefixed by a keyword.

When structured arguments like matrices, vectors, or drive callers are expected, they are parsed by dedicated functions. Anyway, the structured data always follows the rules of the general data. Few exceptions are present, and will be eliminated soon. Every data block is surrounded by the control statements begin and end:

    begin: <block_name> ;
        ...
    end: <block_name> ;
The block sequence is:
    begin: data;
        # select a problem
    end: data;

    begin: <problem>;
        # problem data
    end: <problem>;

    begin: control data;
        # model control data
    end: control data;

    begin: nodes;
        # nodes data
    end: nodes;

    # note: optional
    begin: drivers;
        # special drivers data
    end: drivers;

    begin: elements;
        # elements data
    end: elements;
The drivers block is optional.

The Schur solver allows an extra block after that of the elements:

    # note: optional; only allowed when Schur solver is used
    begin: parallel;
        # parallel data
    end: parallel;
where data specific to the partitioning and the connectivity of the Schur solver is provided. This is yet undocumented, and will likely be described in a future chapter.

Chapter 2 describes the basic and aggregate data structures that concur in building up the cards. Chapter 3 describes problem selection options. Chapter 4 describes the cards dedicated to the specification of the parameters of the simulation and of the selected integration scheme. Chapter 5 describes the model control data. Chapter 6 describes the cards related to the input of nodes. Nodes come first because they are the elementary blocks of the connectivity graph of the model, so historically they had to be defined before any element could be introduced. Chapter 7 describes the cards related to special drivers. Chapter 8 describes the cards related to the input of elements.


next up previous contents
Next: Output Up: Overview Previous: Overview   Contents
MBDyn: MultiBody Dynamics Software
Document version: 1.3.7
Last update: Tue Mar 17, 2009
Maintained by mbdyn@aero.polimi.it