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 <fried...@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 <royst...@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
>>
>
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
