[petsc-users] maintaining application compatibility with 3.1 and 3.2

[Matthew Knepley]

On Thu, Apr 18, 2013 at 8:26 AM, Alexei Matveev <
alexei.matveev+petsc at gmail.com> wrote:

>
> Do I understand it correctly that there is no way currently to load a
>>> distributed
>>> Vec from the file without knowing and setting its dimensions first?
>>>
>>
>> I am not sure what you mean here. The point is that prescribing the
>> layout of a Vec
>> in a file is clearly wrong. We would like to be able to save from one
>> parallel configuration
>> and load on another (maybe serial). Thus, the loader prescribes the
>> layout.
>>
>>
> I see. You understood me correctly. I used that feature to to quickly load
> a Vec from a file and dump it in ACSII or to do simple arithmetics.
> Admittedly
> that was usually done in serial runs.
>
> So the comment here is actually wrong, since you say it is not going to be
> supported by any viewer/loader pair?
>

No, I have to be more specific. PETSc saves the Vec in a uniform format, but
also saves information "out of band" in a .info file. If the input Vec has
not been
already partitioned, the plan was to use the .info file to recreate the
original
layout.

   Matt


> /* This one is supposed to save enough meta-info (such as distribution
>    pattern, dimensions) to recover the vector from scratch: */
> void vec_save (const char file[], const Vec vec)
> {
>   PetscViewer viewer;
>
>   PetscViewerBinaryOpen (PETSC_COMM_WORLD, file, FILE_MODE_WRITE, &viewer);
>   VecView (vec, viewer);
>   PetscViewerDestroy (viewer);
> }
>
> Sorry for spamming the channel,
>
> Alexei.
>



-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20130418/aeec79db/attachment.html>