mirror of
https://github.com/JuliaFEM/JuliaFEM.jl.git
synced 2026-09-01 08:46:23 +00:00
Jukka Aho
fb732efd1b
- Relocate docs/contributor/ to docs/src/contributor/ - Add three GPU quickstart guides (renamed from UPPERCASE to snake_case): - gpu_elasticity_quickstart.md - gpu_nodal_assembly_quickstart.md - quick_reference_gpu.md - Part of three-tier docs reorganization following Documenter.jl standard - All files now under docs/src/ for automatic rendering
title, description, date, author, categories, keywords, audience, level, type
| title | description | date | author | categories | keywords | audience | level | type | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| JuliaFEM Contributor Manual | Technical guide for developers and contributors | 2025-11-09 | Jukka Aho |
|
|
developers | advanced | manual |
Audience: Developers, contributors, advanced users who want to extend or modify JuliaFEM.
This manual is technical and detailed - it explains HOW the code works and WHY we made certain design choices.
What's Here
- Testing Philosophy: How and why we test
- Coding Standards: Required conventions for all contributions (variable names, types, performance)
- Architecture: Module structure, data flow, key abstractions
- Performance: Zero-allocation design, profiling, benchmarking
- Adding Elements: How to implement new element types
- CI/CD: Continuous integration, releases, versioning
- Git Workflow: Branching, commits, pull requests
What's NOT Here
- User tutorials (see
docs/user/for that) - Deep mathematical theory (see
docs/book/for that) - "How do I solve problem X?" (that's user docs)
Philosophy
"Show me the code AND tell me why."
We assume you:
- Know Julia reasonably well
- Understand FEM basics
- Want to add features or fix bugs
- Care about performance and correctness
- Need to understand design rationale
Before Contributing
- Read Testing Philosophy
- Follow Coding Standards - REQUIRED for all contributions
- Understand Architecture
- Check Performance Guidelines
- Review Git Workflow
Key Principles
- Type stability: No
Any, noDictwithout types - Zero allocations: Hot paths should allocate nothing
- Immutability: Prefer
structovermutable struct - Composition: Use tuples and free functions, not OOP hierarchies
- Explicit: No magic, user knows what happens
- Test first: Write tests before fixing bugs
Start here: Testing Philosophy | Architecture Overview