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".
matplotlib cannot be installed during the generation of documentation,
ssl error. Use static images in documentation instead of automatically
generated ones.
Core functionality is moved to base package called FEMBase.jl. The
aim is that when developing new elements, solvers, materials and so on,
user only imports FEMBase.jl and uses the functionality there.
JuliaFEM.jl is a sort of "metapackage" collecting together all the
packages and features can be programmed in smaller packages focusing
only on one thing. This structure makes it attractive to contribute
smaller amount of code e.g. in the form of thesis. Moreover, FEMBase.jl
is under 2000 lines of code, which will be very clearly documented thus
everyone can understand the basic concepts behing JuliaFEM easily.
Mass matrix can be analytically solved if Tet10 metric is constant, i.e.
the midnodes are in the midpoint of corner nodes. This should increase
assembling speed of mass matrix.
Slicing is very expensive operation on sparse matrices. Avoid slicing
by calculating matrix product `K_red = C1*K*C1`, where C1 is diagonal
matrix. This should be much cheaper.
Now style is to assemble all same kind/dimension elements at same time
in one function call, so it's possible to allocate all necessary
matrices only one time.
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.
Problem arises typically when boundary condition is created using
"nodal" elements of type Poi1, but forget to define geometry and
```solvers("geometry", 0.0)``` fails in Xdmf update function. Fixed.
Jukka Aho