>> 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 partition-independent global node ordering imposed by the Hilbert index - we use this in other places we want to produce a partition-agnostic 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 ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform 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/intel-appdev _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
