From: <an...@tn...> - 2004-03-16 01:47:48
|
Benjamin Thanks for your answer. KIRK, BENJAMIN (JSC-EG) (NASA) writes: > 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. Yes, this makes sense to me. > 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. Well, I just realised that mesh.boundary_info.print_info() gives a list of boundary nodes. It would be nice if it is possible to input them directly (from the xda file) in the form (Node No., ID). This could be specified by the a second figure in the header, e.g. 32 25 # Num. Boundary Conds. would mean 32 element b.c. and 25 node b.c. > I would be open to any discussion on easing the pain of BC-handling, > though... I will follow up on this after some more thought. One more little detail: the xda-files are not of the form everywhere. In most files, there is a empty line between the coordinates and the b.c. but not in /reference_elements/3D/one_hex27.xda and one_tet10.xda. Best, Martin |