We often deal with issues in our models and have a hard time finding what might be going on. This article aims to demonstrate some debugging scenarios in a bumper beam model, but it can occur in any model.
We will describe three different cases with the same model, representing different debugging scenarios. At the end, you will find a zipped file containing each case that you can try to solve by yourself.
Case 1
Running the model, you will see that the computation has been completed successfully, but the percentage of error is positively increasing during all the analysis and reaches 99.9% at the last cycles.
A weird behavior can be seen when loading the animation file (H3D) in HyperView, as shown in the image below.
So, we might wonder, what can cause this issue in the model?
Looking at the 0000.out file, you can see all the warnings and errors related to the model. They are:
- 3-node shell formulation
- Incompatible kinematic conditions between the rigid wall and rigid body.
- Stiffness value of springs.
The first and third warnings do not generally provoke this kind of issue.
Let’s check the second warning - Incompatible Kinematic Conditions (IKC).
We can run the model checker on HyperMesh and check which nodes are given the incompatible kinematic condition.
The nodes responsible for the IKC are placed on the side parts of the model, so we can conclude that the IKC is not responsible for the problem since these nodes are not going to impact the rigid wall.
The model checker shows us this information:
The only one that could explain the issue is “Free nodes in the model”. Looking in detail at our boundary conditions and contacts, we can see a free node in the center of the frontal beam:
This free node has been selected in the initial velocity set. Then, it gets an initial velocity and impacts the bumper beam once it’s restrained by the rigid wall.
To solve this issue, we can use the model checker, right click on “Free nodes in the model” and select “Apply Auto Correction”.
Behavior after changes:
The issue has been solved.
Case 2
When running this model, the computation stopped and shows:
One investigation that we can do is on the time step. Looking at the 0000.out file you can see a list of the smaller time steps in the model.
We can see that the node controlling the model time step is the node with ID 12178. If you search this node on HyperMesh, you will see that it is the Rigid Body main node.
But before making any changes to the time step control or to the rigid body definition, first, let’s run the model checker. This can be done in Validate -> Check -> Model.
As a result, we can see that we have one error and three warnings in the model. All errors must be corrected before running the model, and all warnings must be reviewed.
By right-clicking on “Multiple RBODY sharing common nodes” and selecting review, you will see which Rigid body is giving this error.
To solve this, you can right-click on “Multiple RBODY sharing common nodes” and select “Apply Auto Correction”.
After this modification, you can rerun the model and see that the issue has been solved.
Case 3
At first look, this run looks fine. The energy error is only -0.7%, we have a very low added mass in the model, and it was printed the message “Normal Termination” (these can be checked in the 0001.out file).
When opening the animation file (H3D) in HyperView, at first sight,everything is ok, such as the energy balance and the behavior.
Nevertheless, looking more into details and plotting the outputs, we can see:
- Kinetic and Internal energy converge too fast in the energy balance.
- All rear nodes have no initial velocity (figure below).
Usually, this is a problem with the boundary conditions. Let’s check the BC and the INIVEL.
On HyperMesh, we can go on Loads -> BC and see if the Rigid Body is restrained correctly. We need only the DOF1 (Translation in X) to be free. The model is correct.
Now, let’s check the initial velocity. On Loads -> Inivel -> Right click -> Review. We do this to review which nodes are selected in the initial velocity set.
You can see that all nodes of the model are selected in the initial velocity set, except for the Rigid Body main node. As it’s a /RBODY, the independent node is the main node, so if we don’t have any initial velocity in the main node, we don’t have it in the secondary nodes. That is to say, none of the nodes connected to the Rigid Body will have initial velocity.
After adding the Rigid Body main node in the Initial Velocity set, the problem has been solved.
The model can be downloaded here: Models.zip