changes to MatSetOption() in petsc-dev

[Barry Smith]

  Lisandro,

    For each new column it simply checks if the current
index is larger then or smaller than the previous index.
Then it searches on the appropriate side, thus it works
well if the values are sorted or not. In fact, I see no
advantage of "taking advantage of" being sorted). Thus
a long time ago I changed the code to do this, but did
not remove the sorted flags at that time.

   Is this clear or am I missing something,

   Barry


On Mon, 9 Jul 2007, Lisandro Dalcin wrote:

> On 7/9/07, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > > Not sure what to do with  MAT_USE_INODE. Perhpas it can be
> > 
> >    Can just leave it as an on-off switch as it is now
> 
> It's OK for me anyway.
> 
> > > * You removed the MAT_[ROW|COLUMN]_SORTED stuff. I think you should
> > > keep it, even when this feature is not yet implemented.
> > 
> >   It is not a mater of being implemented, it used to be used but is not
> > needed IMHO. What do you think it would be used for?
> 
> Well, I believe that if the user can assert that the row or cols
> indices are sorted, then the matrix assembly for row/column compressed
> formats can be implemented faster by reducing the range where you have
> to do binary search for locating the index. Is this correct? I said I
> was not implemented because some time ago I've looked at matrix
> assembly routines for AIJ and I understood this optimitzation was not
> implemented despite the option MAT_[ROW|COLUMN]_SORTED was available.
> 
> This option could be used for a power user to inform PETSc that the
> row or column indices in MatSetValues() are sorted. However, I have to
> recognize that it use is error prone. This can interact really badly
> with MatSetValuesLocal. Perhaps it's a good idea to remove it anyway.
> 
> 
> 
>