Next: The CalculiX interface. Up: User subroutines. Previous: Gap heat generation (fricheat.f) Contents
There are two ways of introducing user-defined mechanical behavior:
Each of these approaches has its own advantages and its own pitfalls.
The first one is intrusive and requires a partial recompilation of CalculiX, which means having access to the sources and the rights to install the executable if it is meant to be deployed on a system-wide location.
The second one does not require any modification to CalculiX, is generally easier to set up and is very flexible. There is no intrinsic limitation on the number of shared libraries and functions that can be dynamically loaded. It is thus quite feasible to create mechanical behaviour databases by creating a shared library for each specific material. Such libraries will only be loaded if needed. In such an approach, the mechanical behaviour is dedicated to a specific material and is self-contained: it has no external parameter. Shared libraries can be shared between co-workers by putting them on a shared folder. However, experience shows that using shared libraries can be confusing for some users as they have to update their environment variables (PATH on Windows or LD_LIBRARY_PATH on Unix) for the libraries to be usable. Shared libraries can also be more sensitive to system updates. A further drawback of using shared libraries is that the behavior must be written in C or C++ and the name of the functions implementing the behavior must be upper-case due to CalculiX internal conventions1. The reason of such a restriction is detailed below. One way of generating such library with the appropriate naming convention is to use the MFront code generator: