dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Jan 15, 2008 at 09:18:36AM +0100, Johan Hoffman wrote:
> > On Jan 14, 2008 5:42 PM, Murtazo Nazarov <murtazo@xxxxxxxxxxx> wrote:
> >> > On Tue, Jan 15, 2008 at 12:23:30AM +0100, Murtazo Nazarov wrote:
> >> >> > On Mon, Jan 14, 2008 at 08:57:34PM +0100, Murtazo Nazarov wrote:
> >> >> >> > Is there an obvious high level way to implement normal flow type
> >> >> >> > boundary conditions or symmetry type boundary conditions?
> >> >> >> >
> >> >> >> > -gideon
> >> >> >> >
> >> >> >>
> >> >> >> If you mean slip boundary condition which for normal velocity, it
> >> is
> >> >> >> already implemented and soon will be available with UNICORN.
> >> >> >>
> >> >> >> The slip with friction is also implemented.
> >> >> >>
> >> >> >> /murtazo
> >> >> >
> >> >> > How is this implemented and for which element types? Maybe it can
> >> be
> >> >> > added to DOLFIN.
> >> >> >
> >> >>
> >> >> It is implemented in the "stong" way as the Dirichlet BC. The idea is
> >> to
> >> >> put u*n = u1*n1 + u2*n2 + u3*n3 = 0, where u = (u1,u2,u3) velocity
> >> and n
> >> >> =
> >> >> (n1,n2,n3) normal to a boundary node. At the monent it works for
> >> simple
> >> >> (cylinder, cube, ...) and quite complex geometries (car), but we are
> >> >> testing it in different geometries. Then, it would be good to add it
> >> to
> >> >> DOLFIN.
> >> >
> >> > I mean how do you translate u1*n1 + u2*n2 + u3*n3 = 0 into an equation
> >> > for the degrees of freedom (which may or may not be u1, u2, u3), which
> >> > types of finite elements does this work for and how do you modify the
> >> > linear system?
> >> >
> >>
> >> It is done for the linear system. The idea is almost the same as
> >> Dirichlet
> >> implementation, but here we change two (in 2D), three (in 3D)
> >> corresponding rows of the system. I think (I may be wrong) it has
> >> nothing
> >> to do with the types of finite elements.
> >
> > Just a small comment. I believe this is a completely wrong strategy for
> > parallel
> > operation, and have discussed it extensively with Wolfgang Bangreth
> > (DealII).
> > Changing an assembled parallel matrix is a very big pain, and can impact
> > performance. I think it makes much more sense to identify and remove
> > constrained dofs before assembly. I believe we discussed this approach
> > last time
> > I was at Simula.
> 
> Yes, this is a good comment. We have not thought too much about this
> together with parallelization yet. We have started to get things working
> now in parallel for a Poisson equation, and the next step is to set up a
> flow problem, so we'll run in to this problem any day... We'll get back
> when we have any news on that.
> 
> > Also, I believe it does depend on the element which you use. If I want to
> > apply
> > a Dirichlet condition to the linear system, I assume this means setting a
> > vector entry to some value. That vector entry is a coefficient in the
> > expansion
> > of the BC function in the FEM basis. Thus I need the projection of this
> > function
> > into the basis first. Coordinating this is not trivial. FIAT does not
> > currently output
> > the projection method (I have it coded for some elements), but I believe
> > SiFy
> > does.
> 
> You can apply these conditions strongly or weakly; what Murtazo is
> referring to is a strong implementation. For both strategies you need
> normals (and possibly tangents) associated to each dof. The reason it does
> not work with a normal defined based on the geometry of the boundary mesh
> (for each boundary face for example) is that dofs with basis functions
> supported on more than one boundary face runs the risk of being
> constrained in more than one normal direction (if the normal for the two
> faces are not parallel), so that for example a slip bc (u*n=0) in fact
> becomes a no slip bc (u=0).
> 
> For a strong implementation, in principle, I guess that you may extend the
> implementation to general elements as u*n = sum_i u_i phi_i*n, but then
> you still need to define a normal for each dof, which may be less obvious
> for general elements. In UNICORN we are currently using linear Lagrange
> elements so things are rather straight forward. This is also the reason we
> have chosen to not implement it directly in DOLFIN. But a generalization
> suitable for DOLFIN may be possible to develop.

ok, would be good to have.

-- 
Anders


> Also, for the strong implementation one typically is forced to rearrange
> rows in the global matrix to avoid bad conditioning after application of
> the bc's. I agree that it is probably better to apply the bc's before
> assembly, but one still may be forced to change rows in the global matrix.
> 
> For a weak implementaion (penalty or Lagranage multiplier) one still needs
> to define normals for each dofs. Both strategies are based on a local
> coordinate transformation from Cartesian coordinates (e1,e2,e3) into the
> space spanned by normals and tangents (n,t1,t2).
> 
> /Johan
> 
> >
> >   Thanks,
> >
> >     Matt
> >
> >> /murtazo
> >>
> >> _______________________________________________
> >> DOLFIN-dev mailing list
> >> DOLFIN-dev@xxxxxxxxxx
> >> http://www.fenics.org/mailman/listinfo/dolfin-dev
> >>
> >
> >
> >
> >
> 
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev