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.
