You can subscribe to this list here.
2003 
_{Jan}
(4) 
_{Feb}
(1) 
_{Mar}
(9) 
_{Apr}
(2) 
_{May}
(7) 
_{Jun}
(1) 
_{Jul}
(1) 
_{Aug}
(4) 
_{Sep}
(12) 
_{Oct}
(8) 
_{Nov}
(3) 
_{Dec}
(4) 

2004 
_{Jan}
(1) 
_{Feb}
(21) 
_{Mar}
(31) 
_{Apr}
(10) 
_{May}
(12) 
_{Jun}
(15) 
_{Jul}
(4) 
_{Aug}
(6) 
_{Sep}
(5) 
_{Oct}
(11) 
_{Nov}
(43) 
_{Dec}
(13) 
2005 
_{Jan}
(25) 
_{Feb}
(12) 
_{Mar}
(49) 
_{Apr}
(19) 
_{May}
(104) 
_{Jun}
(60) 
_{Jul}
(10) 
_{Aug}
(42) 
_{Sep}
(15) 
_{Oct}
(12) 
_{Nov}
(6) 
_{Dec}
(4) 
2006 
_{Jan}
(1) 
_{Feb}
(6) 
_{Mar}
(31) 
_{Apr}
(17) 
_{May}
(5) 
_{Jun}
(95) 
_{Jul}
(38) 
_{Aug}
(44) 
_{Sep}
(6) 
_{Oct}
(8) 
_{Nov}
(21) 
_{Dec}

2007 
_{Jan}
(5) 
_{Feb}
(46) 
_{Mar}
(9) 
_{Apr}
(23) 
_{May}
(17) 
_{Jun}
(51) 
_{Jul}
(41) 
_{Aug}
(4) 
_{Sep}
(28) 
_{Oct}
(71) 
_{Nov}
(193) 
_{Dec}
(20) 
2008 
_{Jan}
(46) 
_{Feb}
(46) 
_{Mar}
(18) 
_{Apr}
(38) 
_{May}
(14) 
_{Jun}
(107) 
_{Jul}
(50) 
_{Aug}
(115) 
_{Sep}
(84) 
_{Oct}
(96) 
_{Nov}
(105) 
_{Dec}
(34) 
2009 
_{Jan}
(89) 
_{Feb}
(93) 
_{Mar}
(119) 
_{Apr}
(73) 
_{May}
(39) 
_{Jun}
(51) 
_{Jul}
(27) 
_{Aug}
(8) 
_{Sep}
(91) 
_{Oct}
(90) 
_{Nov}
(77) 
_{Dec}
(67) 
2010 
_{Jan}
(25) 
_{Feb}
(36) 
_{Mar}
(98) 
_{Apr}
(45) 
_{May}
(25) 
_{Jun}
(60) 
_{Jul}
(17) 
_{Aug}
(36) 
_{Sep}
(48) 
_{Oct}
(45) 
_{Nov}
(65) 
_{Dec}
(39) 
2011 
_{Jan}
(26) 
_{Feb}
(48) 
_{Mar}
(151) 
_{Apr}
(108) 
_{May}
(61) 
_{Jun}
(108) 
_{Jul}
(27) 
_{Aug}
(50) 
_{Sep}
(43) 
_{Oct}
(43) 
_{Nov}
(27) 
_{Dec}
(37) 
2012 
_{Jan}
(56) 
_{Feb}
(120) 
_{Mar}
(72) 
_{Apr}
(57) 
_{May}
(82) 
_{Jun}
(66) 
_{Jul}
(51) 
_{Aug}
(75) 
_{Sep}
(166) 
_{Oct}
(232) 
_{Nov}
(284) 
_{Dec}
(105) 
2013 
_{Jan}
(168) 
_{Feb}
(151) 
_{Mar}
(30) 
_{Apr}
(145) 
_{May}
(26) 
_{Jun}
(53) 
_{Jul}
(76) 
_{Aug}
(33) 
_{Sep}
(23) 
_{Oct}
(72) 
_{Nov}
(125) 
_{Dec}
(38) 
2014 
_{Jan}
(47) 
_{Feb}
(62) 
_{Mar}
(27) 
_{Apr}
(8) 
_{May}
(12) 
_{Jun}
(2) 
_{Jul}
(22) 
_{Aug}
(22) 
_{Sep}

