JuliaFEM.jl/docs/book/element_architecture.md

title, description, date, author, categories, keywords, audience, level, type, series, chapter, status

title	description	date	author	categories	keywords	audience	level	type	series	chapter	status
Element Architecture: Separation of Concerns	Understanding finite elements as composition of orthogonal concerns: topology, interpolation, integration, and fields	November 9, 2025	Jukka Aho	architecture theory design	element topology interpolation integration basis functions separation of concerns composition	researchers	intermediate	theory	The JuliaFEM Book	2	draft

Introduction

What is a finite element? This seemingly simple question has profound implications for software architecture, performance, and maintainability. Most FEM codes conflate multiple concerns into monolithic "element types," leading to combinatorial explosion and code duplication. This chapter presents JuliaFEM's approach: elements as composition of orthogonal concerns.

The Four Orthogonal Concerns

A finite element is fundamentally composed of four independent concerns:

1. Topology (Reference Element Geometry)

What it is: The geometric shape of the reference element in parametric space.

• Examples: Triangle, Quadrilateral, Tetrahedron, Hexahedron, Pyramid, Wedge
• Properties: Dimension, edges, faces; parametric domain
• Mathematics: Differential geometry, topology
• Key insight: Topology is pure geometry, independent of node count or DOF placement

Critical: Topology does NOT specify node count! That's determined by the interpolation scheme.

Reference element: The element in parametric coordinates \xi \in \Omega_{ref}

Triangle reference element (parametric domain):
     η
     ^
     |
  (0,1)
     |  \
     |    \
     |      \
     +---------> ξ
  (0,0)    (1,0)

Same topology works for:
- 3 nodes (linear, P1)
- 6 nodes (quadratic, P2) 
- 10 nodes (cubic, P3)
- Edge DOFs (Nédélec)
- Face DOFs (Raviart-Thomas)

2. Interpolation (Basis Functions + DOF Placement)

What it is: How to interpolate field values AND where degrees of freedom live.

• Examples: Lagrange (nodal DOFs), Nédélec (edge DOFs), Raviart-Thomas (face DOFs)
• Properties: Polynomial order, continuity, DOF location, partition of unity
• Mathematics: Approximation theory, functional analysis
• Can vary: Same topology with different interpolation schemes

Interpolation formula: u(\xi) = \sum_{i=1}^n N_i(\xi) u_i

where N_i(\xi) are basis functions and u_i are DOF values (not necessarily at nodes!).

Critical insight: Interpolation determines BOTH polynomial degree AND node count:

• Lagrange{Triangle, 1} → P1 → 3 nodes (vertices only)
• Lagrange{Triangle, 2} → P2 → 6 nodes (vertices + edge midpoints)
• Lagrange{Triangle, 3} → P3 → 10 nodes (vertices + edges + interior)
• Nedelec{Triangle, 1} → Edge elements → 3 DOFs on edges, NOT at nodes!

Node count vs DOF count:

• Nodes: Geometric points for element connectivity (graph structure)
• DOFs: Where unknowns live (can be at nodes, edges, faces, interior)

# Electromagnetics: DOFs on edges, not nodes
element = Element(Triangle(), Nedelec{Triangle, 1}(), Gauss{2}(), (1,2,3))
nnodes(element) # → 3 (vertices for connectivity)
ndofs(element)  # → 3 (one DOF per edge)

# Standard mechanics: DOFs at nodes
element = Element(Triangle(), Lagrange{Triangle, 1}(), Gauss{1}(), (1,2,3))
nnodes(element) # → 3
ndofs(element)  # → 3 (coincide for nodal elements)

# Quadratic: More nodes than linear
element = Element(Triangle(), Lagrange{Triangle, 2}(), Gauss{3}(), (1,2,3,4,5,6))
nnodes(element) # → 6 (vertices + edge midpoints)
ndofs(element)  # → 6

3. Integration (Quadrature Rules)

What it is: How to numerically integrate over the element.

• Examples: Gauss-Legendre, Gauss-Lobatto, reduced integration
• Properties: Number of points, weights, accuracy order
• Mathematics: Numerical integration theory
• Can vary: Full vs. reduced integration, different orders

Integration formula: \int_\Omega f \, dV \approx \sum_{i=1}^{n_q} w_i f(\xi_i) |J(\xi_i)|

