Just to reiterate the point that RobL made: adding collectives to check for completion, etc. of other ranks adds overhead to the calls when they are successful. This in turn makes people not use MPI-IO, because it becomes slower, which is good for reducing bug reports, but bad for encouraging use of standard interfaces.
Rob
On Jul 25, 2013, at 12:10 PM, Bob Cernohous wrote:
> > From: "Rob Latham" <robl(a)mcs.anl.gov>
>
> > How did this single rank get a negative offset? Was there some
> > integer math that overflowed?
>
> That's for the app developer to figure out. My issue is that if all ranks had failed the write he probably would have started figuring that out a few days ago and I wouldn't have gotten involved :) It's the weird hw error that dragged me into this when the non-failing ranks entered allreduce in romio and the failing ranks entered allreduce in the app.
>
> Like I said :
>
> > > Just wondering if there's something I can fix here in addition to the
> > > application.
>
> Not the highest priority really. But I coincidentally just got another report (from ANL this time) that an app is hung with half the ranks in write_at_all and half the ranks in a later barrier. It could be something similar. I don't have enough information yet to know but I've suggested they look at errors from write.
>
