>> Of course, you would also have to propagate the mesh_data (Or again, >> am I the only one using this ?) which stores material >> information/element or create a view of it also. > > You may be the only one using this. ;-) But yes, we'd want to handle > its restriction as well.
If your primary use of the mesh_data is to define material information, I'd wonder if anything special needs to be done in the case of refinement. As Roy mentions, when an element is refined, it is set to 'inactive' (or 'subactive') because it has children, but it is not removed from the mesh. And specifically, level-0 elements (the ones you read in before adaptivity are still there too. You can get the 'top parent' (the coarsest elementm, read from file, before any refinement) of any element by calling 'elem->top_parent()' - and these are the elements that your mesh_data is probably defined in terms of? I'm guessing your initial mesh resolved material interfaces by necessity, right? So when you refine an element, all the children will be the same material? If so, this is a perfect use for 'top_parent()' We actually also use this notion with boundary conditions associated with element faces. If a parent has a bc on face 2, then all children touching that face inherit the bc. We use this in the library by actually only storing BCs for the level-0 elements. Not to be a MeshData hater, but I wonder if your purposes would be better served by the element subdomain flag? It is an unsigned char in each element you can use to mark elements for whatever purpose you wish... You could then have a function or table lookup that provides material property data based on element subdomain id. What's more, you can exploit this in one of out mesh 'views' - just as the 'active_local_element' iterators provide just that, it would be easy for us to add 'subdomain_active_local_element' iterators, where you could loop over all the active copper elements, then the steel, whatever... on the current processor. -Ben ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