where w_i are quadrature weights, \xi_i are integration points, and |J| is the Jacobian determinant.

Key property: Integration scheme is independent of topology and interpolation (mostly).

• Full integration: Enough points to integrate exactly
• Reduced integration: Fewer points (e.g., for locking prevention)
• Selective integration: Different rules for different terms

4. Fields (Data)

What it is: The variables/data stored on the element.

• Examples: Displacement, temperature, pressure, velocity
• Properties: Scalar/vector/tensor, time-dependent or not
• Mathematics: Depends on the PDE being solved
• Problem-dependent: Elasticity has displacement, heat has temperature

Field storage: Each element stores values at nodes or integration points.

fields = Dict(
    :displacement => [u1, u2, u3],  # Nodal values
    :temperature => [T1, T2, T3],
    :stress => [σ1, σ2, σ3, σ4]     # Integration point values
)

Key property: Fields are completely independent of topology, interpolation, and integration.

The Anti-Pattern: Code Aster (and Abaqus)

Commercial FEM codes conflate topology, node count, and interpolation, leading to hardcoded combinatorial explosion:

The Hardcoded Node Count Anti-Pattern

Element Type	Topology	Node Count	Polynomial Order	Integration
TRIA3	Triangle	3 (hardcoded!)	P1	Default
TRIA6	Triangle	6 (hardcoded!)	P2	Default
QUAD4	Quadrilateral	4	Q1	Full
QUAD8	Quadrilateral	8	Q2 Serendipity	Full
QUAD9	Quadrilateral	9	Q2	Full
TETRA4	Tetrahedron	4	P1	Default
TETRA10	Tetrahedron	10	P2	Default
HEXA8	Hexahedron	8	Q1	Full (2×2×2)
HEXA20	Hexahedron	20	Q2 Serendipity	Full
HEXA27	Hexahedron	27	Q2	Full (3×3×3)

The fundamental mistake: Node count is hardcoded into the type name, when it should be a consequence of:

1. Topology (geometric shape)
2. Interpolation scheme (polynomial degree)

Result: Cannot use Triangle with edge DOFs (Nédélec), cannot add interior DOFs for pressure, cannot use hierarchical basis with same topology.

The Problem with Conflation

// Code Aster style (pseudo-code)
class TRIA3 {
    // Topology, node count, interpolation all mixed
    Node nodes[3];  // Hardcoded!
    void stiffness_matrix() {
        // Hardcoded: 3 nodes, P1 shape functions, default integration
    }
};

class TRIA6 {
    // Almost identical code for same topology!
    Node nodes[6];  // Different hardcoded count
    void stiffness_matrix() {
        // Hardcoded: 6 nodes, P2 shape functions, more integration points
    }
};

// Now need TRIA7, TRIA10 (cubic), QUAD4, QUAD8, QUAD9, ... → explosion

Issues:

• ❌ Hardcoded node count prevents using same topology with different basis
• ❌ Cannot use edge/face DOFs (Nédélec, Raviart-Thomas for electromagnetics)
• ❌ Cannot add interior DOFs (pressure in mixed formulations)
• ❌ Code duplication (TRIA3 and TRIA6 nearly identical except node count)
• ❌ Combinatorial explosion (n shapes × m node-counts × k integrations × ...)
• ❌ Maintenance nightmare (bug fix must be repeated in all variants)
• ❌ No runtime dispatch possible (everything statically hardcoded)

JuliaFEM's Approach: Composition Over Conflation

Separation of Concerns

# 1. Define topology (pure geometry, NO node count)
abstract type AbstractTopology end

struct Point <: AbstractTopology end
struct Segment <: AbstractTopology end
struct Triangle <: AbstractTopology end
struct Quadrilateral <: AbstractTopology end
struct Tetrahedron <: AbstractTopology end
struct Hexahedron <: AbstractTopology end
struct Pyramid <: AbstractTopology end
struct Wedge <: AbstractTopology end  # Prism

# Properties come from topology itself
dim(::Triangle) = 2
dim(::Tetrahedron) = 3

# 2. Define interpolation schemes (determines node count AND DOF placement)
abstract type AbstractBasis end

# Lagrange family: nodal DOFs, polynomial degree P
struct Lagrange{T<:AbstractTopology, P} <: AbstractBasis end

