PetscViewerBinaryOpen getting stuck

[Barry Smith]

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 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
>>
>