On Tue, Jan 15, 2008 at 09:18:36AM +0100, Johan Hoffman wrote: > > On Jan 14, 2008 5:42 PM, Murtazo Nazarov <[EMAIL PROTECTED]> 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 > >> [email protected] > >> http://www.fenics.org/mailman/listinfo/dolfin-dev > >> > > > > > > > > > > > _______________________________________________ > DOLFIN-dev mailing list > [email protected] > http://www.fenics.org/mailman/listinfo/dolfin-dev _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
