[petsc-dev] MatSetColoring

[Peter Brune]

On Fri, May 17, 2013 at 3:25 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> Peter Brune <prbrune at gmail.com> writes:
>
> >
> https://bitbucket.org/petsc/petsc/commits/all/tip/prbrune/snes-jacobiancolorfixchanges
>
> Bitbucket website seems screwed up, but 'git fetch' still works.
>
> > setting user coloring back to how it was in 3.3; I'll change the
> > manual to describe why this is bad (doesn't work with grid sequencing or
> > FAS or a number of other things) and then merge into maint if it's OK.
>
> Is the context ever set in current code, with the expectation that it
> will be ignored?  Maybe when used with TS?  In any case, the branch
> should cook in 'next' before being merged to 'maint'.
>

Yeah it was pretty easy to break in TS..  I thought that I might be going
in circles here.


>
> It's probably worth risking the low-probability of a user depending on
> the parameter being ignored in exchange for being able to fix this
> inconvenience in petsc-3.4.
>

What exactly do you mean by this?  I can "fix it" for the TS case by
replacing the error-out on the parameter with a type compare, but for a
general user context that's not a PetscObject it's more dicey.  We could
zero it out explicitly when setting snes_fd_coloring from options and
expect users to do the right thing.


>
> Or MatSetColoring() could be revived for 3.4.1 and then you wouldn't
> have to worry about breaking compatibility.
>
> > After that, we should take MatGetColoring and MatSetColoring and make
> them
> > be a convenient interface.  Can we remove the remaining Adifor stuff and
> > start from scratch on this?
>
> I don't think the Adifor stuff was being kept intentionally.
>

Cool; I'll strip it out.


>
> > Having a good parallel MatColoring would make a lot of these problems
> less
> > severe.  We should write a simple one and then go from there.
>
> Yes.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130517/496b13d3/attachment.html>