derivatives step?
./configure --enable-runtime-loading
This requires the availability of the GNU ltdl library.
In addition to that, to enable building specific modules, one needs
to configure using the switch
./configure --with-module=<module-list>
where module-list is the list of the module names
one wants to build.
Module names correspond to the directories in modules/
without the module- prefix.
To add custom modules, use the module-template as a guideline,
and place the module in a subdirectory of modules/.
On x86/x86_64 with gcc/g++, MBDyn must be compiled with
LDFLAGS=-rdynamic
to instruct MBDyn to export symbols to the run-time loaded modules.
This is known to work with Cygwin as well.
No other architecture/compiler has been tested.
If you succeed, please drop us a note.
libltdl is built or to a bug in libtool
itself, one needs to explicitly link the libltdl object.
This is obtained, for example, by setting
LIBS=/usr/lib/libltdl.a
when configuring MBDyn, or by manually hacking the resulting
mbdyn/Makefile.
naive (documented here),
may be significantly more efficient than UMFPACK
at solving a wide class of typical multibody problems
(small & very sparse).
When not natively available, you need to download UMFPACK sources,
compile them following instructions provided with the package,
place the library (after renaming it to libumfpack.a)
and all the header files where the compiler and the linker
can find them, or instruct the C pre-processor about the location
of the header files by the CPPFLAGS switch,
and the linker about the location of the library
by the LDFLAGS switch.
On Debian GNU/Linux,
UMFPACK can be installed by means of a native package;
in that case, it has been reported that only the header files need
help to be located.
Then, libamd, used by UMFPACK, depends on libm,
but this information is not available to the linker during configuration.
So to configure UMFPACK support on Debian one needs to use
LIBS=-lm CPPFLAGS=-I/usr/include/umfpack ./configure
and that should be it.
If you are aware of more GNU/Linux distributions or other OSes
that provide UMFPACK or other uncommon packages that MBDyn
interacts with, please let us know
(thru the mbdyn-users
mailing list; you need to subscribe first;
instructions here).
#ifdef)
or specific input file statements;mbdyn-orig/, and a clean source tree with the patched software,
e.g. mbdyn-patched/, and produce a diff using
diff -uNr mbdyn-orig/ mbdyn-patched/ > your.name-date-description.patch
For example, Mario Rossi writing a patch on Christmas 2006 that fixes
a bug in the Jacobian matrix of the deformable hinge should
name the patch
mario.rossi-2006-12-25-deformable-hinge-jacobian.patch
AUTHOR: your name <email@address>
Copyright (C) year(-year) all rights reserved.
The copyright of this patch is transferred
to Pierangelo Masarati and Paolo Mantegazza
for use in the software MBDyn as described
in the GNU Public License version 2.1
If this statement goes in source code, either C/C++, LaTeX, shell
or whatever, it should be formatted as a comment, and placed towards
the top of each file that is significantly affected by the patch
(as a rule of thumb, more than 20 relevant lines, excluding comments
and lines with just open/close curly brackets), just below
the existing copyright statements.
The copyright transfer is required because it is the copyright's holder
that has the right to sue in case of license infringements; if you don't
release the copyright and the license is infringed, we would need to ask
you (and all other contributors) to sue those who infringed it.
The GNU Public License requires that the license terms cannot be changed
in the sense of restricting the rights to use or copy the code,
so releasing the copyright shouldn't lead to any rights loss for the
Author (on the contrary: the Author's and the rest of the world's rights
should be very well protected).
derivatives step?
derivatives tolerance
and the desired derivatives max iterations are set;derivatives coefficient;
it roughly represents the ratio between the elastic
and the inertia forces during the computation
of the highest order derivatives before actually starting
the integration.initial assembly, is experimental.
By definition, an algebraic constraint defines an algebraic relationship
between the relative position and/or orientation
of two "geometrical entities" whose kinematics is that of a rigid body
(in MBDyn they're called structural nodes;
the difference between a structural node and a rigid body is that,
from the point of view of algebraic constraints, structural nodes
don't need to have any mass or inertia, since it's all about geometry
and kinematics).
Consider, for example, a spherical hinge joint,
which connects two structural nodes.
The position and orientation of node 1 are x_1
and R_1, and those of node 2 are x_2
and R_2.
The location (and the orientation, when matters) of the constraint
(the ball joint, in this case) must be defined with respect to both nodes.
So, with respect to node 1, the location of the ball is defined
by rel_f_1, where the prefix rel_ means that
it's defined in the node's reference frame, in this case
frame R_1, so that in the absolute, or global, frame,
f_1 = R_1 * rel_f_1
and, with respect to node 2, the location of the ball is defined
by rel_f_2, and
f_2 = R_2 * rel_f_2
What counts is that the location of the ball, regardless of what node
is considered, must be unique; namely, both paths, either from node 1 or 2,
must lead to the same absolute point:
x_1 + f_1 = x_2 + f_2The above is the definition of the spherical joint. What really matters is
rel_f_1 and rel_f_2: one wants the constraint
to be correctly located with respect to each body (think of an elbow:
it has to be in the right place with respect to both the arm and the forearm,
while its absolute location makes little sense); when the above absolute
relationship is not valid, something is inconsistent,
so x_1, x_2, R_1 or R_2
need to change (usually, all of them need).
The structural nodes need to adjust their absolute position and orientation
so that the definition of the algebraic constraints is satisfied.
That's why we need two definitions for the same location/orientation:
because we need to define both rel_f_1 and rel_f_2,
and let the solver check if the rest of the model is consistent.
How to ensure consistencytotal joint, which allows to independently constrain
the components of the relative position and orientation between two nodes.
spherical hinge, which constrains
the three relative displacement components, andprismatic joint, which constrains
the relative orientation.structural nodes connected by
a revolute hinge joint.
That joint allows one degree of freedom, corresponding
to the relative rotation of the nodes
about axis 3 of the revolute hinge joint.
In some cases, the user may want to impose the value of the angle
about that axis as well.
In this case, a different joint is required, since now it is imposing
all the 6 relative degrees of freedom, rather than the 5 ones imposed
in the previous case.
total joint element.
This joint allows to select what relative degrees of freedom are allowed
between two nodes and, optionally, to enforce the value of the remaining ones.
spherical hinge joint,
that constrains the relative position (3 degrees of constraint),
drive hinge joint, that allows to impose
the relative orientation between the two nodes as a whole
(thus adding 3 more degrees of constraint).
axial rotation joint,
which is equivalent to a revolute hinge with the angular velocity
about the revolute hinge axis imposed as function of time.
This is not exactly equivalent to imposing the relative orientation,
even in case the imposed angular velocity is exactly the time derivative
of the desired relative angle, since the constraint
is now non-holonomic and, as such, may drift as a consequence
of numerical integration.
.log file.
So, for example, to find out what is the value of a label called
NODE1, related to an analysis whose output files
are named output, the command
$ grep 'NODE1' output.log
integer NODE1 = 13170
yields the result.
All variables are dumped, including pre-defined ones.