Re: PetscViewerBinaryOpen getting stuck

[Barry Smith <bsmith@xxxxxxxxxxx>]

On Mar 8, 2008, at 11:19 AM, Gideon Simpson wrote:

> 1.  Certainly a problem in serial.  Also a problem on a shared  
> memory machine with MPI.  Have not tested on a distributed memory  
> machine
>
> 2.  When loading the matrix with MatLoad, you can see in top that it  
> starts gunzip, and then gunzip idles,using no memory or cpu.

   Sounds like gunzip is waiting for input. Edit bin/urlget and  
locate the gzip like that looks like
    gunzip -f $file > /dev/null 2>&1    replace it with
    gunzip -f $file

Now maybe it will print a message when it "hangs" and you can see what  
it wants.

   The -f is suppose to force it to run without asking the user  
anything but


> 3.  Here's an update.  This is NOT a petsc problem, or at least not  
> obviously a petsc problem.  I am using petsc in conjunction with  
> fenics software.  I decided that I wanted to do problems that would  
> need to be run on distributed memory machines, so I decoupled the  
> three processes.  I run dolfin code that generates the matrices and  
> vectors and saves them as petsc binaries.  Then I have pure petsc  
> code that solves the problem.  Finally, there is another dolfin  
> program that interprets the output in terms of my variables.  I  
> discovered that if I do not run this third segment, I can run the  
> petsc solver piece as many times as I want, and there is no idling  
> of gunzip.  Maybe dolfin has a memory leak or something.
>
> 4. Also, if I choose not to zip my files, and just dump the  
> uncompressed binary data, the problem also disappears.
>
> Related question:  when saving compressed binaries, if there is  
> already something in the directory with the filename, gzip prompts  
> to overwrite.  Is there a way to circumvent this need for user  
> intervention?

    I have added the -f option to gzip in src/sys/viewer/impls/binary/ 
binv.c so it will force the overwrite without
request. You can hg pull and then run make in that one directory for  
this update.

> On Mar 8, 2008, at 10:31 AM, Matthew Knepley wrote:
>
> > On Sat, Mar 8, 2008 at 12:00 AM, Gideon Simpson  
> > <GRS2103@xxxxxxxxxxxx> wrote:
> > > I have some code that wants to read in a previously binary dumped  
> > > and
> > > gzipped matrix.  The first time I run this code, it opens the file
> > > with PetscViewerBinaryOpen, loads the data into the matrix and
> > > processes as expected.  However, if, for some reason, I want to
> > > execute it a second time, when it tries to open the file, it gets
> > > stuck.  Investigating a bit, it seems to be that the first time it
> >
> > 1) Is this serial or parallel?
> >
> > 2) What do you mean by "gets stuck"?
> >
> > 3) Is there a small example which illustrates this?
> >
> > I am looking at the code, and do not see an obvious error.
> >
> > Thanks,
> >
> >    Matt
> >
> > > runs, when it gunzips the file, it leaves the file in /tmp.  If that
> > > file is still in this folder, it gets stuck.  If I remove it from /
> > > tmp, the code executes without a problem, as it did the first time.
> > >
> > > Obviously, I could avoid using zipped files.  Is this a bug (or a
> > > feature)?  Is there an obvious way to clean up /tmp after the code
> > > executes?
> > >
> > > -gideon
> >
> >
> >
> > --
> > What most experimenters take for granted before they begin their
> > experiments is infinitely more interesting than any results to which
> > their experiments lead.
> > -- Norbert Wiener