I do remember it. I thought we had checked it in and so I figured
that couldn't *still* be the problem. Oh well.
Derek Gaston writes:
> John... do you remember that you and I already did this once back when
> I was working on my thesis? I was seeing the same problem of writing
> from every node... and we dug down there and put a bunch of those
> statements in. I guess it never actually got checked in though....
> and I'm not even sure I still have that code around.
> This is why I'm not committing my stuff a lot more often... don't want
> to lose it.
> On Nov 26, 2007 11:15 AM, John Peterson <peterson@...> wrote:
> > 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