In the last two chapters we analyzed and interpreted the whole input file for Problem 1, "free_falling_body.mbd" (shown again in Code 1). This chapter presents some techniques to make input files more readable. Because the format of MBDyn input is fairly flexible, with a little ingenuity we can write a readable and effective input file. Making an input file readable is important when constructing a complex model.

# free_falling_body.mbd

begin: data;
   problem: initial value;
end: data;
 
begin: initial value;
   initial time: 0.;
   final time: 1.;
   time step: 1.e-3;
   max iterations: 10;
   tolerance: 1.e-6;
end: initial value;
 
begin: control data;
   structural nodes: 1;
   rigid bodies: 1;
   gravity;
end: control data;
 
begin: nodes;
   structural: 1, dynamic, null, eye, 0., 3., 0., null;
end: nodes;
 
begin: elements;
   body: 1, 1, 1., null, eye;
   gravity: 0., 0., -1., const, 9.81;
end: elements;

Use spaces

Since MBDyn ignores spaces, we can use spaces at will. If we use spaces effectively, for example to indent lines logically or to align numbers, we can make a code clean and comprehensible.

Use line breaks

MBDyn allows us to break lines almost anywhere. If we break lines skillfully and reduce the amount of information in each line, a code becomes more readable.

Use comments

MBDyn allows us to insert comments anywhere even in the middle of a statement. If we use comments together with line breaks, we can make even a long statement easily-comprehensible.

Use variables

We can define a variable using a "set" card. The set card can be used anywhere in the input file even outside of a block. For example, the next statement creates a real variable "Vy0" and assigns "3" to it.

   set: real Vy0 = 3.;

A variable defined like this can be treated in the same way as a number. Since variables are useful to change values collectively, it is a good idea to make a value that is likely to be changed later a variable.

There is another advantage of using variables. A variable makes us possible to handle a number by name and to write a more descriptive code. For example, when we need to write a number for the area of a circle, if we write it as

   pi*Radius^2

where "Radius" is a variable, it is very clear what the number is about. In a similar manner, if we make labels for nodes and elements variables with self-explanatory names, management of labels becomes much easier.

Modified input file

Code 1 was modified to Code 2 using the techniques described above. How about it? Isn't Code 2 more readable than Code 1? From here on, we write input files in the style of Code 2. Of course, this is not the only and best style and you may want to seek out a better style for yourself.

# free_falling_body_E.mbd

begin: data;
   problem: initial value;
end: data;
 
begin: initial value;
   initial time:   0.;
   final time:     1.;
   time step:      1.e-3;
   max iterations: 10;
   tolerance:      1.e-6;
end: initial value;
 
begin: control data;
   structural nodes: 1;
   rigid bodies:     1;
   gravity;
end: control data;

# Design Variables
set: real Vy0 = 3.; #[m/s] Initial horizontal speed
set: real M   = 1.; #[kg]  Mass of the ball

# Node Labels
set: integer Node_Ball = 1;

# Body Labels
set: integer Body_Ball = 1;
 
begin: nodes;
   structural: Node_Ball, dynamic,
      null,        # absolute position
      eye,         # absolute orientation
      0., Vy0, 0., # absolute velocity
      null;        # absolute angular velocity
      
end: nodes;
 
begin: elements;
   body: Body_Ball, Node_Ball,
      M,    # mass
      null, # relative center of mass
      eye;  # inertia matrix
      
   gravity: 0., 0., -1., const, 9.81;
   
end: elements;