dolfin team mailing list archive

["Johan Hoffman" <jhoffman@xxxxxxxxxx>]

> 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.

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
>>
>
>
>
> --
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which
> their experiments lead.
> -- Norbert Wiener
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>