_{Oct}
(17) 
_{Nov}
(20) 
_{Dec}
(12) 
2015 
_{Jan}
(25) 
_{Feb}
(2) 
_{Mar}
(16) 
_{Apr}
(13) 
_{May}
(21) 
_{Jun}
(5) 
_{Jul}
(1) 
_{Aug}
(8) 
_{Sep}
(9) 
_{Oct}
(30) 
_{Nov}
(8) 
_{Dec}

2016 
_{Jan}
(16) 
_{Feb}
(31) 
_{Mar}
(43) 
_{Apr}
(18) 
_{May}
(21) 
_{Jun}
(11) 
_{Jul}
(17) 
_{Aug}
(26) 
_{Sep}
(4) 
_{Oct}
(16) 
_{Nov}
(5) 
_{Dec}
(6) 
2017 
_{Jan}
(1) 
_{Feb}
(2) 
_{Mar}
(5) 
_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 

1

2

3

4

5

6
(1) 
7

8
(1) 
9
(7) 
10
(5) 
11
(3) 
12
(2) 
13

14

15

16

17

18

19

20
(1) 
21

22

23
(1) 
24
(5) 
25
(3) 
26

27
(15) 
28

29

30
(10) 
31
(2) 




From: John Peterson <jwpeterson@gm...>  20120110 21:09:20

