Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More efficient way of creating condensed sparsity pattern #436

Merged
merged 2 commits into from
Oct 5, 2022

Conversation

lijas
Copy link
Collaborator

@lijas lijas commented Mar 8, 2022

Creating the sparsity pattern with affine constraints was extremely slow.

grid = generate_grid(Quadrilateral, (300,300))

dh = DofHandler(grid)
push!(dh, :u, 2)
close!(dh);

ch_periodic = ConstraintHandler(dh);
periodic = PeriodicDirichlet(
    :u,
    ["left" => "right", "bottom" => "top"],
    [1, 2]
)
add!(ch_periodic, periodic)
close!(ch_periodic)
update!(ch_periodic, 0.0)

@time K = create_sparsity_pattern(dh, ch_periodic)
Before:  11.439089 seconds (239.59 k allocations: 355.780 MiB, 0.22% gc time)
Now:       0.244780 seconds (181.27 k allocations: 411.271 MiB, 10.16% gc time)

A lot of %gc time still which I dont understand

@lijas lijas requested a review from fredrikekre March 8, 2022 13:18
@codecov-commenter
Copy link

codecov-commenter commented Mar 8, 2022

Codecov Report

Base: 91.37% // Head: 92.00% // Increases project coverage by +0.63% 🎉

Coverage data is based on head (e17d09c) compared to base (98284bb).
Patch coverage: 95.91% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##           master     #436      +/-   ##
==========================================
+ Coverage   91.37%   92.00%   +0.63%     
==========================================
  Files          22       22              
  Lines        3258     3703     +445     
==========================================
+ Hits         2977     3407     +430     
- Misses        281      296      +15     
Impacted Files Coverage Δ
src/Dofs/MixedDofHandler.jl 86.39% <75.00%> (-0.68%) ⬇️
src/Dofs/ConstraintHandler.jl 93.27% <100.00%> (+0.93%) ⬆️
src/Dofs/DofHandler.jl 89.16% <100.00%> (+5.65%) ⬆️
src/Grid/grid.jl 86.94% <0.00%> (-0.27%) ⬇️
src/utils.jl 100.00% <0.00%> (ø)
src/PointEval/PointEvalHandler.jl 92.69% <0.00%> (+0.08%) ⬆️
src/assembler.jl 98.46% <0.00%> (+0.11%) ⬆️
src/Grid/coloring.jl 92.43% <0.00%> (+0.12%) ⬆️
src/Export/VTK.jl 91.37% <0.00%> (+0.15%) ⬆️
... and 4 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

src/Dofs/DofHandler.jl Outdated Show resolved Hide resolved
src/Dofs/ConstraintHandler.jl Outdated Show resolved Hide resolved
src/Dofs/ConstraintHandler.jl Outdated Show resolved Hide resolved
src/Dofs/DofHandler.jl Outdated Show resolved Hide resolved
src/Dofs/ConstraintHandler.jl Outdated Show resolved Hide resolved
src/Dofs/DofHandler.jl Outdated Show resolved Hide resolved
src/Dofs/MixedDofHandler.jl Outdated Show resolved Hide resolved
src/Dofs/MixedDofHandler.jl Outdated Show resolved Hide resolved
src/Dofs/MixedDofHandler.jl Outdated Show resolved Hide resolved
@fredrikekre fredrikekre merged commit 8a7a499 into master Oct 5, 2022
@fredrikekre fredrikekre deleted the eb_condense branch October 5, 2022 11:45
# Store linear constraint index for each constrained dof
distribute = Dict{Int,Int}(acs[c].constrained_dof => c for c in 1:length(acs))

#Adding new entries to K is extremely slow, so create a new sparsity triplet for the condensed sparsity pattern
N = length(acs)*2 # TODO: Better size estimate for additional condensed sparsity pattern.
I = Int[]; resize!(I, N)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could use sizehint! here instead and then use push! instead of setindex!.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, and perhaps in _create_sparsity_pattern() aswell? How much does push! Grow the vector if it grows beyond the size hint?

fredrikekre added a commit that referenced this pull request Nov 25, 2022
This patch removes some unnecessary allocations of a sparse matrix
column which was needed before when the sparse matrix changed in-place.
Since #436 we create a new matrix for the new entries and then add them
in the end instead.
fredrikekre added a commit that referenced this pull request Nov 27, 2022
…#537)

This patch removes some unnecessary allocations of a sparse matrix
column which was needed before when the sparse matrix changed in-place.
Since #436 we create a new matrix for the new entries and then add them
in the end instead.
fredrikekre added a commit that referenced this pull request Dec 10, 2022
After #436 the condensation of the pattern is done by creating a new
matrix which is added to the original matrix. Before this patch there is
still a check for whether each new entry already exist in the original
matrix before adding it to the new matrix. With the new approach
implemented in #436 this seems unnecessary and this patch removes the
check. This also removes some extra complexity from the code.

A datapoint, which support this, is the Stoke's flow example in the
documentation. In that problem, the condensation adds 32k new entries,
of which 30k are new, and 2k exist in the original matrix. Checking
whether the 32k elements exist is much more expensive than simply
including the extra 2k entries in the new matrix. The new approach
reduces the time for creating the combined matrix from 4ms to 3.2ms.

Matrix creation isn't a bottleneck by any means, but it is nice to see
that we with simpler code also get better performance.
fredrikekre added a commit that referenced this pull request Dec 11, 2022
After #436 the condensation of the pattern is done by creating a new
matrix which is added to the original matrix. Before this patch there is
still a check for whether each new entry already exist in the original
matrix before adding it to the new matrix. With the new approach
implemented in #436 this seems unnecessary and this patch removes the
check. This also removes some extra complexity from the code.

A datapoint, which support this, is the Stoke's flow example in the
documentation. In that problem, the condensation adds 32k new entries,
of which 30k are new, and 2k exist in the original matrix. Checking
whether the 32k elements exist is much more expensive than simply
including the extra 2k entries in the new matrix. The new approach
reduces the time for creating the combined matrix from 4ms to 3.2ms.

Matrix creation isn't a bottleneck by any means, but it is nice to see
that we with simpler code also get better performance.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants