When an element is refined the refinement pattern is such that the =
children
and parents have coincident faces. That is to say if a parent has side =
3 on
a boundary, then those children adjacent to side 3 will also have their =
side
3 on the boundary. Make sense? That way if you want to know the side =
id for
a child you ask its parent, all the way back to the level 0 element. =
That
way you don't need to add & remove children from the BoundaryInfo =
class.
As for specifying BC values from a file: that might be a useful =
addition,
but I think it should go in a separate file. The XDA/XDR file should =
define
the mesh and its boundary. All simulation-specific stuff should go
somewhere else... A huge mesh file should be portable across many
simulations, which would not be the case if the BC values get recorded =
with
the mesh.
I would be open to any discussion on easing the pain of BC-handling,
though...
-Ben
-----Original Message-----
From: libmesh-devel-admin@...
[mailto:libmesh-devel-admin@...] On Behalf Of Martin =
L=FCthi
Sent: Monday, March 15, 2004 1:37 PM
To: libmesh-devel@...
Subject: RE: [Libmesh-devel] BoundaryMesh
Benjamin
KIRK, BENJAMIN (JSC-EG) (NASA) writes:
> I have attached a description of the XDA format, hopefully this will
clear > up how the boundary conditions are read from file.
Thanks, this explains quite a bit. Apparently it is not possible to =
give
nodal boundary conditions with specific values. To reproduce results =
from
other FE Codes I would like to impose varying nodal quantities, such as
Quantity Node-nr value =20
0 42 0.0
0 46 0.3
0 52 0.7
1 42 0.0
1 101 100.
....
Of course it is easily possible to read these data in from additional =
files,
but it would be nice to be able to provide numerical values of imposed
boundary conditions. This seems to be missing in the scheme you =
described in
the definition of the XDR files.=20
> As for the boundary mesh:
>=20
> The main reason it exists is for extracting the boundary of the mesh =
for
> post-processing purposes. The idea is that you can extract the =
entire >
boundary of a simulation and then look at surface quantities of =
interest. >
With that said, the only thing *I* have ever used it for is extracting =
faces
> to make sure that boundary conditions are properly specified. =
meshtool.cc
> probably shows this most clearly. The boundary mesh should be one
dimension > lower than the primal mesh... I'll fix this so that it is
properly > enforced.
OK, this makes sense. I will also dig into meshtool.cc
> As for specifying boundary conditions, the BoundaryInfo class simply =
>
provides a way for you to group nodes or sides together. It is up to =
you to
> use this grouping (presumably in your matrix assembly routine) to =
impose
> meaningful boundary conditions. There are no 'magic' boundary =
conditions
> (like 1 =3D no-slip, 2 =3D constant temperature, etc...). This would =
require
> libMesh to know too much about the systems you are solving and would =
limit
> your flexibility.
So, are the boundary descriptors inherited on a refined mesh (ok, I =
should
try that out)? Then it seems reasonable not to prescribe nodal values, =
or
one would have to interpolate on a refined mesh.
Thanks for your time
Martin
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of =
GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcl=
ick
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@...
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
|