OK, so it's not an n^2 algorithm, but XdrIO::write() currently gets called on all CPUs, and so all of them try to write to the same file at the same time. Turns out this is a lot more noticeable on 128 CPUs than it is on 4...
The fix should be to wrap the call to write in if (processor_id==0) as is done for GMVIO. I'll try to check this fix in today. -John John Peterson writes: > Benjamin Kirk writes: > > > I haven't had a chance to look into this closely yet, but I just wanted > to > > > post something here so I would remember to. In writing out some > relatively > > > large (36x36x36 Hex27's) meshes recently, mesh.write() apparently took > 1268 > > > seconds!! > > > > I'm guessing it was an xdr file?? I've never seen anything that slow, but > > certainly it is worth looking in to. I'm guessing writing a cube should > be > > able to reproduce the problem? > > I can't reproduce this error in the CFDLab... writing the same size > mesh takes about 4 seconds there. TACC has been having some troubles > with their $WORK filesystem lately, so maybe that was it. It'd be nice > not to have to wait 20 minutes at the end of a run for the mesh to be > written, though ;-) > > -J ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
