From: Yujie <rec...@gm...> - 2010-01-27 16:50:10
|
Dear Ben, Thank you very much for your reply. I will recompile the codes with "METHOD=pro". What is "gprof"? To AMD X86_64-based cluster, actually, I run the codes in Master and one slave nodes with 2 CPUs. The same problem is there. Regards, Yujie On Wed, Jan 27, 2010 at 10:42 AM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > >> When I sent the following email to libmesh mail list. I met one > >> problem because of the size of the email. Could you give me some > >> advice regarding this problem? thanks a lot. > > > > It looks like it made it through eventually; just a little late. > > I had to approve it based on size, and it was originally sent late US time > so I didn't get to it until this morning. This is the second approval I've > had to make in 24 hours, I'll see if there is > > > I'm not sure if you'll get an answer, though. Ben is the one > > responsible for find_global_indices, and he's swamped with other > > things right now. It does a parallel sort, which can be very > > sensitive to MPI implementation. > > > 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?? > > -Ben > > |