[Gmsh] Fwd: about .mesh file format

[Christophe Geuzaine]

On 23/07/10 18:44, Felipe Montefuscolo wrote:
> Yes, I can. But I think that would be annoying for a user user.
>
> But I really liked the first option !! it is very convenient for many
> cases,as you do
>   not need memory to store the labels of the nodes, etc.
>
> a big thanks, your tip was very helpful!

In all our codes we just tag the elements, exactly for the reasons you 
outlined below. Indeed, mathematically, what you want to do is impose 
the boundary condition on the *face* of the cube. The easiest is thus to 
put the tag on the triangles on the face, then iterate over the nodes of 
these triangles (if your unknowns are associated with nodes---which is a 
discretization detail).

>
> Felipe,
> Brazil
>
> ---------- Forwarded message ----------
> From: *Geordie McBain* <gdmcbain at freeshell.org
> <mailto:gdmcbain at freeshell.org>>
> Date: 2010/7/23
> Subject: Re: [Gmsh] about .mesh file format
> To: Felipe Montefuscolo <felipe.mt87 at gmail.com
> <mailto:felipe.mt87 at gmail.com>>
> Cc: gmsh at geuz.org <mailto:gmsh at geuz.org>
>
>
> 2010/7/23 Felipe Montefuscolo <felipe.mt87 at gmail.com
> <mailto:felipe.mt87 at gmail.com>>:
>  > hi again, thanks for the answer.
>  > Let-me explain my problem with a example. If I make a cube, I can
>  > label the faces (with Physical groups) that are on the boundary so
> that all
>  > nodes that are in
>  > these faces will be labeled too. Perfect, that's what I want, because
>  > with this I can impose the Dirichlet boundary conditions in my fem code.
>  > The problem is: and nodes that are in the corners of the cube ? these
> nodes
>  > belong to three faces that may have different labels, and how to decide
>  > which
>  > face does he live ? that is why it would be desirable to add a label
> to them
>  > in medit file.
>  > This detail can deteriorate a solution of a lid-driven cavity
> problem, for
>  > example.
>
> Thanks for the clarification.  I see the issue.
>
> A lot of finite element programs (e.g. libMesh, FreeFem++) actually
> impose Dirichlet conditions as Robin conditions with very high
> `conductances' between the solution at the boundary and what it should
> be.  This makes all the boundary conditions `natural' and none
> `essential'.  It means you don't need to worry about which nodes are
> on Dirichlet boundaries, because none are.  This technique is
> described in e.g.
>
> Becker, E. B., G. F. Carey, & J. T. Oden (1981). Finite Elements, An
> Introduction, Volume 1 of The Texas Finite Element Series. Englewood
> Cliffs, New Jersey: Prentice-Hall, pp. 121--122
>
> Ern, A., & J.-L. Guermond (2004). Theory and Practice of Finite
> Elements, Volume 159 of  Applied Mathematical Sciences. New York:
> Springer, section 8.4.4, pp. 379--380
>
> but of course you might not want to do this, I know.
>
> I can't really think of a way to impose true Dirichlet conditions on
> corners a mesh defined by a MEDIT .mesh mesh file, because of this
> restriction of one tag per node... Actually here's a hack: for nodes
> on just one patch it's easy enough, as you've worked out.  For nodes
> on an intersection of two (or more) patches, can you define that
> intersection as another patch and give it a special tag, meaning that
> any node with that tag is actually on each of the patches?
>
>
>
> --
> Felipe Montefuscolo
>
>
>
> _______________________________________________
> gmsh mailing list
> gmsh at geuz.org
> http://www.geuz.org/mailman/listinfo/gmsh


-- 
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science
http://www.montefiore.ulg.ac.be/~geuzaine