On Fri, Jan 23, 2009 at 3:28 PM, Derek Gaston <fried...@gmail.com> wrote: > Is there a particular reason why Mesh::set_n_subdomains() is protected? > > We just noticed that there's an output bug when writing out xda/xdr > format meshes after reading in Exodus meshes with subdomain_id's on > them in the form of blocks.... the subdomain_id's don't get written to > the xda/xdr files. > > The reason appears to be that n_subdomains() is still _0_ on the > mesh.... and after looking at it... that's because the only way to set > n_subdomains() is by using a BoundaryMesh/Info object and the sync() > method. But I can't see any reason why ExodusIO shouldn't be able to > set the number of subdomains when it reads a mesh in.... so I'm voting > for just making set_n_subdomains() public.
>From memory, it's protected because it's not really safe to set_n_subdomains() to an arbitrary value: it depends on how many different subdomain_id()'s the different elements composing the Mesh have. Same goes for the number of partitions... the safest strategy is add a public method akin to MeshBase::recalculate_n_partitions(), for subdomains. Unfortunately, this incurs an O(N elem) overhead and is inconvenient when you really do know the number of subdomains. I find this preferable to adding a potentially unsafe (and it's debatable how unsafe it is) public interface for set_n_subdomains(). 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. -- 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
