[petsc-dev] Removal of PETSC_VIEWER_NATIVE?

[Matthew Knepley]

On Fri, Aug 9, 2013 at 12:56 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> Barry Smith <bsmith at mcs.anl.gov> writes:
>
> >    At that time we had started to collect these oddball IO methods:
> >
> >    loadintovector
> > -  PetscErrorCode (*loadintovectornative)(PetscViewer,Vec);
> > -  PetscErrorCode (*viewnative)(Vec,PetscViewer);
> >
> >    and Vec/MatLoad() actually created the object and load into it.
> >
> >    I wanted XXXView/XXXLoad() to take an already created XXXX
> >    (allowing the user to determine type etc) and get rid of all the
> >    oddball methods.  I think the lose of all the native support was
> >    accidental, hence Shri put some of it back in. If there is more we
> >    should have that is not there then we should add it back in.
>
> We can put back a switch on viewer format.  We should probably have a
> switch on format in all viewers and fail if an unknown format is
> requested.  As it is, most formats will be silently ignored.
>

This is something to think about. I believe the original intention here was
to
go along with our philosophy of subtyping. For example, if you call

  KSPGMRESSetRestart()

on KSPCR, it is just ignored. Likewise ASCII_INFO_DETAIL might just give
regular ASCII output if we have no specialization for it. This is more of
an open
world assumption where we have an acceptable default if we do not know
about something.

You do give up the ability to detect some error conditions, which may be
more
important.

    Matt

-- 
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-dev/attachments/20130809/f0f8cd55/attachment.html>