branch barry/fix-dmdacreate in next for testing pulls the DMSetFromOptions()
and DMSetUp() call out of the DMDACreateNd(). It also removes any special
handling of negative M,N, and P arguments.
> On Sep 15, 2016, at 11:35 PM, Jed Brown <j...@jedbrown.org> wrote:
> Barry Smith <bsm...@mcs.anl.gov> writes:
>> A perhaps better fix is to finally remove this from the DMDCreateNd() calls
>> /* This violates the behavior for other classes, but right now users expect
>> negative dimensions to be handled this way */
>> ierr = DMSetFromOptions(*da);CHKERRQ(ierr);
>> ierr = DMSetUp(*da);CHKERRQ(ierr);
>> Perhaps we could remove both of these lines from those calls and require
>> every use of DMDCreateNd() to add the
>> DMSetUp() call. Then the user is free to insert a DMSetFromOptions() in
>> between or not. We remove the negative value business which is hokey anyway?
>> So in the use of DMDAGetReducedDMDA() it could call DMDACreate2d() then the
>> DMSetUp() but skip the DMSetFromOptions() line.
> I won't stop you, but I'm not sure that's worth it. We don't use
> MatCreateAIJ type "convenience" functions in library code, so why should
> we use the DMDACreate*d convenience functions? Presumably doing so
> would remove the conditionals (over dimension) that we have now. Or
> perhaps we should do both?