<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 17, 2013 at 3:25 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Peter Brune <<a href="mailto:prbrune@gmail.com" target="_blank">prbrune@gmail.com</a>> writes:<br>
<br>
> <a href="https://bitbucket.org/petsc/petsc/commits/all/tip/prbrune/snes-jacobiancolorfixchanges" target="_blank">https://bitbucket.org/petsc/petsc/commits/all/tip/prbrune/snes-jacobiancolorfixchanges</a><br>
<br>
Bitbucket website seems screwed up, but 'git fetch' still works.<br>
<div><br>
> setting user coloring back to how it was in 3.3; I'll change the<br>
> manual to describe why this is bad (doesn't work with grid sequencing or<br>
> FAS or a number of other things) and then merge into maint if it's OK.<br>
<br>
</div>Is the context ever set in current code, with the expectation that it<br>
will be ignored?  Maybe when used with TS?  In any case, the branch<br>
should cook in 'next' before being merged to 'maint'.<br></blockquote><div><br></div><div>Yeah it was pretty easy to break in TS..  I thought that I might be going in circles here.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It's probably worth risking the low-probability of a user depending on<br>
the parameter being ignored in exchange for being able to fix this<br>
inconvenience in petsc-3.4.<br></blockquote><div><br></div><div>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.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Or MatSetColoring() could be revived for 3.4.1 and then you wouldn't<br>
have to worry about breaking compatibility.<br>
<div><br>
> After that, we should take MatGetColoring and MatSetColoring and make them<br>
> be a convenient interface.  Can we remove the remaining Adifor stuff and<br>
> start from scratch on this?<br>
<br>
</div>I don't think the Adifor stuff was being kept intentionally.<br></blockquote><div><br></div><div>Cool; I'll strip it out.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><br>
> Having a good parallel MatColoring would make a lot of these problems less<br>
> severe.  We should write a simple one and then go from there.<br>
<br>
</div>Yes.<br>
</blockquote></div><br></div></div>