ee02f9f37a
feat: Separation of concerns architecture with zero-allocation foundation
...
**Architecture Decision: Element = Topology + Interpolation + Integration + Fields**
This commit establishes the architectural foundation for separating orthogonal concerns
in finite element implementation, preventing Abaqus-style combinatorial explosion.
## New Modules (Not Yet Integrated)
### src/topology/
Reference element geometries (pure mathematical objects):
- topology.jl: Abstract interface for reference elements
- tri3.jl: 3-node triangle reference element
- quad4.jl: 4-node quadrilateral reference element
**Zero-allocation design:**
- reference_coordinates() → NTuple{N, NTuple{D, Float64}}
- edges() → NTuple{Ne, Tuple{Int, Int}}
- faces() → NTuple{Nf, NTuple{Nn, Int}}
All topology queries return compile-time sized tuples (stack allocated, no heap).
### src/integration/
High-level integration scheme abstraction:
- integration.jl: Abstract types and IntegrationPoint struct
- gauss.jl: Gauss-Legendre quadrature wrapper around existing src/quadrature/
**Zero-allocation design:**
- integration_points() → Tuple{Vararg{IntegrationPoint{D}}}
- IntegrationPoint.ξ → NTuple{D, Float64}
**Key Insight:** Integration rules already exist in src/quadrature/ (consolidated from
FEMQuad.jl). New code is a thin architectural wrapper, not reimplementation.
## Documentation
### docs/book/element_architecture.md (NEW - 650+ lines)
Complete book chapter explaining:
- What is an Element? (composition of 4 orthogonal concerns)
- The Abaqus anti-pattern (C3D8, C3D8R, C3D8I explosion)
- JuliaFEM approach: Topology + Interpolation + Integration separation
- Type system enforcement
- Performance implications (100× speedup from type stability)
- Extending the system (adding new topologies/bases/quadrature)
- Comparison with Gridap.jl, Ferrite.jl, Deal.II
### llm/ARCHITECTURE.md (UPDATED)
Added "Architectural Decision: Separation of Concerns" section at top:
- Problem statement
- Anti-pattern example
- JuliaFEM solution
- Directory structure rationale
- Type system design
- Migration strategy
### scripts/generate_lagrange_basis.jl (UPDATED)
Added architectural context explaining Lagrange bases are INTERPOLATION SCHEMES
(not topologies, not integration rules).
## Performance: Zero-Allocation Foundation
**Why tuples matter:**
1. **Zero heap allocations** - All data stack-allocated
2. **Compile-time sizes** - Compiler can unroll loops
3. **Cache friendly** - Contiguous memory layout
4. **Type stable** - Concrete tuple types enable optimization
5. **Immutable** - No accidental mutation, thread-safe
**Example impact:**
```julia
# Compiler knows at compile time:
# - Tri3 has exactly 3 edges
# - Each edge has exactly 2 nodes
# → Loop unrolling, no bounds checks, SIMD vectorization
for edge in edges(Tri3()) # Tuple iteration, fully unrolled!
node1, node2 = edge
# ... assembly code (zero allocations)
end
```
**Principle from Roadmap to HPC:**
> "Zero allocations in hot paths" - Strategic Decision #2
Topology/integration queries happen billions of times in assembly loops.
Even small Vector allocations accumulate to GC pressure and cache misses.
**Rule:** If size known at compile time → use Tuple, not Vector
## Benefits
✅ Clear separation of mathematical concepts
✅ Mix-and-match: Tri3 + Lagrange + Gauss, Tri3 + Hierarchical + Lobatto, etc.
✅ Type system enforces correctness at compile time
✅ Compiler generates specialized code for each combination → 100× speedup
✅ Zero allocations in topology/integration queries
✅ No code duplication (each concern in one place)
✅ Educational: teaches proper software engineering
## Status
- **NOT YET INTEGRATED**: New modules not included in src/JuliaFEM.jl
- **SAFE**: Package loads successfully (verified with `using JuliaFEM`)
- **READY**: Architecture documented, zero-alloc foundation established
## Next Steps
1. Create remaining topology files (Tet4, Tet10, Hex8, Hex20, etc.)
2. Update src/JuliaFEM.jl to include new modules
3. Refactor existing Element to use new separation
4. Run generation script with new architecture
5. Integrate with existing codebase
## References
- Abaqus documentation (anti-pattern example)
- Gridap.jl (alternative approach)
- Ferrite.jl (mixed approach)
- Deal.II (C++ template approach)
- llm/ROADMAP_TO_HPC.md (performance philosophy)
See: docs/book/element_architecture.md for complete rationale and examples.
2025-11-09 05:46:34 +02:00
1636e255fe
docs: Add YAML front matter to all documentation files
...
**Purpose:** Prepare documentation for publishing as blog posts or book
**YAML Headers Include:**
- title: Document title
- subtitle: Optional subtitle for context
- description: Brief summary for SEO/indexing
- date: Creation date
- updated: Last update date (for status docs)
- author: Jukka Aho
- categories: Taxonomic classification
- keywords: Search/indexing keywords
- audience: Target reader (users/contributors/researchers)
- level: Difficulty level (beginner/intermediate/advanced/expert)
- type: Document type (manual/guide/theory/benchmark/status)
- series: Which manual it belongs to
- chapter: Book structure (for The JuliaFEM Book)
- status: Current state (completed/work in progress/active maintenance)
- math: Whether document contains mathematical notation
- prerequisites: Required background knowledge
- tools: Software/packages used (for benchmarks)
- context: Background information
**Files Updated:**
- docs/README.md (main index)
- docs/user/README.md (user manual index)
- docs/contributor/README.md (contributor manual index)
- docs/book/README.md (book index)
- docs/contributor/testing_philosophy.md
- docs/contributor/status.md
- docs/contributor/test_fixes_needed.md
- docs/book/lagrange_basis_functions.md
- docs/book/benchmarks/shape_function_derivatives_ad_vs_manual.md
- scripts/README.md
**Benefits:**
- Ready for static site generators (Jekyll, Hugo, MkDocs)
- Can generate book with proper metadata
- SEO-friendly with descriptions and keywords
- Clear audience/level targeting
- Trackable with dates and status
- Organized by series and chapters
**Compatible With:**
- Jekyll (GitHub Pages)
- Hugo (fast static site generator)
- MkDocs (Python-based documentation)
- Jupyter Book (interactive books)
- Docusaurus (React-based docs)
- Custom publishing scripts
2025-11-09 04:45:12 +02:00
626266c990
docs: Reorganize documentation into three-tier structure
...
**Three Manuals for Three Audiences:**
1. **User Manual** (docs/user/) - "Just Get It Done"
- For end users, engineers, students
- Simple, practical, step-by-step
- Quick start, tutorials, examples, troubleshooting
- Philosophy: Show me how to solve my problem
2. **Contributor Manual** (docs/contributor/) - "Show Me the Code"
- For developers, contributors, advanced users
- Technical, detailed, design rationale
- Testing, architecture, performance, CI/CD
- Philosophy: Explain HOW and WHY
3. **The JuliaFEM Book** (docs/book/) - "Let Me Show You How I Think"
- For researchers, theory nerds, and Jukka
- Comprehensive, educational, opinionated, personal
- Math foundations, design philosophy, history, research
- Philosophy: Mix theory, code, and personal experience
**Reorganization:**
- Moved: TESTING_PHILOSOPHY.md → contributor/testing_philosophy.md
- Moved: STATUS.md → contributor/status.md
- Moved: TEST_FIXES_NEEDED.md → contributor/test_fixes_needed.md
- Moved: lagrange_basis_functions.md → book/lagrange_basis_functions.md
- Moved: benchmarks/ → book/benchmarks/
- Created: docs/README.md (main index explaining structure)
- Created: README.md in each section explaining audience and contents
- Updated: All references in scripts and source files
**Naming:** All docs now lowercase (testing_philosophy not TESTING_PHILOSOPHY)
**Benefits:**
- Clear separation of concerns
- Users don't get overwhelmed with implementation details
- Contributors get technical depth
- Book preserves deep theory and personal insights
- Each manual optimized for its audience
**Next:** Populate each section with appropriate content
2025-11-09 04:38:28 +02:00
Jukka Aho