RIGIDBODY_ForceToApplyOnBody_BE

Default: RIGIDBODY_ForceToApplyOnBody_BE($MOVEitem$) = ( [0.0], [0.0], [0.0] ) The force is evaluated per boundary element via a user-defined function and accumulated over all BEs belonging to the specified MOVE-flag. The moment about the center of gravity (COG) is computed automatically. Note: Priority over PC mapping, i.e. if both RIGIDBODY_ForceToApplyOnBody_PC and RIGIDBODY_ForceToApplyOnBody_BE are present for the same MOVE-flag, then RIGIDBODY_ForceToApplyOnBody_BE takes priority.

Area caching

When the optional fourth argument %RIGIDBODY_BE_CACHE% is specified, element areas are computed once and cached internally. In this case, the user-defined curve should incorporate only pressure/stress contributions (i.e. force per unit area).

Parallelization strategy

To ensure good load balancing, a reduced list of eligible BEs is computed once. All BEs that do not belong to MESHFREE RIGIDBODY coupling are excluded. The reduced list of BEs is then distributed across all processes, and each process collects its own contributions for forces and moments. In the next step, the partial contributions are summed via a global MPI-reduction operation. Note: The point cloud configuration can change for different numbers of MPI processes, which can affect the mapped forces and moments. The differences depend on the mapping technique used, distribution of points, etc., and have nothing to do with the inherent MPI communication. The example below showcases one such option to use BEmon(), BEmonApprox() functionalities to map quantities on the rigid bodies. The distribution of monitor points on the mapping geometry and their corresponding BE associations may differ between MPI processes. In addition, the BEmonApprox() tries to approximate the missing values from the neighboring BEs. This makes the mapping inherently non-conserving and thus the mapped forces and moments on the rigid bodies can be slightly different for different MPI configurations.