# Serendipity: reduced node count (no center nodes)
struct Serendipity{T<:AbstractTopology, P} <: AbstractBasis end

# Nédélec: edge DOFs for H(curl) spaces (electromagnetics)
struct Nedelec{T<:AbstractTopology, P} <: AbstractBasis end

# Raviart-Thomas: face DOFs for H(div) spaces (fluid flow)
struct RaviartThomas{T<:AbstractTopology, P} <: AbstractBasis end

# Hermite: nodal values + derivatives
struct Hermite{T<:AbstractTopology, P} <: AbstractBasis end

# Node count is DERIVED from topology + basis:
nnodes(::Lagrange{Triangle, 1}) = 3   # P1: vertices only
nnodes(::Lagrange{Triangle, 2}) = 6   # P2: vertices + edge midpoints
nnodes(::Lagrange{Triangle, 3}) = 10  # P3: vertices + edges + interior

nnodes(::Lagrange{Quadrilateral, 1}) = 4   # Q1: corners
nnodes(::Lagrange{Quadrilateral, 2}) = 9   # Q2: full tensor product
nnodes(::Serendipity{Quadrilateral, 2}) = 8  # Q2 without center

# 3. Define integration rules
abstract type AbstractIntegration end
struct Gauss{N} <: AbstractIntegration end  # N = order (not point count!)
struct Lobatto{N} <: AbstractIntegration end
struct Reduced <: AbstractIntegration end

# 4. Element composes all three + connectivity
struct Element{T<:AbstractTopology, B<:AbstractBasis, I<:AbstractIntegration, N}
    topology::T
    basis::B
    integration::I
    connectivity::NTuple{N, UInt}  # Tuple, not Vector!
    fields::Dict{Symbol, Any}  # TODO: Type-stable structure
end

User-Facing API

# Create element by composing concerns
topology = Triangle()
basis = Lagrange{Triangle, 1}()     # Linear P1 → 3 nodes
integration = Gauss{2}()             # Order 2 (3 points for triangles)

element = Element(topology, basis, integration, (1, 2, 3))  # Tuple!

# Type-stable construction (preferred)
element = Element{Triangle, Lagrange{Triangle,1}, Gauss{2}, 3}(
    Triangle(),
    Lagrange{Triangle, 1}(),
    Gauss{2}(),
    (1, 2, 3),  # Tuple for connectivity
    Dict{Symbol, Any}()
)

# Same topology, different polynomial order:
element_p2 = Element(Triangle(), Lagrange{Triangle, 2}(), Gauss{3}(), 
                      (1, 2, 3, 4, 5, 6))  # 6 nodes for P2

# Same topology, edge DOFs (electromagnetics):
element_nedelec = Element(Triangle(), Nedelec{Triangle, 1}(), Gauss{2}(),
                           (1, 2, 3))  # 3 nodes, but DOFs on edges!

# Same topology, different integration:
element_reduced = Element(Triangle(), Lagrange{Triangle, 1}(), Reduced(),
                           (1, 2, 3))

**Benefits:**

- ✅ Mix-and-match any combination
- ✅ Type system enforces compatibility
- ✅ Compiler generates specialized code for each combination
- ✅ Zero runtime overhead (types disappear after compilation)

### Directory Structure

