Ok - I just checked in these changes.  It will use the old algorithm unless you pass skip_renumber...

Derek

On Fri, May 25, 2012 at 12:57 PM, Roy Stogner <roystgnr@ices.utexas.edu> wrote:

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?
---
Roy


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)....

Derek

On Fri, May 25, 2012 at 7:52 AM, Derek Gaston <friedmud@gmail.com> 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" ?

Derek

On Thu, May 24, 2012 at 12:36 PM, Roy Stogner <roystgnr@ices.utexas.edu> 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.
---
Roy