Why We Made GageMap

Posted on August 9th, 2017

I spent a long time working at the Arnold Engineering Development Center, AEDC, in the 80’s and 90’s and had the great opportunity to work on many leading edge propulsion systems for our nations front line fighter aircraft.  The center is the largest in the world and has many facilities for full-scale testing of propulsion system in a simulated altitude environment.  There were many times where we would test twelve, fourteen, or even sixteen hours at a time and generate so much data that it would take weeks to get through it all.

In the mid-1990’s, the USAF experienced a significant rise high cycle fatigue (HCF) failures that generated a lot interest at the highest levels.   As with most large government organizations, this led to the formation of a couple of investigative groups to study the problem and figure out how to address it.  Given my position at the center, I was tagged with facilitating a working-group of experts from most of the OEM’s with the goal of improving test methods for detecting HCF problems.  ONE of the outcomes from the working-group was that there needed to be a better focus on “holistic test and evaluation” which simply means that testing should be viewed in the greater context of the overall development and service cycle.  We began looking at how well design models, particularly finite element models, compared with measured strains.

I spent a long time working at the Arnold Engineering Development Center, AEDC, in the 80’s and 90’s and had the great opportunity to work on many leading edge propulsion systems for our nations front line fighter aircraft.  The center is the largest in the world and has many facilities for full-scale testing of propulsion system in a simulated altitude environment.  There were many times where we would test twelve, fourteen, or even sixteen hours at a time and generate so much data that it would take weeks to get through it all.

In the mid-1990’s, the USAF experienced a significant rise high cycle fatigue (HCF) failures that generated a lot interest at the highest levels.   As with most large government organizations, this led to the formation of a couple of investigative groups to study the problem and figure out how to address it.  Given my position at the center, I was tagged with facilitating a working-group of experts from most of the OEM’s with the goal of improving test methods for detecting HCF problems.  ONE of the outcomes from the working-group was that there needed to be a better focus on “holistic test and evaluation” which simply means that testing should be viewed in the greater context of the overall development and service cycle.  We began looking at how well design models, particularly finite element models, compared with measured strains.

AEDC

AEDC

AEDC

AEDC

Historically, the finite element method did a pretty decent job of predicting natural frequencies which were useful for predicting rotation speed where resonances might occur.  Subjective comparison of mode-shapes was often done using holography to correlate predicted eigenvectors with operational deflection shapes (ODS).  However, direct comparison of measured strains with strains from the finite element model were rarely made.  Why?

A normal modes analysis using the finite element method produces a group of eigenvalues and eigenvectors which can be correlated to natural frequencies and mode shapes.  The output from the model is always nodal displacements for each eigenvector.  These displacements are almost always output in the global coordinate system – although local coordinate systems can be created with some additional effort.  Strains are, of course, the partial derivatives of the displacements, but for the finite element method, these are computed at so-called integration points within each element.  These results are extrapolated to the nodes (or interpolated to the element centroid).  Because elements share adjoining nodes, nodal strains are averaged.  Output is again, typically in the global coordinate system.

So, computed strains are point values, linked to the nodes, and output in some kind of coordinate system – most often the global coordinate system.  In general, stains in isotropic materials have six unique components (they are tensor quantities), so to compare the computed value to a measurement, you need to know the plane on which the measurement is made and a direction.  All this depends on a coordinate system too.

Strain measurements, on the other hand, are scaler quantities.  Of course, they are made at some location on a part and in some direction, but this knowledge needs to be converted to the coordinate reference frame of the finite element model if you want to compare the results.  Then there is the issue of averaging.  Strain gages make an average strain measurement over the area of the strain gage.  Once all this information is known, it is a fairly simple mathematical computation to resolve the analytical strain – at the nodes – to the direction of the strain gage for comparison with the measurement.  Whew.  There had to be a better way.

Gage on Model

Gage on Model

Gage on Model

Gage on Model

Well, they say that necessity is the mother of invention, so one day while trying to make a comparison of a measurement with a model, I decided to begin working on a routine to compute the average strain over a prescribed area from displacements at the corner points of the strain gage.  To get the displacements at the corner points of the strain gage, we used the element shape functions to interpolate the displacements from the nodal values for the element containing the strain gage corner.  Because we were using the element shape functions, we could guarantee that the strain gage was exactly on the surface by setting an appropriate natural coordinate (a property within the finite element formulation) to zero or one as appropriate for the element.  This allowed us to “map” the gage exactly on the surface.  GageMap!

Once the corner displacements of the gage were known, computing the strain over the area was fairly trivial.  Output from this computation was the average strain in the direction of the gage, but also gave us the transverse strain and the shear strain – on the surface of the part.  And because we interpolated the displacements for corners of the gage within the appropriate element, our output was no longer restricted to the nodes.  We were finally free of the mesh, and the rest is history.

We just released version 2017.3 of GageMap in August of this year, built upon more than 17 years of development.  Since the original formulation, GageMap has been expanded to enable users to find optimum sensor locations,  handle HCF computations, perform model validation, assess gage misplacement uncertainty, and much more.  There is even a scripting version so you can do mode superposition, hot/cold geometry corrections, or any kind of advanced data analysis you can imagine.  If you are responsible for comparing analysis and test – particularly strains – there is simply no better finite element post processor out there.GageMap works with three of the most popular finite element packages; Ansys, Abaqus, and Nastran.  It supports a large array of element types, simple or complex material properties, non-linear solutions, and cyclic symmetry.

Since we began more than seventeen years ago comparing analytical and experimental strains, we’ve learned a lot about modeling practices, as well as test practices.  The HCF problems of the mid-1990’s are now pretty rare because of products like GageMap.  This makes for even better propulsion systems and more reliable power generation plants, and that benefits us all.

Author: Kurt Nichol, President/CEO of Apex Turbine Testing Technologies

GageMap-Mesh-Free FEA Post Analysis Software

Click image to learn more

Mannually Mapping Strain Gages