thanks for your pointers there
although I am probably not the Michael that Wout refers to ;-) I have
also tried to implement the constraints for several purposes
On 27.09.05, Roy Stogner wrote:
> On Tue, 27 Sep 2005, Wout Ruijter wrote:
> >Three questions regarding periodic boundary conditions:
> >1 - Michael already showed how to implement periodic bc's of type
> >how do you add u(l)-u(r)=x? Is that a matter of modifying the
> >I mean, is the rhs taken into account for constrained dof?
Exactly. At the moment only homogeneous constraints are supported. If
you really need inhomogeneous constraints you need two things:
1. A marker pseudo-DOF-number that collects the inhomoheneity in the
2. patch the source code of libmesh. The function that really does the
But the easiest thing is to consider if you really need the the
inhomogeneous constraints. I had the simple case where I wanted a
pressure-driven flow, and the pressure had to fulfill similar
inhomogeneous constraints. But this could easily be avoided by adding
a constant gradient in the Navier-Stokes equation.
What kind of system do you need the constraints for?
> >2 - Is there any way in which of two elements with the same error estimate
> >only one will be refined?
> If you have a mesh on which 400 elements have error 2 and 600 have
> error 1, then AFAIK telling libMesh to refine the worst 30% of
> elements will cause a random 300 elements from the first group to be
> flagged for refinement. Normally this is barely noticeable: any
> elements "left behind" by one refinement step are likely to be the
> first elements in line for refinement on the next step. If you need
> two meshes to match exactly or one mesh to be perfectly symmetric,
> though, this will be a problem.
> >If this is not the case I would be able to ensure matching meshes by
> >modifying the error estimates, or should I modify the refinement
> >flags directly?
> Either way is good; I'm not sure which way would be quicker to code.
> To be safe make sure to modify the flags conservatively: only set new
> refinement flags and remove coarsening flags, never set coarsening or
> remove refinement.
> >3- Am I right to presume that in the case that no interpolated constraints
> >are used the _dof_coupling can be used for x==0?
> >I guess this could speed up the whole matter in cases with many couplings.
This is a serious problem. In most cases the _dof_coupling is already
built when you impose the constraints. Then, the Petsc solver will
have to enlarge its dof-coupling every time you fill the matrix at an
unexpected position. This makes the story damn slow.
Therefore, you will need to create the constraints _before_ the
dof-coupling is built. This is exactly what happens to the
I took me a long time to recognize this issue, and maybe there is
another solution, but I ended up by drilling a hole into the complete
library. I now have something like "attach_constrain_function" which works
similar as "attach_assemble_function" and which is called from inside
the library right after the hanging nodes have been built.
"A mathematician is a device for turning coffee into theorems"