Hi, Your patch sounds interesting; what version of libmesh did you use to do the timings? I'd like to take a closer look, would it be possible for you to send me your patch as produced by "svn diff" or "git diff" commands, just so that I can be sure I have all the necessary code? Thanks, John On Tue, Jan 10, 2012 at 7:10 AM, Gong Ding <gdiso@...> wrote: > Hi, > I am dealing with large 3D model, ~2M tet cells. > The find neighbor algorithm is a bit slow. > Since face does not have a unique key, face matching wasted a lot of time. > > So i use a unique key to match the neighbor face. > The new algorithm takes about 18s vs 76s of old algorithm. > > Here is the header file elem_ukey.h for the unique key of an element. > > #ifndef __elem_ukey_h__ > #define __elem_ukey_h__ > > #include <vector> > #include <algorithm> > > > /** > * Unique key for a elem consisting of a variable number of vertices. > */ > class ElemKey > { > public: > > /** > * constructor > * build key by elem's node id > **/ > ElemKey(const Elem * elem); > > /** > * constructor > * @param vertices the vector of node id > */ > ElemKey(const std::vector<unsigned int> &vertices); > > /** > * constructor > * @param elem elem > * @param local_ids the vector of local node index of elem > */ > ElemKey(const Elem * elem, const std::vector<unsigned int> &local_ids); > > /** > * test if two ElemKey objects are equal > */ > class Equal > { > public: > /** > * Call ElemKey::Equal()(a,b) to check equalness. > * Two keys are equal iff > * # they have the same number of vertices > * # every vertex index matches > */ > bool operator()(const ElemKey &a, const ElemKey &b) const; > }; > > /** > * weakly less test of two ElemKey objects > */ > class Less > { > public: > > /** > * Call ElemKey::Less()(a,b) to check less. > */ > bool operator () (const ElemKey &a, const ElemKey &b) const; > }; > > /** > * compute the hash function of a key > */ > class Hash > { > public: > unsigned int operator()(const ElemKey &a) const; > }; > > friend std::ostream& operator<< (std::ostream& os, const ElemKey &key); > > private: > /** > * internally stored, sorted, list of vertex indices > */ > std::vector<unsigned int> _vertices; > }; > > > // > > > ElemKey::ElemKey(const Elem * elem) > { > for(unsigned int n=0; n<elem>n_nodes(); ++n) > _vertices.push_back(elem>node(n)); > std::sort(_vertices.begin(), _vertices.end()); > } > > > ElemKey::ElemKey(const std::vector<unsigned int> &vertices) > { > _vertices = vertices; > std::sort(_vertices.begin(), _vertices.end()); > } > > > ElemKey::ElemKey(const Elem * elem, const std::vector<unsigned int> &vertices) > { > for(unsigned int n=0; n<vertices.size(); ++n) > _vertices.push_back(elem>node(vertices[n])); > std::sort(_vertices.begin(), _vertices.end()); > } > > > unsigned int ElemKey::Hash::operator()(const ElemKey &a) const > { > /* > OneataTime hash designed by Bob Jenkins > http://eternallyconfuzzled.com/tuts/algorithms/jsw_tut_hashing.aspx > */ > > unsigned int h = 0; // should be 32bit > for (std::vector<unsigned int>::const_iterator it=a._vertices.begin(); > it!=a._vertices.end(); it++) > { > unsigned int k = *it; > > for (int i=0; i<sizeof(unsigned int); i++) > { > unsigned char b = k & 0xff; > k = k >> 8; > > h += b; > h += (h<<10); > h ^= (h>>6); > } > } > > h += (h<<3); > h ^= (h>>11); > h += (h<<15); > > return (unsigned int)h; > } > > bool ElemKey::Equal::operator()(const ElemKey &a, const ElemKey &b) const > { > if (a._vertices.size()!=b._vertices.size()) return false; > > for (std::vector<unsigned int>::const_iterator ia=a._vertices.begin(),ib=b._vertices.begin(); > ia!=a._vertices.end() && ib!=b._vertices.end(); > ia++,ib++ > ) > if (*ia != *ib) return false; > > return true; > } > > bool ElemKey::Less::operator () (const ElemKey &a, const ElemKey &b) const > { > if (a._vertices.size() != b._vertices.size()) return (a._vertices.size() < b._vertices.size()); > > for (std::vector<unsigned int>::const_iterator ia=a._vertices.begin(),ib=b._vertices.begin(); > ia!=a._vertices.end() && ib!=b._vertices.end(); > ia++,ib++ > ) > if (*ia != *ib) return (*ia) < (*ib); > > return false; > } > > std::ostream& operator<< (std::ostream& os, const ElemKey &key) > { > os << "key:" << std::hex << std::setw(10) << ElemKey::Hash()(key) << std::dec; > os << " vertices:"; > for (std::vector<unsigned int>::const_iterator it=key._vertices.begin(); > it!=key._vertices.end(); it++) > { > os << " " << *it; > } > return os; > } > > #endif > > > And unordered_map is used in find_neighbor when possible > > // data structures  Use the unordered_multimap if available > typedef ElemKey key_type; > typedef std::pair<Elem*, unsigned char> val_type; > > #if defined(HAVE_UNORDERED_MAP) > typedef std::unordered_map<key_type, val_type, ElemKey::Hash, ElemKey::Equal> map_type; > #elif defined(HAVE_TR1_UNORDERED_MAP) > typedef std::tr1::unordered_map<key_type, val_type, ElemKey::Hash, ElemKey::Equal> map_type; > #else > typedef std::map<key_type, val_type, ElemKey::Less> map_type; > #endif > > > > > Gong Ding > > > >  > Write once. Port to many. > Get the SDK and tools to simplify crossplatform app development. Create > new or port existing apps to sell to consumers worldwide. Explore the > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join > http://p.sf.net/sfu/intelappdev > _______________________________________________ > Libmeshdevel mailing list > Libmeshdevel@... > https://lists.sourceforge.net/lists/listinfo/libmeshdevel 
From: Gong Ding <gdiso@us...>  20120110 14:29:57