```text
src/
  topology/
    point.jl           # 0D: Point
    segment.jl         # 1D: Segment (line)
    triangle.jl        # 2D: Triangle (no node count!)
    quadrilateral.jl   # 2D: Quadrilateral
    tetrahedron.jl     # 3D: Tetrahedron
    hexahedron.jl      # 3D: Hexahedron (brick)
    pyramid.jl         # 3D: Pyramid
    wedge.jl           # 3D: Wedge/prism
    
    # Each file defines pure geometry:
    # - Parametric domain
    # - Edges, faces
    # - Reference coordinates (for standard node placements)
    # NO node count hardcoded!
  
  basis/
    lagrange.jl              # Lagrange{T, P} implementation
    serendipity.jl           # Serendipity{T, P} (reduced nodes)
    nedelec.jl               # Nedelec{T, P} (edge elements)
    raviart_thomas.jl        # RaviartThomas{T, P} (face elements)
    hermite.jl               # Hermite{T, P} (C1 continuous)
    hierarchical.jl          # Hierarchical{T, P} (p-refinement)
    nurbs.jl                 # NURBS (isogeometric analysis)
    
    # Each basis determines:
    # - Node count (function of topology + polynomial degree)
    # - DOF placement (nodes, edges, faces, interior)
    # - Basis function evaluation
  
  integration/
    gauss.jl        # Gauss-Legendre quadrature
    lobatto.jl      # Gauss-Lobatto quadrature
    reduced.jl      # Reduced integration (underintegration)
    
    # Maps integration scheme + topology → quadrature points
  
  elements/
    element.jl      # Element type definition
    integrate.jl    # Integration loop
    assemble.jl     # Global assembly

**Rationale:**

- Each concern in its own directory
- Clear separation of mathematical concepts
- Easy to find and modify code
- Natural place for new additions (new topology? → `topology/`)

## Mathematical Formulation

### Element Stiffness Matrix

The element stiffness matrix is computed by integrating over the element domain:

$$K^e_{ij} = \int_{\Omega_e} B_i^T D B_j \, dV$$

where:

- $B_i$ = strain-displacement matrix for node $i$ (depends on **basis derivatives**)
- $D$ = material constitutive matrix
- $\Omega_e$ = element domain

### Separation in Implementation

```julia
function element_stiffness(element::Element{T, B, I}) where {T, B, I}
    n = nnodes(element.basis)  # Node count from BASIS, not topology
    ndof = ndofs_per_node(element.basis)
    K = zeros(n * ndof, n * ndof)
    
    # Get integration points from integration scheme + topology
    ips = integration_points(element.integration, element.topology)
    
    for ip in ips
        # Evaluate basis functions (depends on basis scheme)
        N = evaluate_basis(element.basis, ip.ξ)
        dN = evaluate_basis_derivatives(element.basis, ip.ξ)
        
        # Jacobian (depends on topology + actual node coordinates)
        J = jacobian(element.topology, element.connectivity, dN)
        
        # Strain-displacement matrix (depends on basis derivatives)
        B = strain_displacement_matrix(dN, J)
        
        # Integrate using quadrature weight
        K += ip.weight * B' * D * B * det(J)
    end
    
    return K
end

Notice: Each concern is accessed through clean interfaces:

• nnodes(basis) → basis determines node count, NOT topology!
• integration_points(integration, topology) → integration scheme
• evaluate_basis(basis, ξ) → interpolation scheme
• jacobian(topology, connectivity, dN) → geometric mapping

Type-Stability for Performance

With concrete types, the compiler can specialize:

# This becomes a specialized function with no runtime overhead
function element_stiffness(
    element::Element{Triangle, Lagrange{Triangle,1}, Gauss{2}, 3}
)
    # Compiler knows at compile time:
    # - Triangle topology (2D, 3 edges)
    # - 3 nodes (from Lagrange{Triangle, 1})
    # - 3 basis functions (P1)
    # - 3 integration points (Gauss{2} on triangle)
    # - connectivity is NTuple{3, UInt}
    
    # Generated code has:
    # - No branches
    # - No allocations
    # - Vectorized loops
    # - Inlined function calls
end

Performance benefit: 100× speedup compared to runtime dispatch!

Extending the System

Adding a New Topology

# File: src/topology/prism.jl
"""
Prism/Wedge element: triangular cross-section extruded in z-direction.

Parametric domain: Triangle × [-1, 1]
  - (ξ, η) ∈ Triangle (base)
  - ζ ∈ [-1, 1] (height)

Note: Does NOT specify node count! That comes from basis.
"""
struct Prism <: AbstractTopology end

dim(::Prism) = 3

# Parametric domain edges/faces
function edges(::Prism)
    # 9 edges: 3 on bottom, 3 on top, 3 vertical
    return ((1,2), (2,3), (3,1), (4,5), (5,6), (6,4), (1,4), (2,5), (3,6))
end

function faces(::Prism)
    # 5 faces: 2 triangular (top/bottom), 3 quadrilateral (sides)
    return ((1,2,3), (4,5,6), (1,2,5,4), (2,3,6,5), (3,1,4,6))
end

# Standard node placements for common basis functions
function reference_node_positions(::Prism, ::Type{Lagrange{Prism, 1}})
    # 6 nodes for linear (P1)
    return [(-1,0,0), (1,0,0), (0,1,0),   # Bottom triangle
            (-1,0,1), (1,0,1), (0,1,1)]   # Top triangle
