That would be useful to have anyway... so it gets my vote. AND... while we're thinking about it... is it too much to ask that it keeps track of which elements are in each subdomain? _THAT_ is something we really need right now.... especially since just around the corner is the capability to have different variables in different subdomains... it would be really nice to be able to just loop over the elements in one subdomain without having to loop through all elements looking for the ones you want.
It's funny because I was just talking this over with a colleague of mine... and we decided that we're going to have to keep regenerating and keeping track of the elements in each subdomain. The purpose here is for postprocessing... where you really only want to compute something on a single subdomain... but it would be useful for lots of purposes. Derek On Jan 23, 2009, at 3:15 PM, John Peterson wrote: > On Fri, Jan 23, 2009 at 4:11 PM, John Peterson > <jwpeter...@gmail.com> wrote: >> It seems like there might be a nice compromise for the MeshIO classes >> since they know quite a lot about and need to touch many different >> parts of the Mesh. I'm not advocating we make them friends, but >> something similar would probably be useful in many instances. > > How about: Mesh maintains a set of unique subdomain_ids which gets > updated by each call to Mesh::add_elem(). Then Mesh::n_partitions > returns the size of that set > > ??? > > -- > John ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
