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.
Barry > On Sep 15, 2016, at 11:35 PM, Jed Brown <[email protected]> wrote: > > Barry Smith <[email protected]> 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?
