> 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.
That is very interesting. I did not realize that there was an iterator over specific elements in current processor based on a flag. I would very much use this if the idea was extended to say an array of unsigned ints rather than just one, namely subdomain flag. I want to store the physical material id, the original surface or volume id which helps me in visualization and any other helpful parameter that I do not foresee right now. This is the reason why I like mesh_data because it allows you to add a std::vector to each element and hence is a lot more flexible. But if this concept can be implemented in mesh itself, that would be a lot more helpful since I do not have to worry about propagating whenever there is a change in the mesh . On Wed, Nov 12, 2008 at 7:43 PM, Benjamin Kirk <[EMAIL PROTECTED]> wrote: >>> 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
