Ok - I just checked in these changes. It will use the old algorithm unless you pass skip_renumber...
Sorry, was gone for a bit.
Sticking with the old algorithm in the non-skip_renumbering case is
probably the best way to go if you're in a hurry. However, I wouldn't
worry about restart files - don't we always libHilbert-renumber the
solution data anyway?
On Fri, 25 May 2012, Derek Gaston wrote:
Any input here? I'm probably going to do what I said... run the original algorithm unless they say "skip_renumbering"....
I need to get this fixed (have some users waiting on it)....
On Fri, May 25, 2012 at 7:52 AM, Derek Gaston <firstname.lastname@example.org> wrote:
Right - good idea!
However, I just thought of something else. With my new code the original mesh won't ever be renumbered. I'm sure there are quite a few
restart files and other things that are depending on that old renumbering. Should I maybe restore the old algorithm... and only do the new
algorithm if they've asked to "skip_renumbering" ?
On Thu, May 24, 2012 at 12:36 PM, Roy Stogner <email@example.com> wrote:
On Thu, 24 May 2012, Derek Gaston wrote:
HOWEVER: This is now a 2nLog(n) algorithm... where n is the number
of nodes in your mesh.
Replace std::set with LIBMESH_BEST_UNORDERED_SET and (as long as
configure found a gnu or tr1 or c++11 hash table container) we ought
to be back to O(n). Since you're not actually trying to iterate
through connected_nodes in order, just testing for set inclusion
later, there's no need to preserve ordering. The hash tables probably
take up more memory, but I don't think the difference will be
too bad - might want to benchmark (both RAM and CPU usage) to be sure.