PetscViewerBinaryOpen getting stuck

[Gideon Simpson]

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.

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?

On Mar 8, 2008, at 10:31 AM, Matthew Knepley wrote:

> On Sat, Mar 8, 2008 at 12:00 AM, Gideon Simpson  
> <GRS2103 at columbia.edu> 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
>