4. Handling element diversity

Real finite element models are rarely homogeneous. A single automotive body-in-white model may contain beam elements for the door hinges, shell elements for the panels, and solid elements for the cast suspension knuckles. A pressure vessel model may combine shell elements for the cylindrical wall with solid elements for the nozzle reinforcement. When such a mixed mesh is converted into a graph for a graph neural network (GNN), the conversion logic must decide what a node is, what an edge is, and how attributes from fundamentally different element topologies can be placed into a single consistent feature space. This section addresses that problem directly: how to map 1D, 2D, and 3D elements onto graph structures, and how to keep the resulting graph usable for downstream learning.

Why element diversity breaks naive conversion

The most common naive approach is to treat every finite element node as a graph node and every element as a clique of edges. For a 3D hexahedral mesh this produces eight nodes per element and 28 edges per element (a complete graph on eight vertices), which is both memory-heavy and physically misleading: a hex element does not transmit stiffness between all pairs of its corners in the same way. For a 2D quadrilateral, the same rule gives four nodes and six edges, again over-connecting. For a 1D beam element, the two end nodes are connected by a single edge, which happens to be reasonable, but the beam's bending behavior is not captured by a scalar edge at all.

The deeper issue is that element dimensionality encodes different physics. A beam element carries axial, bending, and torsional stiffness along a line; a shell element carries membrane and bending stiffness across a surface; a solid element carries full three-dimensional stress states through a volume. If the graph representation collapses all of these into the same node-and-edge schema without distinguishing them, the GNN cannot learn to treat them differently, and predictions on mixed models degrade.

Node and edge definitions per element family

A practical conversion strategy is to define the graph schema per element family and then merge the families with explicit type tags. The table below summarizes a workable convention. It assumes the graph is undirected unless stated otherwise, and that node features are stored as a fixed-length vector per node.

The key decision in this table is that 2D and 3D elements use edge-based connectivity rather than clique connectivity. A quad contributes four edges, not six; a hex contributes twelve, not twenty-eight. This matches the load path in the underlying shape functions more closely and keeps the graph sparse. For a tet, the four edges are the natural choice; for a hex, the twelve edges correspond to the element's physical edges.

Merging families into one graph

Once each family is converted, the families must be merged. Two nodes that originate from different elements but share the same physical mesh node ID must be identified as the same graph node. This is a simple dictionary join on the mesh node ID, but it must be done before feature aggregation, otherwise duplicate nodes will appear at shell-to-solid interfaces and the GNN will see spurious boundaries.

After the join, each node carries a feature vector assembled from its incident elements. A node at a shell-solid interface may receive contributions from both shell and solid elements; the feature vector should record the count of each element type incident to the node, so the model can distinguish an interface node from a pure shell node. A compact convention is to append a one-hot element-type histogram to the node feature vector.

# Example: node feature assembly for a mixed mesh
# node_features[i] = [x, y, z, n_beam, n_shell, n_solid, avg_thickness, avg_E]
for nid, node in mesh.nodes.items():
    incident = node.incident_elements
    n_beam  = sum(1 for e in incident if e.family == "1D")
    n_shell = sum(1 for e in incident if e.family == "2D")
    n_solid = sum(1 for e in incident if e.family == "3D")
    thickness = mean([e.thickness for e in incident if e.family == "2D"] or [0.0])
    E = mean([e.material.E for e in incident])
    node_features[nid] = [node.x, node.y, node.z,
                          n_beam, n_shell, n_solid, thickness, E]

This snippet is illustrative, not a library call; the exact API depends on the mesh reader (for example, a CalculiX .inp parser or an Abaqus .inp parser). The important point is that the feature vector length is fixed across the whole model, and the element-type counts make the mixed nature of each node explicit.

Edge typing and direction

Edges should also carry a type tag: beam, shell, or solid. When a shell edge and a solid edge connect the same pair of nodes (which can happen at a shell-solid transition), the graph should keep both edges with distinct type tags rather than collapsing them, because the two edges represent different stiffness contributions. In message-passing GNNs, edge-type-aware aggregation (for example, separate weight matrices per edge type) then preserves this distinction.

Direction is a separate concern. Structural meshes are naturally undirected, but beam orientation vectors and shell normals are directional attributes. Store these as edge features or node features rather than as edge direction, so the graph remains undirected and the GNN does not have to learn an arbitrary orientation convention.

Worked example: a mixed bracket model

Consider a simplified bracket: a 200 mm × 100 mm × 5 mm steel plate modeled with 400 S4R shell elements, a 40 mm long beam stub modeled with 10 BEAM188 elements attached at one edge, and a 30 mm × 30 mm × 30 mm solid block modeled with 125 C3D8 hex elements bonded to the plate's center. The mesh has, say, 520 shell nodes, 11 beam nodes, and 216 solid nodes, with 12 nodes shared at the shell-solid bond and 2 nodes shared at the beam-shell attachment.

After conversion, the graph has 520 + 11 + 216 − 12 − 2 = 733 nodes. Shell edges number roughly 400 × 4 = 1600 (minus shared edges, so somewhat fewer); beam edges number 10; solid edges number 125 × 12 = 1500. The node feature vector has length 8 as in the snippet above. A quick sanity check is to verify that the number of nodes equals the number of unique mesh node IDs and that no node has an element-type histogram summing to zero.

Common failure modes and how to spot them

• Clique explosion. Hex elements expanded to 28 edges each inflate memory by roughly 2.3× and blur the load path. Symptom: graph edge count far exceeds 12 × number of hex elements.
• Interface duplication. Shell and solid nodes at a bonded interface are not merged. Symptom: node count exceeds unique mesh node count; the GNN sees a false free surface.
• Feature length mismatch. Beam nodes lack thickness, shell nodes lack cross-section area. Symptom: ragged arrays or silent zero-padding that the model interprets as real zeros. Fix by defining a fixed schema with explicit "not applicable" sentinels and a mask channel.
• Lost orientation. Beam orientation vectors and shell normals dropped during conversion. Symptom: bending-dominated predictions are systematically wrong while axial predictions are acceptable.

The figure below summarizes the conversion pipeline for the three element families and the merge step that produces a single typed graph.

Practical guidance for mixed-mesh pipelines

Three habits make mixed-mesh conversion reliable in practice. First, define the node feature schema before writing any converter code, and include explicit element-type count channels; this prevents silent zero-padding later. Second, validate edge counts per family against the source mesh, as noted in the tip above. Third, keep the conversion deterministic: sort node IDs and edge lists before writing the graph, so that repeated runs on the same mesh produce byte-identical outputs and downstream training is reproducible.

When the model contains transition elements (for example, a shell-to-solid transition element or a rigid link), treat them as their own family with a dedicated edge type rather than forcing them into one of the three main families. A rigid link, for instance, is best represented as a single edge with a high stiffness attribute and a rigid type tag, so the GNN can learn that it transmits load without deforming. This keeps the schema extensible as the model complexity grows.