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 <> wrote:
> Barry Smith <> 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?

Reply via email to