Hi, I am dealing with large 3D model, ~2M tet cells. The find neighbor algorithm is a bit slow. Since face does not have a unique key, face matching wasted a lot of time. So i use a unique key to match the neighbor face. The new algorithm takes about 18s vs 76s of old algorithm. Here is the header file elem_ukey.h for the unique key of an element. #ifndef __elem_ukey_h__ #define __elem_ukey_h__ #include <vector> #include <algorithm> /** * Unique key for a elem consisting of a variable number of vertices. */ class ElemKey { public: /** * constructor * build key by elem's node id **/ ElemKey(const Elem * elem); /** * constructor * @param vertices the vector of node id */ ElemKey(const std::vector<unsigned int> &vertices); /** * constructor * @param elem elem * @param local_ids the vector of local node index of elem */ ElemKey(const Elem * elem, const std::vector<unsigned int> &local_ids); /** * test if two ElemKey objects are equal */ class Equal { public: /** * Call ElemKey::Equal()(a,b) to check equalness. * Two keys are equal iff * # they have the same number of vertices * # every vertex index matches */ bool operator()(const ElemKey &a, const ElemKey &b) const; }; /** * weakly less test of two ElemKey objects */ class Less { public: /** * Call ElemKey::Less()(a,b) to check less. */ bool operator () (const ElemKey &a, const ElemKey &b) const; }; /** * compute the hash function of a key */ class Hash { public: unsigned int operator()(const ElemKey &a) const; }; friend std::ostream& operator<< (std::ostream& os, const ElemKey &key); private: /** * internally stored, sorted, list of vertex indices */ std::vector<unsigned int> _vertices; }; // ElemKey::ElemKey(const Elem * elem) { for(unsigned int n=0; n<elem>n_nodes(); ++n) _vertices.push_back(elem>node(n)); std::sort(_vertices.begin(), _vertices.end()); } ElemKey::ElemKey(const std::vector<unsigned int> &vertices) { _vertices = vertices; std::sort(_vertices.begin(), _vertices.end()); } ElemKey::ElemKey(const Elem * elem, const std::vector<unsigned int> &vertices) { for(unsigned int n=0; n<vertices.size(); ++n) _vertices.push_back(elem>node(vertices[n])); std::sort(_vertices.begin(), _vertices.end()); } unsigned int ElemKey::Hash::operator()(const ElemKey &a) const { /* OneataTime hash designed by Bob Jenkins http://eternallyconfuzzled.com/tuts/algorithms/jsw_tut_hashing.aspx */ unsigned int h = 0; // should be 32bit for (std::vector<unsigned int>::const_iterator it=a._vertices.begin(); it!=a._vertices.end(); it++) { unsigned int k = *it; for (int i=0; i<sizeof(unsigned int); i++) { unsigned char b = k & 0xff; k = k >> 8; h += b; h += (h<<10); h ^= (h>>6); } } h += (h<<3); h ^= (h>>11); h += (h<<15); return (unsigned int)h; } bool ElemKey::Equal::operator()(const ElemKey &a, const ElemKey &b) const { if (a._vertices.size()!=b._vertices.size()) return false; for (std::vector<unsigned int>::const_iterator ia=a._vertices.begin(),ib=b._vertices.begin(); ia!=a._vertices.end() && ib!=b._vertices.end(); ia++,ib++ ) if (*ia != *ib) return false; return true; } bool ElemKey::Less::operator () (const ElemKey &a, const ElemKey &b) const { if (a._vertices.size() != b._vertices.size()) return (a._vertices.size() < b._vertices.size()); for (std::vector<unsigned int>::const_iterator ia=a._vertices.begin(),ib=b._vertices.begin(); ia!=a._vertices.end() && ib!=b._vertices.end(); ia++,ib++ ) if (*ia != *ib) return (*ia) < (*ib); return false; } std::ostream& operator<< (std::ostream& os, const ElemKey &key) { os << "key:" << std::hex << std::setw(10) << ElemKey::Hash()(key) << std::dec; os << " vertices:"; for (std::vector<unsigned int>::const_iterator it=key._vertices.begin(); it!=key._vertices.end(); it++) { os << " " << *it; } return os; } #endif And unordered_map is used in find_neighbor when possible // data structures  Use the unordered_multimap if available typedef ElemKey key_type; typedef std::pair<Elem*, unsigned char> val_type; #if defined(HAVE_UNORDERED_MAP) typedef std::unordered_map<key_type, val_type, ElemKey::Hash, ElemKey::Equal> map_type; #elif defined(HAVE_TR1_UNORDERED_MAP) typedef std::tr1::unordered_map<key_type, val_type, ElemKey::Hash, ElemKey::Equal> map_type; #else typedef std::map<key_type, val_type, ElemKey::Less> map_type; #endif Gong Ding 
From: Kirk, Benjamin (JSCEG311) <benjamin.kirk1@na...>  20120110 13:11:24

