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