On Fri, May 17, 2013 at 3:25 PM, Jed Brown <[email protected]> wrote:
> Peter Brune <[email protected]> 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. >
