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;
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.
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.
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.
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
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.
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;