Changes to test/test_elasticity_1d.jl:
- Changed sqrt(3)/2 to sqrt(3) / 2 (added spaces around /)
- Improves code readability and follows Julia style conventions
- No functional change, formatting only
Rewrote test_elasticity_1d.jl to follow immutable element pattern.
This is the first fully working test with the new architecture!
Changes:
1. test/test_elasticity_1d.jl:
- Convert Dict node data to element-local tuple format
- Wrap data in DVTI field objects (Discrete, Variable, Time-Invariant)
- Create element with fields at construction: Element(Seg2, conn; fields=(...))
- Fix Jacobian shape expectation (3×1 not 1×3 for 1D in 3D)
2. src/JuliaFEM.jl:
- Add minimal jacobian() function for AbstractBasis (non-parametric)
- Handles embedding (1D element in 3D space) correctly
- Returns Matrix instead of Tensor for flexibility
3. src/elements/elements.jl:
- Fix Jacobian computation to handle both Tuple and IntegrationPoint
- Fix detJ calculation logic for embedded elements (check m not size(JT,2))
- Correctly handle 1D elements: detJ = ||∂X/∂ξ||
Result: test_elasticity_1d.jl passes! ✓
This validates the immutable architecture:
- Element created with fields at construction
- No mutation needed during test
- Field system integration working (DVTI fields)
- Jacobian computation working for embedded elements
MAJOR PERFORMANCE REFACTORING:
1. Shape functions return tuples instead of allocating vectors:
- eval_basis!(): Returns NTuple{N,T} directly (zero allocations)
- eval_dbasis!(): Returns NTuple{N,Vec{D}} directly (zero allocations)
- API boundary (get_basis/get_dbasis) still returns vectors for compat
2. Element is now immutable with compile-time known structure:
- connectivity: Vector{UInt} → NTuple{N,UInt}
- integration_points: Vector{IP} → NTuple{NIP,IP}
- Element{N,NIP,M,B} parametrized by connectivity/IP count
- Changed from 'mutable struct' to 'struct'
3. Helper function for immutability:
- with_integration_points(element, ips) returns new element
- get_integration_points() returns tuple directly
Benefits:
- Zero allocations in hot paths (basis evaluation)
- Compile-time sizes enable better optimization
- Type stability improvements
- Stack allocation instead of heap
Breaking changes:
- Element.connectivity is now tuple (use collect() for vector)
- Element is immutable (use with_integration_points for updates)
Tests: All 157 tests passing
Major architectural decision: Use Tensors.jl consistently everywhere
for geometric vectors, integration points, and coordinates.
Changes to src/elements/elements.jl:
- get_basis(): Convert ip to Vec, use Vector (not Matrix) for eval_basis!
- get_dbasis(): Convert ip to Vec
- jacobian evaluation: Convert geometry and ip.coords to Vec properly
- Handle both raw coordinates (Tuple) and IP struct transparently
New Tutorial 3: Numerical Integration and Jacobian (49 tests)
- Integration point structure and weights
- Jacobian determinant and matrix evaluation
- Numerical integration (constant, linear, quadratic functions)
- Multiple element types (Quad4, Seg2, Tri3)
Tests: 107 → 156 passing (49 new)
Runtime: ~7 seconds
Closes architectural standardization on Tensors.jl.
Related to Issue #250 (merge conflict resolution).
Why Tensors.jl:
- Type stability (100× performance vs Dict-based)
- Material science compatibility (stress tensors)
- Zero-cost abstractions
- Consistent API across all geometric calculations
Current state discovery:
- Element basis function evaluation broken (eval_basis! signature mismatch)
- Field interpolation at integration points broken (same root cause)
- Jacobian evaluation at integration points broken
- These are fundamental API issues affecting multiple test paths
Impact:
- Tutorial 3 (basis functions) deferred until API fixed
- Affects any code trying to evaluate fields at integration points
- Related to Quad4 assembly issues discovered in Tutorial 4
Working tutorials (107/107 tests passing):
- Tutorial 1: Element creation (5 tests)
- Tutorial 2: Gmsh mesh reading (72 tests)
- Tutorial 4: 1-element validation (35 tests)
Next: Focus on tutorials using working APIs only
Educational validation test for Issue #265 use case (JuliaFEM as reference).
Covers:
- Element creation and connectivity
- Field assignment (geometry, material properties)
- Field retrieval with function call syntax
- Hand-calculated constitutive matrix for plane stress
- Geometry validation (dimensions, center, area)
- Material property validation (physical ranges)
Note: Defers stiffness matrix assembly to future work due to current
Quad4 assembly issues. Focus is on element setup validation that
other FEM developers can use as reference.
Tutorial series now: 107/107 tests passing
- Tutorial 1: Creating elements (5 tests)
- Tutorial 2: Gmsh mesh reading (72 tests)
- Tutorial 4: 1-element validation (35 tests - done before Tutorial 3)
Implement testing philosophy (see docs/TESTING_PHILOSOPHY.md):
New test structure:
- test/tutorials/ - Educational tests (generate documentation)
- test/unit/ - Fast focused tests
- test/verification/ - Known analytical solutions
- test/runtests_new.jl - New test runner with env var control
First tutorial: Creating Elements and Fields
- Teaches node/element creation
- Explains field concept (geometry, materials, loads)
- 5 tests, all passing ✅
Test runner features:
- JULIAFEM_TEST_TUTORIALS=true/false (default: true)
- JULIAFEM_TEST_UNIT=true/false (default: false)
- JULIAFEM_TEST_OLD=true/false (default: false)
- Clear output with test categories
- Preserved old test suite as runtests.jl.old
Results: 5/5 tests passing in <2 seconds
Next: Write 2-3 more fundamental tutorials (mesh reading, 1D elasticity)
Sometimes user may have the wrong kind of elements in element set when
assembling 3d continuum problem. This could happen for example in
situations, where mesher is giving also segment elements. They may have
some use in certain situations, but currently we don't support them.
When assembly is failing for this reasons, we give a meaningful error
message:
[ Info: It looks that you are trying to assemble elements of type Seg3
to 3d continuum problem. However, they are not supported yet. To filter
out elements from a element set, try `filter(element->!isa(element,
Element{Seg3}), elements)`
ERROR: LoadError: Tried to assemble unsupported elements of type Seg3 to
3d continuum problem.
This commit closes issue #211.
The order of the calculated eigenvalues has been changed in the newest
Julia versions. Fixed by sorting the lists before comparison. Closes
issue #232.
* Fix deprecation warnings from tests
* Refactor tests so that ´@testset` is usually called in master file
`runtests.jl`, not inside test file. Later on we can convert tests
to examples.
* Syntax of tests now follow more closely syntax used currently in
JuliaFEM. We have had earlier studies with different kind of syntaxes,
now we have kind of explicit way to do things.
Let's use Literate.jl to automatically generate usage examples.
* Automatically generate documentation from other packages (first try to include each package's docs/src/index.md, but if that fails, then use README.md to introduce the package).
* Add example how to calculate local element matrices.
* Add example how to perform 2d contact analysis.
Development of auto-differentiated mortar contact mechanics in 2D is moved to own separate package, MortarContact2DAD. Other changes are similar to what is done with MortarContact2D: elements are added to problems using `add_slave_elements!` and `add_master_elements!` instead of `add_elements!`, to make interface more explicit. Also, problem name is `Contact2DAD`, so the dimension is now explicitly stated in problem name. (Also have `Mortar2DAD`, compare to the `Mortar2D` and `Contact2D` of `MortarContact2D.jl`.)
Moved plane contact related stuff to own separate package
`MortarContact2D.jl`, where the development continues.
The following changes to test files are done:
1) Problem name for plane mortar coupling is `Mortar2D` (was `Mortar`
before), and later on 3d coupling will be `Mortar`. So the dimension
of coupling operator is explicitly given in a problem name.
2) Before elements to coupling was defined using
```julia
update!(problem.elements, "master elements", master_elements)
add_elements!(problem, [slave_elements; master_elements])
```
Now, explicitly give master and slave elements as
```julia
add_slave_elements!(problem, slave_elements)
add_master_elements!(problem, master_elements)
```
Keep on mind that Lagrange multipliers are in slave side.
Heat transfer analysis is moved to its own package where the development continues. Two small modifications are needed for test files:
- Instead of `problem.properties.formulation`, we have two separate problems, `PlaneHeat` for two-dimensional problems and `Heat` for three-dimensional problems.
- Unnecessary prefixing of field names is changed. For example, now we simply have only "thermal conductivity" and not prefixed "temperature thermal conductivity".
This function can be used to create elements from node set defined
in mesh. Resulting elements are of type Poi1, that is, they don't
have any volume but it's still possible to add boundary conditions
to them which are then enforced in discrete sense.
Jukka Aho