dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #22392
Re: Unit test problem in parallel
On Wed, Mar 30, 2011 at 11:46:56AM -0700, Johan Hake wrote:
> On Wednesday March 30 2011 11:38:07 Anders Logg wrote:
> > On Wed, Mar 30, 2011 at 10:22:36AM -0700, Johan Hake wrote:
> > > On Wednesday March 30 2011 10:15:01 Niclas Jansson wrote:
> > > > Johan Hake <johan.hake@xxxxxxxxx> writes:
> > > > > On Wednesday March 30 2011 10:02:28 Niclas Jansson wrote:
> > > > >> Johan Hake <johan.hake@xxxxxxxxx> writes:
> > > > >> > On Tuesday March 29 2011 23:27:27 Anders Logg wrote:
> > > > >> >> On Tue, Mar 29, 2011 at 11:10:17PM -0700, Johan Hake wrote:
> > > > >> >> > What triggers the error? Is it writing and/or reading to/from
> > > > >> >> > file. Is it assignment of data from within the read function
> > > > >> >> > in the test?
> > > > >> >> >
> > > > >> >> > johan
> > > > >> >>
> > > > >> >> It's the next line following the read:
> > > > >> >> std::string filename(p1["filename"]);
> > > > >> >
> > > > >> > It took some time to find the parameter unit test ;)
> > > > >> >
> > > > >> >> So something goes wrong for at least one of the processes when
> > > > >> >> the parameters are read back from file. Here's what happens:
> > > > >> >>
> > > > >> >> 1. All processes create parameter set p0
> > > > >> >>
> > > > >> >> 2. Process 0 writes p0 to file
> > > > >> >>
> > > > >> >> 3. Everyone waits (barrier)
> > > > >> >>
> > > > >> >> 4. All processes read from the file into p1
> > > > >> >>
> > > > >> >> 5. All processes access parameters from p1 and compare to p0
> > > > >> >
> > > > >> > I guess it is 4 that goes wrong. I have tried to google varieties
> > > > >> > of "open shared file fstream". It looks like others have had the
> > > > >> > same problem.
> > > > >> >
> > > > >> > Johan
> > > > >>
> > > > >> I don't think it's enough with a barrier. It doesn't guarantee that
> > > > >> the data is flushed to the disk.
> > > > >
> > > > > But how could it work for some processes and not for others. Doesn't
> > > > > this indicate that the file is properly created?
> > > > >
> > > > > Johan
> > > >
> > > > True...
> > > >
> > > > But, say that the file is flushed some time after the barrier. Maybe
> > > > that is long enough for some of the processes to reach the "File f1"
> > > > statement before the file is flushed. The others arrives a bit later
> > > > and gets a valid file pointer.
> > >
> > > Ok, make sense.
> > >
> > > A flush at the end of each << call might not hurt anyway.
> >
> > I tried a flush but it didn't help.
>
> Have you tried closing the file after writing?
Not yet. I will return to it later (=not today).
--
Anders
Follow ups
References