On Dec 21, 2011, at 8:47 AM, Jed Brown wrote:
> Problem: User calls SNESSetDM() instead of SNESSetFunction(), then calls
> SNESVISetVariableBounds(). The latter function checks for snes->vec_func and
> errors.
>
> We can't make SNESSetDM() create vec_func because (a) it is only logically
> collective and (b) the DM might not be set up yet.
>
> We can't call SNESSetUp() because that requires snes->vec_sol to have been
> created (with a confusing error message about aliasing). We can work around
> this by adding a new function SNESSetSolution(), but that's an awkward
> interface and SNESSetUp() does other things like call SNESSetUp_VI() which
> doesn't have the bounds yet.
>
> It would be simple and consistent (I think) for SNESGetFunction() to create
> vec_func if it is requested, does not already exist, and can be created. Then
> we can simply call
>
> SNESGetFunction(snes,&snes->vec_func,PETSC_NULL,PETSC_NULL);
>
> before checking whether vec_func is available yet. The problem with this is
> that SNESGetFunction() is currently Not Collective, and this would make it
> collective in that case.
Seems ok to me to make it collective and create the vector if needed.
>
> If it's not acceptable for SNESGetFunction() to create vec_func, then we need
> something like SNESSetUpFunction() that is collective and ensures that
> vec_func exists. I'd rather not add this extra API if it's not necessary.
>
>
> What should we do? (I'm asking in such a verbose way because I think we see
> similar issues in other places, so we can reuse the solution here in other
> places.)
>
>
> Also, why does SNESVISetVariableBounds() call SNESSetType(snes,SNSVIRS)? I
> didn't think we ever did this, but Barry wrote this line as part of the huge
> http://petsc.cs.iit.edu/petsc/petsc-dev/rev/31c8ce41 , so I don't know what
> to think.
If it did not set the type here then the user would always have to both set
the bounds and set a vi solver. That seemed stupid to me (people will forget to
set a vi solver). I would like to leave this the same.
Barry
