4. Creating your first PivotTable from CAE results

With a clean, well-structured nodal stress dataset in hand, the next step is to turn that flat table into a summary that answers engineering questions rather than merely listing numbers. A PivotTable is the fastest route from a raw CAE export to a stress summary organized by part, load case, and location. This chapter walks through building that first PivotTable, choosing which fields belong in which area, and shaping the layout so the result reads like an engineering report instead of a spreadsheet dump.

Starting from a suitable source table

Before inserting the PivotTable, confirm the source range is a proper tabular block: one header row, no merged cells, no blank rows or columns inside the data, and one record per row. A typical nodal stress export looks like this:

NodeID  Part      LoadCase  Location   Stress_MPa  StressType
1001    Bracket   LC1       Fillet     182.4       vonMises
1002    Bracket   LC1       Fillet     176.9       vonMises
1003    Bracket   LC1       Web        121.3       vonMises
1004    Bracket   LC2       Fillet     241.7       vonMises
1005    Bracket   LC2       Web        158.2       vonMises
1006    Housing   LC1       Flange      94.6        vonMises
1007    Housing   LC2       Flange      133.8       vonMises

Each row is one node under one load case. The Stress_MPa column holds the scalar result, and StressType records which stress measure it represents. Keeping StressType as a field is deliberate: if the export mixes von Mises, maximum principal, and shear stresses, you can filter to a single measure inside the PivotTable rather than pre-filtering the source and losing the others.

Select any cell inside the range, then choose Insert > PivotTable. Excel proposes the full contiguous range and a new worksheet. Accept both. The PivotTable Fields pane appears with every header listed as a field, and the four areas — Filters, Columns, Rows, and Values — wait empty.

Understanding what each area does

The four areas are not interchangeable; each answers a different question.

• Rows defines the vertical grouping — the categories you want to read down the page. For nodal stress, Part and Location are natural row fields because engineers compare regions within a component.
• Columns defines a horizontal grouping, typically a comparison dimension such as LoadCase. Putting load cases across the top lets you read LC1 and LC2 side by side for the same location.
• Values holds the numeric field to aggregate. Stress_MPa goes here, and the default aggregation for numeric data is Sum — which is almost always wrong for stress.
• Filters applies a page-level restriction, such as limiting the view to StressType = vonMises or a single part, without removing fields from the row/column structure.

Building the first layout

Drag Part to Rows, then Location beneath it so the rows nest: each part expands into its locations. Drag LoadCase to Columns. Drag Stress_MPa to Values, then open the value field settings and switch from Sum to Max. Finally, drag StressType to Filters and select von Mises.

The resulting table has one row per part-location combination and one column per load case, with the maximum nodal von Mises stress in each cell. That single view already answers the most common screening question: which location in which part reaches the highest stress, and under which load case.

Reading and refining the result

In the example above, the Bracket/Fillet location reaches 241.7 MPa under LC2, clearly above the same location under LC1 and above every other cell. That is the kind of signal a stress engineer wants surfaced immediately. Two refinements make the table more trustworthy before it is used for any decision.

First, verify the aggregation is Max and not Sum by clicking any value cell and checking the field settings; a Sum of nodal stresses will produce numbers in the thousands and is an easy tell. Second, confirm the filter is actually applied — if StressType contains mixed measures, an unfiltered Max will silently compare von Mises against principal stresses, which are not on the same basis.

Choosing Max versus Average deliberately

The aggregation choice encodes an engineering intent, so make it consciously rather than accepting the default.

For a first screening pass, Max is the correct default because design decisions are driven by the worst-case node, not the regional mean. Average becomes useful later when you want to compare whether one load case raises stress broadly across a region or only at an isolated node.

Common first-build problems

If the PivotTable shows a single row labeled "(blank)" or the values are all zero, the source range likely excluded the header row or included a blank column. Re-select the full range including headers and rebuild. If a field you expect is missing from the Fields pane, the source range did not cover that column. If numbers appear as text and cannot be aggregated, the Stress_MPa column contains non-numeric entries — often a solver comment or a unit suffix — and must be cleaned in the source before pivoting.

A correctly built first PivotTable is compact but already decision-ready: it groups nodes by part and location, compares load cases across columns, reports peak stress per cell, and restricts the view to one stress measure. From this foundation, subsequent chapters extend the same structure with additional statistics, calculated fields, and charts.