end

function reference_node_positions(::Prism, ::Type{Lagrange{Prism, 2}})
    # 18 nodes for quadratic (P2)
    # 6 corners + 9 edge midpoints + 3 face centers
    return [...]  # Full list
end

Usage:

element = Element(Prism(), Lagrange{Prism, 1}(), Gauss{2}(), (1,2,3,4,5,6))
# Automatically works with existing assembly code!

element_p2 = Element(Prism(), Lagrange{Prism, 2}(), Gauss{3}(), 
                      (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18))
# Same topology, quadratic basis → 18 nodes

Adding a New Interpolation Scheme

# File: src/basis/hierarchical.jl
"""
Hierarchical polynomial basis for p-refinement.

Unlike Lagrange (nodal basis), hierarchical basis has:
- Low-order modes at vertices (vertex bubbles)
- Higher-order modes as edge/face/volume bubbles
- Easier adaptivity (can increase P without changing low-order modes)

Node count depends on polynomial degree:
  P=1: same as Lagrange (vertices only)
  P=2: vertices + edge modes
  P=3: vertices + edge modes + face modes + volume modes
"""
struct Hierarchical{T<:AbstractTopology, P} <: AbstractBasis end

# Node count = vertices + edges*(P-1) + faces*(P-1)*(P-2)/2 + ...
nnodes(::Hierarchical{Triangle, 1}) = 3
nnodes(::Hierarchical{Triangle, 2}) = 3 + 3*1 = 6
nnodes(::Hierarchical{Triangle, 3}) = 3 + 3*2 + 1 = 10

# Evaluate basis functions
function evaluate_basis(basis::Hierarchical{Triangle, P}, ξ::Vec) where P
    # Implement hierarchical polynomial evaluation
    # First 3 are vertex functions (same as Lagrange P1)
    # Next modes are edge bubbles, then face bubbles
    return NTuple{nnodes(basis), Float64}(...)  # Zero allocation!
end

# Evaluate basis derivatives
function evaluate_basis_derivatives(basis::Hierarchical{Triangle, P}, ξ::Vec) where P
    # Return tuple of gradients
    return NTuple{nnodes(basis), Vec}(...)
end

Usage:

# Same triangle topology, hierarchical basis instead of Lagrange
element = Element(Triangle(), Hierarchical{Triangle, 3}(), Gauss{4}(), 
                  (1,2,3,4,5,6,7,8,9,10))  # 10 nodes for P3

# Can do p-refinement by just changing basis degree!
element_p2 = Element(Triangle(), Hierarchical{Triangle, 2}(), Gauss{3}(),
                      (1,2,3,4,5,6))

Adding a New Integration Rule

# File: src/integration/lobatto.jl
struct Lobatto{N} <: AbstractIntegration end

function integration_points(scheme::Lobatto{N}, topology::T) where {N, T<:AbstractTopology}
    # Return integration points and weights for Lobatto quadrature
    # Lobatto includes endpoints (useful for spectral methods)
    # Specific to topology dimension
    
    if T === Segment
        # 1D Lobatto points
        return lobatto_1d(N)
    elseif T === Triangle
        # 2D Lobatto-like scheme for triangles
        return lobatto_triangle(N)
    # ... other topologies
    end
end

Usage:

element = Element(Quadrilateral(), Lagrange{Quadrilateral, 1}(), Lobatto{3}(),
                  (1,2,3,4))
# Use Lobatto instead of Gauss for same element!

Compile-Time Guarantees

Type System Enforcement

The type system prevents invalid combinations:

# ✅ Valid: Triangle with P1 Lagrange basis
element = Element(Triangle(), Lagrange{Triangle, 1}(), Gauss{2}(), (1,2,3))

# ✅ Valid: Triangle with P2 Lagrange basis (6 nodes)
element = Element(Triangle(), Lagrange{Triangle, 2}(), Gauss{3}(), 
                  (1,2,3,4,5,6))

# ✅ Valid: Triangle with Nédélec edge elements
element = Element(Triangle(), Nedelec{Triangle, 1}(), Gauss{2}(), (1,2,3))
# Note: 3 nodes, but DOFs are on edges!

# ❌ Compile error: Hexahedron basis on Triangle topology (if enforced)
element = Element(Triangle(), Lagrange{Hexahedron, 1}(), Gauss{2}(), (1,2,3))
# Type mismatch: basis topology must match element topology

