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 limitations on the number of shared libraries and functions that can be dynamically loaded. It is thus quite feasible to create mechanical behaviours databases by creating a shared library by 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 moving them on a shared folder. However, experience shows that using shared libraries can be confusing for some user as they have to update their environment variables (PATH on Windows or LD_LIBRARY_PATH on Unixes) for the libraries to be usable. Shared libraries can also be more sensible to system updates. A drawback of using shared libraries is that the behaviors must be written in C or C++ as the name of the functions implementing the behaviors must be upper-cased du to CalculiX internal conventions1 The reason of such a restriction is detailed below. On way of generating such library with the appropriate naming convention is to use the MFront code generator: