Elasticity: add a local buffer struct to preallocate things needed in the assembly loop #220
Conversation
… the assembly loop
|
The creation of this local buffers should probably be moved to somewhere around https://github.com/JuliaFEM/FEMBase.jl/blob/master/src/assembly.jl#L85. |
…sing sparsity pattern in FEMBase.jl
KristofferC
force-pushed
the
kc/local_buffer
branch
from
71cad7d
to
9327587
Compare
|
|
||
| [[FEMBase]] | ||
| deps = ["FEMBasis", "FEMQuad", "LinearAlgebra", "SparseArrays", "Statistics", "Test", "TimerOutputs"] | ||
| path = "../FEMBase" |
There was a problem hiding this comment.
I think we are missing these changes from FEMBase repository
| uuid = "be8e8821-3f6f-54c2-987c-d2773c3a52cb" | ||
| version = "0.2.0" | ||
|
|
||
| [[FEMSparse]] |
There was a problem hiding this comment.
I registered package today and merged pull request
| @@ -319,3 +319,80 @@ function JuliaFEM.Problem(mesh::Mesh, ::Type{P}, name, dimension, parent_field_n | |||
| problem.elements = create_elements(mesh, name) | |||
| return problem | |||
| end | |||
|
|
|||
| """ | |||
There was a problem hiding this comment.
This is merged in another pull request, should be rebased.
|
|
||
| # determine material model | ||
| const u = ([0.0, 0.0, 0.0], [0.0, 0.0, 0.0], [0.0, 0.0, 0.0], [0.0, 0.0, 0.0], [0.0, 0.0, 0.0], [0.0, 0.0, 0.0], [0.0, 0.0, 0.0], [0.0, 0.0, 0.0], [0.0, 0.0, 0.0], [0.0, 0.0, 0.0]) |
There was a problem hiding this comment.
Should not be in final deliverable?
| # calculate stress vector based on material model | ||
| Parameters.@unpack bi, BL, BNL, Km, Kg, f_int, f_ext, f_buffer, f_buffer_dim, gdofs, gradu, strain, | ||
| strain_vec, stress_vec, F, D, Dtan, Bt_mul_D, Bt_mul_D_mul_B, Bt_mul_S = local_buffer | ||
| if !cheating |
There was a problem hiding this comment.
Should not be in final deliverable?
| calculate_stress! = plastic_def["type"] | ||
| yield_surface_ = plastic_def["yield_surface"] | ||
| params = plastic_def["params"] | ||
| if cheating |
There was a problem hiding this comment.
Should not be in final deliverable?
test/test_mesh_coloring.jl
Outdated
| @@ -0,0 +1,20 @@ | |||
| using JuliaFEM, LinearAlgebra, Test | |||
There was a problem hiding this comment.
Accepted in another pull request, should be rebased
|
After looking at this pull request with detail, it looks that some parts of code is missing, which is defining K_csc and f_csc to problem.assembly. Anyway, we should design this so that we have an abstract representation of matrices in Assembly, so that we can just change SparseMatrixCOO -> SparseMatrixCSC and everything works as expected, and not define several different stiffness matrices to Assembly. As a general note, this pull requests is trying to do too many things at once, and commits should have some meaningful description of what they are doing so that they can be merged separately. I tried to rebase this to newest master but lost the idea in the first rebase conflict. As this is still clearly "work in progress" stage, we should rebase commits so that we can pick already working ideas to the master branch. |
| M = problem.assembly.M | ||
| K = problem.assembly.K | ||
| f = problem.assembly.f | ||
| K_csc = problem.assembly.K_csc |
There was a problem hiding this comment.
Here, we should not have several different presentations of stiffness matrix, but instead, have only one and define necessary functions so that code works for both of types?
| @@ -3,7 +3,7 @@ | |||
|
|
|||
| using JuliaFEM, Test | |||
|
|
|||
| include("../docs/make.jl") | |||
| # include("../docs/make.jl") | |||
There was a problem hiding this comment.
This is fixed in later PR, should be rebased. And I think it's not the subject of this pull request anyway.
| @@ -25,8 +25,8 @@ update!(element, "geometry", X) | |||
| update!(element, "displacement", u) | |||
| problem = Problem(Elasticity, "tet10", 3) | |||
| add_element!(problem, element) | |||
| time = 0.0 | |||
| assemble!(problem, time) | |||
| ttime = 0.0 | |||
There was a problem hiding this comment.
Probably a good idea which should be cherry-picked and merged separately.
@KristofferC do you agree with @ahojukka5's comment here? I would need to get this merged. What would be the minimum energy principle to get there? |
This is one step towards #219 where we need to preallocate all the local buffers that each thread will use. This makes that simpler.