Linear constraints #401
Linear constraints #401
Conversation
|
Looks cool! Just a quick question here again, anything wrong with using the maps returned by __close! to identify the dofs? |
|
For node dofs that should work fine i think. But regarding the dofs, I am thinking about adding some dof-tools to get dof-ids on faces/nodes. |
|
Maybe some refactoring of the code in the |
|
given a face and/or edge you should still be able to figure out the corresponding dofs with those dicts https://github.com/Ferrite-FEM/Ferrite.jl/blob/master/src/Dofs/DofHandler.jl#L281 But we throw them away everytime we call |
|
I dont think the facedict from close! can be used... It stores (thee) nodeids of the faces, but usually we references faces via I think that #360 would be a better approach (and relatively efficient). ( |
|
yes, but with |
Codecov Report
@@ Coverage Diff @@
## master #401 +/- ##
==========================================
+ Coverage 89.78% 91.27% +1.48%
==========================================
Files 22 22
Lines 2701 3036 +335
==========================================
+ Hits 2425 2771 +346
+ Misses 276 265 -11
Continue to review full report at Codecov.
|
|
I found a bug where I was pushing new entries to K while thinking I was only reading the old entries so I had to change it to but this allocates We could force the user to first call Thoughts on what we should do? Edit: the assembler class also requires the user to have called |
|
Can't we check if K has non-zero (well or explicit zero) values in these positions and at least throw a warning when a user hasn't created the right sparsity pattern? |
|
I think the simplest approach here is to write a new function If just iterative solvers are used, then maybe just computing the action of the "condensation matrix" |
|
@kimauth I think that is pretty much the same amount of work as doing the condensation. @termi-official That is what I have added already :) |
|
Ah, sorry, no idea how I missed that in the discussion. |
|
I have tested this in my own code and everything seems to work. My next TODO is to add some docs, but if anyone wants to start reviewing this PR, please feel free too :P (@fredrikekre) |
There was a problem hiding this comment.
Looks really cool! I left some comments on the docs.
Ping @koehlerson we could utilize this for AMR, as this is basically just a different approach to applying the P-matrix, which we implemented for the AMR student project.
fredrikekre
force-pushed
the
EB_linearc
branch
from
b82cda1
to
89e7211
Compare
|
Very cool. |
|
Nice, thanks for review and updates. |
This adds the AffineConstraint constraint type that can be added to the
constraint handler. An affine constraint of the form
u_i = \sum_j (c_j * u_j) + b,
where u_i are dofs, c_j scaling factors and b a inhomogeneity is
constructed and added to the constraint handler as
ac = AffineConstraint(i, [u_j => c_j, ...], b)
add!(ch, ac)
Sparsity patterns must then be constructed with the constraint handler
e.g. create_sparsity_pattern(dh, ch), and apply! must be used after
solving the system (apply!(u, ch), where u is the solution).
This wip PR makes it possible to use linear constraints. I was able to use a lot of the old structure of the ConstraintHandler which is nice. I also got inspiration on how to condense the stiffness matrix from deal ii :)
Currently this PR is not very fail safe, meaning that the user can add Dirichlet and/or linear constraints that does not "work" together, without warning the user. There is no logic that assures that constraints are linearly independent etc (this is something the user must make sure themselves).
When adding constraints, the user must reference global dof ids directly. For this, we need better tools for querying dof ids on faces/edges/nodes etc.
Example: