mirror of
https://github.com/JuliaFEM/JuliaFEM.jl.git
synced 2026-09-09 12:42:19 +00:00
Jukka Aho
c65abfa5cc
**Purpose:** Comprehensive justification for all technical decisions prioritizing
performance over convenience.
**Key Principles:**
- Efficiency > Educativeness (when forced to choose)
- Type stability over everything (100× performance difference)
- No free lunch - Julia doesn't make miracles
- HPC requires discipline and trade-offs
**Core Decisions Justified:**
1. **No Dynamic Field System**
- field["foo"] = x is 100× slower (Dict{String,Any})
- Type-stable structs only
- Sacrifice: Runtime flexibility
- Gain: Performance
2. **Immutable Data Structures**
- struct over mutable struct
- Sacrifice: Convenient mutation
- Gain: 2-10× speedup, thread-safety, stack allocation
3. **NTuple Over Vector**
- Compile-time size → SIMD optimization
- Sacrifice: Dynamic sizing
- Gain: Zero allocations, type stability
4. **Monolithic Over Multi-Package**
- Learned from 2015-2019 mistake
- Sacrifice: Small dependencies
- Gain: It actually works
5. **Manual Derivatives (hot paths)**
- 30× faster than AD for Tet10
- Sacrifice: More code
- Gain: Assembly loops stay fast
6. **Matrix-Free Methods**
- Design for 1M+ DOF from day 1
- Cannot retrofit later
7. **Explicit Over Implicit**
- No magic, show the steps
- Debuggable and teachable
**Hierarchy of Values:**
1. Correctness
2. Performance
3. Maintainability
4. Educativeness
5. Convenience
**What We're Giving Up:**
- Runtime flexibility (no element["custom_field"])
- Dynamic problem definition (no runtime topology changes)
- Duck typing convenience
- Small dependencies
- Beginner-friendly magic
**What We're Getting:**
- 10× single-thread speedup target
- 1M DOF contact problems
- Thread/GPU/distributed scalability
- Real HPC capability
**The Hard Truth:**
From Issue #266: "Do like Python, be slow like Python. Know what you do
before compiling, and be fast like C. There's no free lunch."
**Success Metrics:**
- ✅ Zero allocations in assembly
- ✅ Type-stable hot paths
- 🎯 10× faster than v0.5.1
- 🎯 1M DOF in < 1 hour
- 🎯 100+ thread scaling
**Use Cases:**
- "Why can't I use Dict?" → Point here
- "Why immutable?" → Point here
- "Why manual derivatives?" → Point here
- Any "why not convenience?" → Point here
**Status:** Living document, updated as we learn
See: Issue #266, TECHNICAL_VISION.md, benchmark results
title, description, date, author, categories, keywords, type
| title | description | date | author | categories | keywords | type | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| JuliaFEM Documentation | Three-tier documentation structure for users, contributors, and researchers | 2025-11-09 | Jukka Aho |
|
|
index |
JuliaFEM Documentation
Welcome! JuliaFEM documentation is organized into three manuals for three different audiences:
📘 User Manual - "Just Get It Done"
For: End users, engineers, students who want to run simulations.
Style: Simple, practical, step-by-step.
Contents:
- Quick start and installation
- Tutorials and examples
- API reference
- Troubleshooting
Philosophy: Show me how to solve my problem, skip the lectures.
👉 Start Here if you want to run simulations.
🔧 Contributor Manual - "Show Me the Code"
For: Developers, contributors, advanced users who want to extend JuliaFEM.
Style: Technical, detailed, design rationale.
Contents:
- Testing philosophy
- Code style and architecture
- Performance guidelines
- How to add elements
- CI/CD and git workflow
Philosophy: Explain HOW the code works and WHY we made these choices.
👉 Start Here if you want to contribute code.
📖 The JuliaFEM Book - "Let Me Show You How I Think"
For: Advanced researchers, theory nerds, those who want to understand deeply. And Jukka.
Style: Comprehensive, educational, opinionated, personal.
Contents:
- Mathematical foundations (Lagrange basis, contact mechanics, etc.)
- Design philosophy and technical vision
- Strategic mistakes and lessons learned (2015-2019)
- Research directions (nodal assembly, matrix-free, etc.)
- Personal reflections on the journey
Philosophy: Mix theory, software design, and personal experience. Teach FEM through implementation.
👉 Start Here if you love deep dives and want to understand the "why" behind everything.
Quick Navigation
I want to...
- Solve a heat transfer problem → User Manual
- Add a new element type → Contributor Manual
- Understand Lagrange basis functions → Book: Lagrange Basis
- Learn about testing → Contributor: Testing Philosophy
- See benchmark results → Book: Benchmarks
- Understand the design philosophy → Book: Philosophy
- Report a bug → GitHub Issues
- Ask a question → GitHub Discussions
Documentation Philosophy
Why Three Manuals?
Different readers have different needs:
- Users don't care about implementation details - they just want working code.
- Contributors need technical depth but not necessarily all the theory.
- Researchers (and Jukka) want to understand everything from first principles.
Mixing these audiences in one manual makes it too complex for users and too shallow for researchers.
Design Principles
- User Manual: Optimize for time-to-first-result
- Contributor Manual: Optimize for correctness and maintainability
- Book: Optimize for understanding and education
Cross-References
Manuals link to each other when appropriate:
- User manual links to theory when deeper understanding helps
- Contributor manual links to book for design rationale
- Book links to code examples and practical guides
Contributing to Documentation
Documentation improvements are always welcome!
- User docs: Fix errors, add examples, improve clarity
- Contributor docs: Update for new features, clarify architecture
- Book: Add theory, share insights, document research
See Contributor Manual for guidelines.
License: MIT (same as code)
Questions? Open an issue or discussion on GitHub