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

Lots of stuff... #125

Merged
merged 44 commits into from
Apr 4, 2017
Merged

Lots of stuff... #125

merged 44 commits into from
Apr 4, 2017

Conversation

KristofferC
Copy link
Collaborator

No description provided.

@fredrikekre
Copy link
Member

Nice, possible to extract renaming commits to another PR and merge that?

@KristofferC
Copy link
Collaborator Author

Yes

@KristofferC KristofferC changed the title WIP make faces better Lots of stuff... Mar 23, 2017
@KristofferC
Copy link
Collaborator Author

Sorry for the mess... I will try to fix it up later. The interesting changes right now are the following:

  • Fix so looping over faces is more natural
  • Add a DofHandler type
  • Add a DirichletBoundaryCondition type.
  • Add a create_sparsity_pattern function that creates the sparsity pattern from a dofhandler.
  • Add a new assembler type that takes a sparse matrix and efficiently assemble into it.
  • Create a function apply! that modifies the stiffness matrix and optionally the force vector so that K \ f solves the system including boundary conditions.

Everything is showed in the committed cantilevel.ipynb notebook.

@codecov-io
Copy link

codecov-io commented Mar 23, 2017

Codecov Report

Merging #125 into master will decrease coverage by 0.9%.
The diff coverage is 84.16%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #125      +/-   ##
==========================================
- Coverage   88.81%   87.91%   -0.91%     
==========================================
  Files          14       17       +3     
  Lines         948     1274     +326     
==========================================
+ Hits          842     1120     +278     
- Misses        106      154      +48
Impacted Files Coverage Δ
src/Quadrature/quadrature.jl 93.33% <ø> (ø)
src/Quadrature/gaussquad_tri_table.jl 100% <ø> (ø)
src/Quadrature/gaussquad_tet_table.jl 100% <ø> (ø)
src/deprecations.jl 0% <ø> (ø) ⬆️
src/interpolations.jl 100% <100%> (ø) ⬆️
src/utils.jl 100% <100%> (ø)
src/Export/VTK.jl 77.5% <100%> (ø)
src/FEValues/face_values.jl 100% <100%> (ø)
src/FEValues/cell_values.jl 100% <100%> (ø)
src/Grid/grid.jl 37.5% <37.5%> (ø)
... and 16 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 102cbb1...4c1a176. Read the comment docs.

# Adds a boundary condition
function add!(dbcs::DirichletBoundaryConditions, field::Symbol,
nodes::Union{Set{Int}, Vector{Int}}, f::Function, components::Vector{Int})
field in dbcs.dh.field_names || error("field $field did not exist in the dof handler, exisitng fields are $(dh.field_names)")
Copy link
Member

Choose a reason for hiding this comment

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

existing

end

CellVectorValues{dim, FIP <: Interpolation, GIP <: Interpolation}(quad_rule::QuadratureRule{dim}, func_interpol::FIP, geom_interpol::GIP=func_interpol) =
function CellVectorValues{dim}(quad_rule::QuadratureRule{dim}, func_interpol::Interpolation, geom_interpol::Interpolation=func_interpol)
Copy link
Member

Choose a reason for hiding this comment

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

might as well remove dim parameter here too

"name": "stderr",
"output_type": "stream",
"text": [
"\u001b[1m\u001b[34mINFO: Recompiling stale cache file /home/kristoffer/.julia/lib/v0.5/JuAFEM.ji for module JuAFEM.\n",
Copy link
Member

Choose a reason for hiding this comment

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

👍

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Argh!

@KristofferC
Copy link
Collaborator Author

I dunno why 0.5 is so slow for hyper elasticity...

@KristofferC
Copy link
Collaborator Author

Everything is like super slow on 0.5... Stiffness example takes 1.6s on 0.6 and 45s on 0.5...

@fredrikekre
Copy link
Member

It's probably Ferrite-FEM/Tensors.jl#19

@KristofferC
Copy link
Collaborator Author

Ah.. yeah.

@KristofferC
Copy link
Collaborator Author

Maybe we should revert it... and just add it to a 0.6 only release later? It makes things pretty unusable on 0.5

@fredrikekre
Copy link
Member

It's a non-trivial revert at this point. Perhaps just checkout an old commit of Tensors when testing on 0.5?

@fredrikekre
Copy link
Member

---------------------------------------------------------------------------

                                    Time                   Allocations      

                            ----------------------   -----------------------

      Tot / % measured:          2373s / 99.9%           68.9GiB / 99.9%    

 Section            ncalls     time   %tot     avg     alloc   %tot      avg

 ---------------------------------------------------------------------------

 assemble                6    2354s  99.3%    392s   64.5GiB  93.7%  10.8GiB

   inner assemble    30.0k    2349s  99.0%  78.3ms   64.3GiB  93.4%  2.20MiB

 linear solve            5    17.7s  0.75%   3.54s   4.33GiB  6.28%   886MiB

 export                  1   40.9ms  0.00%  40.9ms   3.49MiB  0.00%  3.49MiB

 ---------------------------------------------------------------------------

such performance 40 min assemble

@KristofferC
Copy link
Collaborator Author

I think it is because inlining is disabled on 0.5?

@fredrikekre
Copy link
Member

How come?

@KristofferC
Copy link
Collaborator Author

Because on 0.5 Pkg.test disables inlining because otherwise coverage got bad.

@KristofferC
Copy link
Collaborator Author

@fredrikekre
Copy link
Member

Oh okay. Perhaps just run the notebooks on 0.6 then, consider them doctests which we also only run on 0.6?

@KristofferC
Copy link
Collaborator Author

Yes, that sounds ok!

Copy link
Member

@fredrikekre fredrikekre left a comment

Choose a reason for hiding this comment

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

merge?

@fredrikekre
Copy link
Member

Easier to fix small things later than to do more on this branch imo

@KristofferC
Copy link
Collaborator Author

Yes, I agree

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.

3 participants