Files
JuliaFEM.jl/docs/book
Jukka Aho be076d968a docs(book): Add concise type-stability rationale for field storage
Create 299-line focused design rationale explaining why type stability is essential
for CPU/GPU/MPI performance, without mandating specific storage patterns.

Executive summary (lines 16-26):
- v0.5.1 Dict{String,Any}: 9-92× performance degradation
- Type-unstable code CANNOT run on GPUs
- Significant MPI communication overhead
- Document does NOT prescribe storage location
- Demonstrates why type stability at access points is essential
- Key: Storage pattern matters less than type inference

Problem analysis (lines 28-67):
- Type instability definition: Runtime dispatch when type unknown at compile time
- Why it matters: 10-100× slower CPU, GPU compilation fails, MPI serialization
- Measured impact table: 9-92× speedup, 0 allocations with type stability
- Critical: Zero allocations required for GPU kernels

Design requirements (lines 69-136):
1. Type stability at access points (compiler must infer types)
   - Fields could be element-local, global arrays, or arguments
   - Access pattern must be type-stable regardless
2. Zero allocations in hot paths (GPU/MPI requirement)
   - Assembly loop must allocate nothing
3. Contiguous memory layout (GPU/MPI optimization)
   - CUDA transfers contiguous arrays directly
4. Immutable where possible (safe parallelism)
   - Thread-safe reads without locks

Demonstrated solutions (lines 138-201) - EXAMPLES, not mandates:
1. NamedTuple container: Simple, type-stable, immutable
2. Struct with typed fields: Explicit, self-documenting
3. Passed as arguments: Maximum type stability, explicit dependencies
- All three achieve type stability
- Choice depends on use case, not performance

GPU and MPI rationale (lines 203-237):
- GPU execution: CUDA requires all code type-stable
- Mock demonstration in benchmarks/gpu_mpi_mock.jl
- MPI communication: Typed arrays use fast memcpy vs slow serialization
- Type stability enables identical code for CPU/GPU

Recommendations (lines 239-256):
- Use type-stable access patterns (REQUIRED)
- Prefer immutable data structures (threading/GPU)
- Pre-allocate caches (zero allocations)
- Use contiguous arrays (GPU/MPI transfer)
- Profile with @btime (verify zero allocations)
- Does NOT mandate: Storage location, container type, dynamic vs static

Validation (lines 258-275):
- benchmarks/field_storage_comparison.jl: 9-92× CPU speedup
- benchmarks/gpu_mpi_mock.jl: GPU/MPI patterns
- benchmarks/VALIDATION_RESULTS.md: Summary table

Conclusion (lines 277-299):
- Type stability is fundamental requirement, not implementation detail
- Enables: High CPU performance, GPU execution, efficient MPI, safe threading
- v1.0 must ensure type stability at access points
- Storage pattern is secondary concern (memory, cache, API)
- Next steps: Review, benchmark, choose pattern, implement, validate CUDA

Key difference from v1: Shorter (299 vs 1114 lines), focused on WHY not HOW,
explicitly states storage pattern is flexible, emphasizes GPU/MPI requirements.

Platform: Julia 1.12.1, November 9, 2025
Series: The JuliaFEM Book, Chapter 5
Status: Design rationale with validated measurements
2025-11-09 11:10:37 +02:00
..

title, subtitle, description, date, author, categories, keywords, audience, level, type, status
title subtitle description date author categories keywords audience level type status
The JuliaFEM Book A comprehensive manual mixing theory, software design, and personal experience Deep dive into FEM theory, design philosophy, and research directions 2025-11-09 Jukka Aho
theory
research
philosophy
fem theory
contact mechanics
design philosophy
research
researchers and theory enthusiasts expert book work in progress

The JuliaFEM Book

Audience: Advanced researchers, theory nerds, those who want to understand the "why" and "how" at a deep level. And Jukka.

This is the JuliaFEM Bible - a comprehensive manual mixing theory, philosophy, software design, and personal experience. It's educational, opinionated, and unapologetically deep.

What's Here

  • Mathematical Foundations: Lagrange basis functions, weak forms, contact mechanics
  • Design Philosophy: Why JuliaFEM exists, what problems it solves (and doesn't)
  • Technical Vision: Strategic mistakes from 2015-2019, lessons learned
  • Research Directions: Experimental ideas (nodal assembly, matrix-free, etc.)
  • Personal Notes: The journey, the failures, the "aha!" moments
  • Theory + Code: How mathematics becomes software

What's NOT Here

  • "How do I install?" (see docs/user/)
  • "How do I add a feature?" (see docs/contributor/)
  • Short answers (everything here is DEEP)

Philosophy

"Let me show you how I think about FEM."

This is:

  • Educational: Teach FEM through implementation
  • Personal: Written in Jukka's voice, reflecting 8+ years of experience
  • Opinionated: Strong views on what works and what doesn't
  • Comprehensive: From first principles to cutting-edge research
  • Honest: Documents failures as much as successes

We assume you:

  • Love mathematics AND programming
  • Want to understand WHY, not just HOW
  • Have time to read deeply
  • Are curious about unconventional approaches
  • Might be me, 5 years from now, trying to remember why I did this

Structure

Part I: Foundations

  • Finite Element Method (brief review)
  • Lagrange Basis Functions (deep dive)
  • Assembly and Solving
  • Contact Mechanics

Part II: Software Design

  • Type Stability and Performance
  • Zero-Allocation Design
  • Immutability and Composition
  • Field System Architecture

Part III: History and Vision

  • Strategic Mistakes (2015-2019)
  • Why JuliaFEM is Different
  • Contact Mechanics Focus
  • Laboratory Philosophy

Part IV: Research

  • Nodal Assembly (experimental)
  • Matrix-Free Methods
  • Automatic Differentiation
  • GPU Acceleration

Part V: The Journey

  • Personal Reflections
  • Lessons Learned
  • Future Directions
  • Open Questions

Reading Guide

  • For Theory: Start with Part I
  • For Design Rationale: Start with Part II
  • For History: Start with Part III
  • For Research Ideas: Start with Part IV
  • For Philosophy: Read Part V first, then everything else

Start here: Mathematical Foundations | Strategic Mistakes | Why JuliaFEM?