On Wed, 27 Jan 2010, Kirk, Benjamin (JSC-EG311) wrote: >> It only gets used for I/O and the cost should scale more slowly than >> solves, though; for large implicit 2D/3D problems it shouldn't be an >> issue even on inefficient MPI implementations. > > Yes, this issue is bizarre indeed. The code does not even do that much > communication there... You might want to compile with METHOD=pro and run it > through gprof - that will give you finer grained granularity as to what the > issue may actually be. > > Can you confirm that the problem doesn't exist on one processor? What are > the details of the mesh you are using??
You know, if we want to try repeating this ourselves, I believe Paul saw a relatively long find_global_indices() execution time by simply ultra-refining (~500K elements) a 1D mesh. I'd assumed that the key word there was "relatively" (we're not at all optimized for 1D, but 1D is still pretty fast to assemble and solve), but perhaps that case triggered a real problem. --- Ro ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