# ✅ Valid: Same topology, different integration rules
element1 = Element(Quadrilateral(), Lagrange{Quadrilateral,1}(), Gauss{4}(), 
                    (1,2,3,4))     # Full integration
element2 = Element(Quadrilateral(), Lagrange{Quadrilateral,1}(), Reduced(), 
                    (1,2,3,4))     # Reduced integration
element3 = Element(Quadrilateral(), Lagrange{Quadrilateral,2}(), Gauss{9}(), 
                    (1,2,3,4,5,6,7,8,9))  # Quadratic + more points

Number of Nodes Known at Compile Time

# Connectivity is NTuple{N, UInt} where N is determined by basis, not topology!
struct Element{T, B, I, N}
    topology::T
    basis::B
    integration::I
    connectivity::NTuple{N, UInt}  # N = nnodes(B)
end

# For Lagrange{Triangle, 1}: N = 3
# For Lagrange{Triangle, 2}: N = 6
# For Nedelec{Triangle, 1}: N = 3 (still 3 nodes, DOFs on edges)

# Compiler can unroll loops over connectivity
function process_element(element::Element{T, B, I, N}) where {T, B, I, N}
    for i in 1:N  # N known at compile time
        # Loop is unrolled at compile time!
        node_id = element.connectivity[i]
        # ...
    end
end

Result: Zero-overhead abstractions, same performance as hand-written code.

Backward Compatibility

Migration from Hardcoded Types

# Old Code Aster style (what we're moving away from):
# element_type = "TRIA3"  # Hardcoded node count

# JuliaFEM modern approach:
element = Element(Triangle(), Lagrange{Triangle, 1}(), Gauss{2}(), (1,2,3))

# For transition, provide type aliases:
const TRIA3 = Lagrange{Triangle, 1}
const TRIA6 = Lagrange{Triangle, 2}
const QUAD4 = Lagrange{Quadrilateral, 1}
const QUAD8 = Serendipity{Quadrilateral, 2}
const QUAD9 = Lagrange{Quadrilateral, 2}

# Old code can use aliases:
element = Element(Triangle(), TRIA3(), Gauss{2}(), (1,2,3))

Constructor Convenience

# Convenience constructors for common cases (implicit defaults)
function Element(topology::Triangle, connectivity::NTuple{3, Int})
    # Assume: P1 Lagrange + standard Gauss quadrature
    Element(topology, Lagrange{Triangle, 1}(), Gauss{2}(), 
            UInt.(connectivity))
end

function Element(topology::Triangle, connectivity::NTuple{6, Int})
    # Infer P2 from 6 nodes
    Element(topology, Lagrange{Triangle, 2}(), Gauss{3}(), 
            UInt.(connectivity))
end

# User can still write simple code:
element = Element(Triangle(), (1, 2, 3))  # Defaults to P1 + Gauss{2}

Performance Implications

From Roadmap to HPC

This architectural decision directly supports the five performance principles:

1. Type Stability ✅

   • All element types are concrete
   • No runtime dispatch in hot paths
   • Compiler can optimize aggressively

2. Zero Allocations ✅

   • NTuple{N} for connectivity → stack allocated
   • Integration points known at compile time → no allocation
   • Basis evaluation can return tuples → no Vector allocation

3. Specialization ✅

   • Compiler generates optimized code for each Element{T, B, I}
   • No generic "one size fits all" slow path
   • Each combination gets its own fast implementation

4. Parallelism ✅

   • Element independence enables parallel assembly
   • Topology separation enables graph-based partitioning
   • No shared state between elements

5. GPU Portability ✅

   • Each concern can be ported to GPU independently
   • Small, focused kernels (evaluate basis, integrate, assemble)
   • Type-stable code → CUDA.jl can compile it

Measured Impact

From benchmarks (see docs/book/benchmarks/):

• Before (Dict-based, runtime dispatch): 15 μs per element
• After (type-stable composition): 150 ns per element
• Speedup: 100× faster!

Comparison with Other Libraries

Gridap.jl

Gridap uses a similar separation but with different emphasis:

• Focus on general PDEs, not specifically FEM
• More abstract (CellField, FESpace concepts)
• Great for research, steeper learning curve

JuliaFEM approach: More explicit, educational focus.

