> If add_elem() inserted subdomain ids into a std::set, for example, > then we'd just have to do a parallel union of that set during > prepare_for_use, which is O(N_subdomains_per_proc * N_proc) instead of > O(N_elem). It would be cheap to keep the set around afterward, too, > enabling O(log(N_subdomains)) MeshBase::have_subdomain(id) queries.
If meshbase owns this set and if you have this updating call in the non-const member subdomain_id() in Elem, this should work. I would go against using a BitVector or vector<bool> instead because subdomain_id's are not necessarily consecutive and depends on how the mesh was created. From my understanding, since libMesh does not support coarsening beyond the initial mesh supplied, all AMR operations just need to propagate this information around and never have to update the n_subdomains and hence, MeshBase can provide methods to manipulate the subdomain_ids as necessary. On a side note, I also have a Parameter pointer for each element in order to accommodate arbitrary properties for the physics. Deal.II allows something like this and I remember having this discussion here before. This might be necessary to propagate the surface_ids that is read from Gmsh attributes and was wondering if you guys would like this for Elem structure. It is by default a NULL pointer and hence all the existing code would take no extra memory but if someone wants to use it, this would completely eliminate the use of MeshData and all the data can be propagated solely based on this. I have not tested this feature on AMR codes yet but it is on my TODO list... I have quite a few changes in my version of libMesh, depending on my requirements and I'm just trying to see if anyone else finds them useful too. If not, that's fine and I can send you a patch with what is required. On Tue, Oct 27, 2009 at 9:16 PM, Roy Stogner <[email protected]> wrote: > > On Tue, 27 Oct 2009, Vijay S. Mahadevan wrote: > >>> Not quite. I'd rather fix this once and for all, not just fix it in >>> Gmsh now, then in XDR after that, then in Exodus after that, etc. We >>> ought to have something that gets called by MeshBase itself, probably >>> in prepare_for_use, to keep the id count consistent after a file is >>> loaded. >> >> That should work if you want to go over all elements again and then >> create a simple list of the subdomain id's to update the n_subdomains >> variable. If you just want to abstract this out, it looks like you >> would be wasting time doing an extra loop over the mesh when you can >> update this information as and when you read the mesh. Eventhough it >> sounds bad, it still might be the right way to go since the mesh >> reader already knows this information. Just my 2 cents. > > I'm tempted to ignore the cost of an extra loop when it's in the > context of file I/O. Why worry about the cost of redundantly > accessing RAM when we've just spent much more time accessing disk? > > But I suppose we can avoid that cost without killing the abstraction, > if we're smart about it... > > If add_elem() inserted subdomain ids into a std::set, for example, > then we'd just have to do a parallel union of that set during > prepare_for_use, which is O(N_subdomains_per_proc * N_proc) instead of > O(N_elem). It would be cheap to keep the set around afterward, too, > enabling O(log(N_subdomains)) MeshBase::have_subdomain(id) queries. > > Anyone doing element destruction would be in charge of un-screwing-up > the subdomain count afterwards, but all our current delete_elem uses > are in contexts like coarsening, all_tri, delete_remote_elems, and > other such methods that won't change the subdomain count. > > I'd be tempted to use a vector<bool> instead of a set, but that could > backfire nastily if someone decided that their two subdomains should > be numbered "1" and "1000000000". > > Thoughts? > --- > Roy > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
