On Fri, May 17, 2013 at 4:09 PM, Jed Brown <[email protected]> wrote:
> Peter Brune <[email protected]> writes: > > > 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 > > If at all possible, I think it _should_ be zeroed by -snes_fd_coloring. > > > and expect users to do the right thing. > > That was the point of my comment. We don't think they are in the same > position as -snes_fd_coloring, but all their old code either passed NULL > or passed a valid MatFDColoring or passed NULL, and it's not very useful > to write new code that passes non-NULL. > The example that caused me to go into this in the first place was snes/examples/tutorials/ex45.c, which a) set the user context, then manually set the Jacobian func to SNESComputeJacobianDefaultColor and b) seems to have disappeared, so I'm on board with this. - Peter
