Direction Dependent Conditioning in Linear Static Analysis
Altair EmployeeIn this article you will learn how to create and use a boundary conditions which behaves as a support (or contact) on a rigid non-modeled structure in a linear static analysis.
In other words, it consists of a condition-based boundary condition depending on the direction of the displacement of the node.
For example let’s consider a support-type boundary condition applied on the Z component of a node:
- Displacement in negative Z direction is impossible (as if it was in contact with an infinitely rigid environment)
- Displacement in positive Z direction is possible and free.
This type of behavior generally requires usage of a non-linear analysis. But in this specific case, where the only source of non-linearity is this support conditioning, this can be solved with a linear static analysis by activating an iterative approach.
(Note that in such case, even though the linear static analysis solver is used, by definition the analysis and the result can no longer be considered linear).
If other source of non-linearity exists (contact between parts, non-linear materials, etc.), then a classical non-linear static analysis must be used.
Two features are used for this setup:
- A boundary condition with SUPORT (or SUPORT1) card image
(Those are specific boundary condition type usually used for Inertia relief cases) - The PARAM,CDITER parameter
Remark: A declination of this feature can be used adding some other components (MPC+SPOINT) to define node-to-node contact in a linear static analysis. This is called « MPC-based fast contact » or « SUPORT-based fast contact » (cf dedicated page in OptiStruct user manual).
However, in such case there exist a more advanced and more simple option, the « N2S-based Fast Contact » (cf dedicated page in OptiStruct user manual).
METHODOLOGY
1. Define the boundary conditions using SUPORT or SUPORT1
Those boundary conditions are defined as any other boundary condition (as SPC for example) in HyperMesh. You just need to specify the correct type.
Just like SPC, those SUPORT(1) must be stored in a load collector.
Difference between SUPORT and SUPORT1:
- SUPORT boundary conditions will be activated in all loadsteps that allow this feature.
- SUPORT1 boundary conditions required to be called in specific loadstep we want to activate them (using the SUPORT parameter).
Hence SUPORT1 should be preferred in case you might want to change conditioning between load steps.
Just like for SPC, the degrees of freedom that will be activated or not by a SUPORT(1) are defined in the nodes analysis (or displacement) system (which is, by default the global system).
For example, on the example below, to generate the correct support-type boundary conditions, we should define a SUPORT1 in X direction in the blue area, and in Y direction in the orange area.
When defining a SUPORT(1) on a DOF of a node, this will block negative values of the displacement along this DOF, and allow positive displacement.
On our example above : nodes in the blue area will be allowed to mode in X+, but not in X-.
This means you may have to generate local systems to cover all possible use cases you may face.
2. Activation of the iterative method via PARAM,CDITER
The PARAM,CDITER is defined as a PARAM card in HyperMesh.
When activated, it requires user to provide a maximum number of iterations that we allow OptiStruct to converge.
The PARAM,CDITER card cannot be used at the same time as PARAM,INREL !
Indeed those 2 cards will activate strictly different behavior for SUPORT(1) items.
Hence this method is not compatible with Inertia relief phenomenon.
3. Getting the final state of the support condition via PARAM,CDPCH
The PARAM,CDPCH card allow the user to request OptiStruct to provide an output file containing the stiffness matrix (DMIG super-element) equivalent to the boundary condition ar the end of convergence.
This matrix is stored in a separated output file with cdpch extension.
Possible usage of this feature is to be able to reuse this matrix in upcoming analysis, for example:
- To reduce processing time on future simulations where we do not expect support-type boundary conditions to change compared to initial run.
- Launch optimizations.
4. Run check and post-processing
User can verify that the method ic correclty applied in the calculation by reading the .out file.
A dedicated block should appear looking as follow:
Linear Gap Solution for Subcase: 1
Summary of Gap/Contact Element Status
-------------------------------------
Iter Switches Open Closed
-------------------------------------
0 ---- 396 0
1 195 201 195
2 144 217 179
3 62 261 135
4 6 274 122
*** Linear gap solution has converged ***
In term of post-processing, reaction forces from a SUPPORT-type conditioning will not be available through SPCFORCE output. You need to request GPFORCE to be able to recover those reaction forces..