Ferrite.jl

Ferrite keeps element types somewhat mixed:

• Element types include both topology and interpolation
• Less flexible mixing-and-matching
• But simpler mental model for beginners

JuliaFEM approach: More flexible, better for advanced users.

Deal.II (C++)

Deal.II has sophisticated separation:

• Template-based (C++ templates)
• Very fast, but complex compilation
• Steep learning curve

JuliaFEM approach: Julia's type system gives similar power without template complexity.

Lessons Learned

What Works

✅ Separation of concerns is worth it

• Initial overhead pays off in maintainability
• Performance benefits are real (100× speedup)
• Users appreciate flexibility

✅ Type system enforcement is powerful

• Catch errors at compile time, not runtime
• Compiler optimizations are dramatic
• Zero-cost abstractions are achievable

✅ Documentation must explain WHY

• Show the Abaqus anti-pattern
• Explain the mathematics
• Provide migration path for old code

What's Hard

⚠️ Forward declarations in Julia

• No forward declarations → careful include order
• See llm/INCLUDE_ORDER_EXAMPLES.md for solutions

⚠️ Balance between flexibility and simplicity

• Too flexible → confusing for beginners
• Too simple → limiting for advanced users
• Solution: Convenience constructors + type aliases

⚠️ Backward compatibility

• Old code expects different API
• Need adapters and deprecation warnings
• Migration guide essential

Conclusion

Element = Topology + Interpolation + Integration + Fields

But with critical insight:

• Topology = geometric shape ONLY (no hardcoded node count!)
• Interpolation = polynomial space + DOF placement (determines node count)
• Integration = numerical quadrature (independent choice)
• Fields = problem-specific data

The Code Aster/Abaqus anti-pattern we avoid:

• ❌ TRIA3, TRIA6, TRIA7, TRIA10 → hardcoded node counts
• ✅ Triangle + Lagrange{Triangle, P} → node count derived from P

Benefits:

• ✅ One topology, infinite possibilities (P1, P2, P3, Nédélec, Raviart-Thomas, ...)
• ✅ Clear separation (geometry ≠ approximation ≠ integration)
• ✅ Type system enforcement (compiler catches mismatches)
• ✅ Zero-cost abstractions (100× performance improvement)
• ✅ Extensible (add new basis without touching topology)
• ✅ Educational (code teaches FEM mathematics correctly)

Key architectural decision:

// ❌ WRONG (Code Aster style)
struct TRIA3 { int nnodes = 3; }  // Hardcoded!

// ✅ CORRECT (JuliaFEM style)
struct Triangle <: AbstractTopology end  // Pure geometry
nnodes(::Lagrange{Triangle, 1}) = 3     // Derived from basis
nnodes(::Lagrange{Triangle, 2}) = 6     // Different basis → different count
nnodes(::Nedelec{Triangle, 1}) = 3      // Edge DOFs, still 3 nodes

Trade-offs:

• ⚠️ More complex type system (but Julia handles it elegantly)
• ⚠️ Requires understanding separation of concerns
• ⚠️ Documentation must be excellent (this document!)

Result: A modern, mathematically correct, high-performance, extensible FEM library that can handle:

• Standard nodal FEM (Lagrange)
• Edge elements (electromagnetics with Nédélec)
• Face elements (fluid flow with Raviart-Thomas)
• Mixed formulations (Taylor-Hood, MINI, ...)
• Isogeometric analysis (NURBS)
• hp-refinement (hierarchical basis)

All with one unified Element type and zero runtime overhead.

---

Further Reading

• llm/ARCHITECTURE.md - Full architecture document
• docs/book/roadmap_to_hpc.md - Performance philosophy
• docs/book/lagrange_basis_functions.md - Lagrange interpolation theory
• docs/contributor/testing_philosophy.md - How we test this design

References

1. Hughes, T.J.R. (2000). The Finite Element Method: Linear Static and Dynamic Finite Element Analysis. Dover. (Classic FEM reference)
2. Wriggers, P. (2006). Computational Contact Mechanics. Springer. (Contact mechanics focus)
3. Abaqus Documentation. (Example of element type proliferation)
4. Gridap.jl Documentation. (Alternative approach to FEM in Julia)
5. Ferrite.jl Documentation. (Another Julia FEM library)
6. Deal.II Documentation. (C++ FEM library with similar separation)