FEA Simulation: What is Element Deactivation Used For?

We were recently asked what the term ‘element death’ meant in the context of finite element analysis (FEA) and what would it be used for.

Simply put, this refers to the turning off or removal of elements from a running analysis.

There are two types of element death or element deactivation, and this blog explores them both while alongside what they are used for.

AUTOMATIC ELEMENT DEACTIVATION

One type involves removing an element from a simulation once the material constituting it has failed.

This could be via a mechanism, such as the impact of a bird on the leading edge of a composite wing where, once the layup has failed, you want to see what the bird hits next for its secondary impact(s).

Similarly, in a joule heating analysis you might ‘kill’ ice elements as they melt.

Either way, the removal is automatic and triggered by logic in the solver that is defined before you start the analysis.

MANUAL ELEMENT DEACTIVATION

The other type is more manual, where you as the analyst decide to remove some elements at a point in the solution to see what happens as load paths change.

Why would you do this? Examples where this might be a useful thing could be:

• Simulating the sudden elimination of a prop supporting a steel structure – you preload the structure with the prop in place and then turn it off to see how the load redistributes to the structure during a sudden removal and if failure ensues.
• Where part of an airframe is suddenly eliminated due to a ballistic impact.
• Simulating the removal of support structures from a 3D printed component, and how the frozen-in stresses redistribute and distort the part.

ELEMENT DEACTIVATION CASE STUDY

To illustrate how simple this can be, and the kind of information you can get from it, we’ll use an example based on based on some work for a client around 20 years ago.

They had a rotating propellor and wanted to see the impact of the sudden loss of one of the blades on the forces in the bearings. For this illustration, we’re not applying the pressure distributions from the airflow, just spinning up the propellor to 2400 RPM and then shutting off one of the blades.

In the real case, we used a user sub-routine to calculate loads on the blade based on speed and orientation.

Fortunately, MSC Marc makes this very easy.

We found using an initial velocity condition to set the blades in motion took a lot more solution time to settle than spinning the blades up to 2400 RPM from stationary, so a ten-second-long transient step was run to reach full speed.

In the second step we deactivate one blade set of elements by simply nominating the ones to remove.

Looking at the reaction forces at the base of the shaft we can see at the moment the blade is deactivated the lateral reaction forces in the constraint that represents the shaft bearing change dramatically as the rotor becomes imbalanced.

We can also look at the tip displacement of one of the remaining blades.

As the speed builds, we see an increase in out of plane deflection rise as the centrifugal load bends the blade. There’s some underlying vibration with an increase at around 4s as we pass through the first bending mode of the blade and then a larger excitation at t=10s when the fifth blade disappears.

If we were interested in the effects of different blade fractions or multiple blade-loss scenarios we could save a lot of time by writing a restart file after the end of the spin up simulation and restart multiple different jobs from that with different failure conditions.

MSC Marc is available under the MSC One token licensing scheme and is a very powerful non-linear FEA solver, renowned for its robust contact and handling of very large strain simulations.

A broad set of user subroutine interfaces also makes it a very flexible tool for users at the cutting edge of what can be done.

If you are interested in this, or have other difficult non-linear problems please get in touch with us to discuss how we might be able to help.