<card> ::= skip initial joint assembly ;
This directive inhibits the execution of the initial joint assembly.
Note that for a model to behave correctly, the initial joint assembly
should always succeed.
A correct model succeeds with 0 iterations, i.e. it intrinsically
satisfies the constraints from the beginning.
However, the initial joint assembly is more than a simple compliance
test; it represents a static preprocessor for models.
See the directives use in Section 5.1.1
and initial stiffness in Section 5.1.1
for more details on performing appropriate initial joint assembly.
<card> ::= use : <item_list> , in assembly ;
<item_list> ::= <item> [ , <item_list> ]
<item> ::= { rigid bodies
| gravity
| forces
| beams
| aerodynamic elements
| loadable elements }
joints are used by default, and cannot be added to the list.
beams are used by default, too, but can be added to the list
essentially for backwards compatibility.
<card> ::= initial stiffness : <position_stiffness>
[ , <velocity_stiffness> ] ;
This directive affects the stiffness of the dummy springs that constrain
the position and the orientation (<position_stiffness>)
and the linear and angular velocity (<velocity_stiffness>)
of the structural nodes (either static or dynamic)
during the initial assembly; the default is 1.0 for both.
Note that each node can use a specific value;
see Section 6.1 for details.
<card> ::= omega rotates : { yes | no } ;
Sets whether the imposed angular velocity should be considered attached
to the node or fixed in the global system during the initial assembly.
<card> ::= tolerance : <tolerance> ;
The tolerance that applies to the initial joint assembly;
this tolerance is used to test the norm 2 of the residual,
because it is very important, for a correct start of the simulation,
that the algebraic constraints be satisfied as much as possible.
The alternate statement initial tolerance is tolerated
for backwards compatibility.
<card> ::= max iterations : <max_iterations> ;
The number of iterations that are allowed during the initial assembly.
The alternate statement max initial iterations is tolerated
for backwards compatibility.
<card> ::= title : " <simulation_title> " ;
<card> ::= print : {
dof stats |
dof description |
equation description |
description |
element connection |
node connection |
connection |
all |
none
} [ , ... ] ;
print: dof stats;
print: dof description;
is equivalent to
print: dof stats, dof description;
while the statement
print: none;
disables all.
<card> ::= make restart file
[ : { iterations , <iterations_between_restarts>
| time , <time_between_restarts> } ] ;
The default (no arguments) is to make the restart file only at the end of
the simulation.
<card> ::= select timeout , <timeout> ;
exit after <timeout> minutes when waiting for connections
on stream drives or stream output elements.
By default, no timeout is used, so select waits forever.
<card> ::= default output : <output_list> ;
<output_list> ::= { all | none | <output_item> }
[ , <output_list> ]
<output_item> ::=
{ reference frames
| abstract nodes
| electric nodes
| hydraulic nodes
| structural nodes [ | accelerations ]
| aerodynamic elements
| air properties
| beams
| electric elements
| forces
| genels
| gravity
| hydraulic elements
| joints
| rigid bodies
| induced velocity elements }
Here the default output flag for a type of node or element can be set.
It can be overridden for each entity either when it is created or later,
for entity aggregates, in each entity module, by means of the output
directive for
nodes
and
elements.
Special values are:
begin: control data;
# ...
# disable all except structural nodes
default output: none, structural nodes;
# ...
end: control data;
<card> ::= output frequency: <steps> ;
Despite the misleading name, this statement causes output to be produced
every <steps> time steps, starting from the initial time.
A more general functionality is now provided by the output meter
statement (Section 5.1.2).
<card> ::= output meter: (DriveCaller)<meter> ;
The functionality of the deprecated output frequency statement
can be reproduced by using the meter drive caller as follows:
output meter: meter, 0., forever, steps, 10;
<card> ::= output precision : <number_of_digits> ;
This will no longer be an issue when the binary output is implemented;
in that case, the output format will likely be fixed (float), or
an optional extended format (double) will be allowed.
Right now, the output results statement is only used to enable the experimental support for NetCDF output, which eventually will replace the current textual output:
<card> ::= output results : netcdf ;
<card> ::= default orientation :
{ euler123 | euler313 | euler321
| orientation vector | orientation matrix } ;
where
Note: this change implies that by default the selected way will be used to represent orientations in input and output. This flag is not honored throughout the code, yet. Right now, only structural nodes can output orientations as indicated by default orientation. However, there is no direct means to detect what format is used in the .mov file (while it is easy, for example, in the .nc file generated by NetCDF). As a consequence, it is the user's responsibility to keep track of what representation is being used and treat output accordingly.
<card> ::= model : <model_type> ;
<model_type> ::= static
This statement allows to set the model type to static, which means
that all dynamic structural nodes will be treated as static, and inertia
forces ignored.
Gravity and centripetal acceleration will only be considered as forcing
terms.
See the structural node (Section 6.1) for details.
<card> ::= rigid body kinematics : <rbk_data> ;
<rbk_data> ::= { <const_rbk> | <drive_rbk> }
<const_rbk> ::= const
[ , position , (Vec3)<abs_position> ]
[ , orientation , (OrientationMatrix)<abs_orientation> ]
[ , velocity , (Vec3)<abs_velocity> ]
[ , angular velocity , (Vec3)<abs_angular_velocity> ]
[ , acceleration , (Vec3)<abs_acceleration> ]
[ , angular acceleration , (Vec3)<abs_angular_acceleration> ]
<drive_rbk> ::= drive
[ , position , (Vec3_tpl_drive_caller)<abs_position> ]
[ , orientation , (Vec3_tpl_drive_caller)<abs_orientation_vector> ]
[ , velocity , (Vec3_tpl_drive_caller)<abs_velocity> ]
[ , angular velocity , (Vec3_tpl_drive_caller)<abs_angular_velocity> ]
[ , acceleration , (Vec3_tpl_drive_caller)<abs_acceleration> ]
[ , angular acceleration , (Vec3_tpl_drive_caller)<abs_angular_acceleration> ]
In principle, the kinematic parameters should be consistent.
However, in most cases this is not strictly required, nor desirable.
In fact, if the model is made only of rigid bodies, algebraic constraints
and deformable restraints, the case of a system rotating
at constant angular velocity does not require abs_angular_velocity
to be the derivative of abs_orientation, since the latter
never appears in the forces acting on the system.
Similarly, the abs_position and abs_velocity
do not appear as well, as soon as the latter is constant.
However, if other forces that depend on the absolute motion (position, orientation, and velocity) participate, this is no longer true. This is the case, for example, of aerodynamic forces, which depend on the velocity of the body with respect to the airstream, whose velocity is typically expressed in the global reference frame.
loadable path : [ { set | add } , ] " <path> " ;
This card allows to either set (optional keyword set)
or augment (optional keyword add) the search path
for run-time loadable modules using the path specified
as the mandatory argument path.
Note: this command should be considered obsolete, but its replacement is not implemented yet. It impacts the loading of all run-time loadable modules, not only that of loadable elements (Section 8.18. See for example the module load statement in Section 2.3.6.