New structure:
- src/io/io.jl: IO submodule definition and exports
- src/io/aster_reader.jl: Code Aster .med reader (ready for HDF5 extension)
Benefits:
- Clean separation of I/O code
- ABAQUS reader works with stdlib only
- Ready for package extensions (HDF5, LightXML)
- Easy to add new formats (VTK, Gmsh, etc.)
The IO submodule exports abaqus_read_mesh() to main JuliaFEM namespace.
Integrated minimal symbolic differentiation from SymDiff.jl by Jukka Aho:
- differentiate(): Symbolic derivatives for polynomials (+, -, *, /, ^)
- simplify(): Expression simplification with numeric evaluation
- Zero external dependencies for basis function generation!
Changes:
- src/basis/create_basis.jl: Added differentiate() and simplify()
- src/basis/subs.jl: Added local simplify with numeric evaluation
- src/basis/abstract.jl: Removed Calculus import
This replaces the Calculus.jl dependency with ~100 lines of pure Julia
code specifically designed for polynomial basis functions.
- Added 118 lines of heat transfer code to src/problems_heat.jl
- Problem types: Heat (3D), PlaneHeat (2D)
- Fields: thermal conductivity, heat source, heat flux, convection
- Fixed Element type signatures (Element{M,B})
- NOTE: Tests currently failing due to element_info! API mismatch
- Will fix after more consolidations (old FEMBase 0.x API)
Result: 9 vendor packages consolidated (~6620 lines total)
Tests: 5 passing baseline maintained (heat tests need API fix)
CRITICAL FIX: Base function imports must come BEFORE any includes that define methods.
Problem:
- Had 'import Base: getindex, setindex!, ...' AFTER including files
- This caused "import conflicts with existing identifier" warnings
- Our getindex/setindex! methods were NOT extending Base, they were standalone
- Result: Dict{Int, Vector} getindex failed completely
Solution:
- Moved all Base imports to module top, right after 'module JuliaFEM'
- Now all our methods properly extend Base functions
- Removed duplicate imports later in file
Result:
- ✅ 5 TESTS PASSING! (back to baseline)
- ✅ Core API works: Element creation, Problem creation, field updates
- ✅ test_mortar_3d_polygon_clip.jl passes all 5 tests
- ⚠️ 43 tests still error (but core functionality proven)
This was the root cause of test regression
Removed all vendor package imports to make JuliaFEM standalone:
- Commented out: HeatTransfer, FEMBeam, MortarContact2D, MortarContact2DAD
- Commented out: AbaqusReader, AsterReader
- These will be consolidated later or remain as vendor archives
Philosophy shift: Focus solely on making JuliaFEM.jl work standalone
- No need for backward compatibility with abandoned vendor packages
- Vendor packages are archaeological artifacts, not dependencies
Result:
- ✅ JuliaFEM still loads successfully
- ✅ Exports reduced to 122 symbols (down from 134)
- Tests status unchanged (still investigating core issues)
Next: Fix actual code issues, not vendor compatibility
Added deprecated_fembase.jl with legacy methods that tests and user code depend on:
- length(element): Returns number of nodes in element
- size(element): Returns (dim, nnodes)
- getproperty override: Maps element.fields → element.dfields
Bug fix:
- Changed sym == :fields to sym === :fields in getproperty
- Reason: fields.jl overrides == operator, breaking normal Symbol comparisons
- This is a known issue (Code Smell documented in Phase 4 plan)
Result:
- ✅ Element length() works correctly
- ✅ Basic element operations functional
- ⚠️ Test suite still has 44 errors (investigating other API mismatches)
Next: Investigate remaining test failures, likely more API incompatibilities
- Add Tensors and Calculus to Project.toml dependencies
- Add basis includes to src/JuliaFEM.jl (Phase 1 integration)
- Fix FEMBasis. namespace references → use JuliaFEM namespace
- Update create_basis.jl: AbstractBasis (not FEMBasis.AbstractBasis)
Status: Basis files load, but conflict with FEMBase expectations
Next: Need to consolidate FEMBase or work around AbstractElement type constraints
This is expected during consolidation - we're bridging two systems.
- Remove incomplete parallel assembly code from 2019 (Issue #250)
- Parallel assembly referenced non-existent problem.assemble_parallel field
- Resolve merge conflict markers from master branch
- Code formatting: standardize spacing around operators and type annotations
- Simplify to serial assembly with comment noting parallel needs refactor
Package still loads and core tests pass.
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.
Improve performance in elasticity by moving out the computation of X from the integration point loop.
Before:
```
12.576967 seconds (37.65 M allocations: 1.852 GiB, 11.65% gc time)
```
After:
```
11.251927 seconds (35.27 M allocations: 1.692 GiB, 11.27% gc time)
```
2 million allocations less.
Store element connectivity as "Mixed" format to Xdmf file. It's a long
list where first number is element code and then there is connectivity
data (starting from 0). Xdmf format does not support several
Topology-elements in Xml file format, so before it was not possible to
store e.g. both Tri3 and Quad4 elements in same problem. After this
commit this should now be possible. Paraview Xdmf3 reader is needed to
use.
Use FEMBeam.jl to solve beam problems. Added an example, where
natural frequencies of frequencies of 3d frame structure are
calculated. Some minor modifications to Modal analysis is done to make
Xdmf writing of 6 dof nodes work.
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".
Jukka Aho