>> We can instantly accommodate the patch, in the same sense that I can >> instantly sell you the Brooklyn Bridge for cash, but in each case >> there's an implied promise (distortions with the same seed will always >> produce the same results; you'll end up with a valid deed) that would >> end up being violated later. I don't like breaking backwards >> compatibility, and so I don't like getting into situations that would >> back us into a corner where we'd eventually have to break backwards >> compatibility. > > Doesn't the current implementation have the same implied promise, just in > a weaker form? I.e., "distortions will always produce the same results"? If my > understanding is correct, distorting a serial mesh and a parallel mesh won't > produce the same result right now. In that sense, the patch wouldn't make a > big difference really, except maybe increasing the chance of a user falling > for > the promise. Which could be reduced again by disclaiming clearly in the > documentation... You are correct. The current implementation has the same issue. Distorting a parallel mesh on M processors yields a different result than on N processors, which is why I don't see an issue with the patch as is. I'm trying to understand the API concern. Allowing the seed to be supplied as a default parameter does not change the API, and anyone who uncovers that there is an optional parameter surely will have done so by reading the (updated) documentation that explains the issue? Anyway, regarding this idea: > keep using std::rand, but reseeding for each > node with std::srand(seed + node>id())? Anything that uses the global node id won't work. The key issue here is that global node ids are dependent on the parallel decomposition. We renumber nodes so that each processor owns a sequential set of global ids. There are two alternatives that come to mind: (1) use the partitionindependent global node ordering imposed by the Hilbert index  we use this in other places we want to produce a partitionagnostic element or nodal ordering, or (2) use the Point key() concept that we use in mesh refinement to locate duplicate nodes. This takes (x,y,z) and maps them to a integer. Now this integer is not guaranteed to be unique, but it should serve the purpose of seeding the random number generator as you proposed above. I'd lean to (2), and this could easily be accommodated by making the key() member of the LocationMap public. Thoughts? Ben 
From: Robert <libmesh@ro...>  20120110 10:45:06

Hello, I have stripped down my code to an example containing a neohookean solid with displacement boundary conditions. See the attached patch. I have just tested this with the default configure options. Any suggestions for improvements are of course welcome. While porting my code to the libmesh tensor classes, I discovered a small bug in TypeTensor<T>::assign. See tensor.patch. Regards Robert On Mon, Jan 09, 2012 at 09:02:29AM +1300, Mark Davies wrote: > Hi Guys, > > I'm just getting started with the library and was wondering if there are > any examples dealing with elastic solids? Thanks in advance for any > suggestions. > > Regards, > Mark > > >  > Ridiculously easy VDI. With Citrix VDIinaBox, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this allinone solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/CitrixVDIinabox > _______________________________________________ > Libmeshusers mailing list > Libmeshusers@... > https://lists.sourceforge.net/lists/listinfo/libmeshusers 
From: Roman Vetter <vetterro@et...>  20120110 07:49:09

>> > Perhaps we could avoid using a sequential PRNG in distort() >> > altogether? Replace the std::rand() subroutine calls with some kind >> > of function calls that lack internal state, just hashing the initial >> > seed with the previous node coordinates somehow? Hm, interesting alternative. Or, keep using std::rand, but reseeding for each node with std::srand(seed + node>id())? >> So I think we can immediately accommodate the patch – it certainly does no >> harm – am I missing something? > > > We can instantly accommodate the patch, in the same sense that I can > instantly sell you the Brooklyn Bridge for cash, but in each case > there's an implied promise (distortions with the same seed will always > produce the same results; you'll end up with a valid deed) that would > end up being violated later. I don't like breaking backwards > compatibility, and so I don't like getting into situations that would > back us into a corner where we'd eventually have to break backwards > compatibility. Doesn't the current implementation have the same implied promise, just in a weaker form? I.e., "distortions will always produce the same results"? If my understanding is correct, distorting a serial mesh and a parallel mesh won't produce the same result right now. In that sense, the patch wouldn't make a big difference really, except maybe increasing the chance of a user falling for the promise. Which could be reduced again by disclaiming clearly in the documentation... Roman 