> Ok we add one more argument for this feature. But what about another > feature, another argument? And another feature another argument?
I am not asking to add more and more arguments. But since this exists in *WithArray routines, it would be nice to have uniformity. As I said, I like the more general route and this was a specific use case that I needed only recently. Hence the reason for the thread and the original confusion. On Tue, Aug 27, 2013 at 6:35 PM, Barry Smith <[email protected]> wrote: > > On Aug 27, 2013, at 6:21 PM, "Vijay S. Mahadevan" <[email protected]> wrote: > >>> We've debated back and forth this. The WithArray() version has to take >>> the block size because it has to instantiate the vector at that point >>> because it needs a place to put the array pointer. >> >> Understood. But since VecCreateMPI is creating the vector completely >> too, should it not know the block size a-priori ? The long winded way >> is general enough that I like it but the specific API would be >> incomplete without giving this ability to the user IMO. > > Ok we add one more argument for this feature. But what about another > feature, another argument? And another feature another argument? Each > incremental addition sounds good, adding a bit more functionality to the > create at a small cost. But after adding ten new arguments the cost is > suddenly high and you are writing lapack. > > >> >>> I don't think that's ever going to be a general solution, so "raw" Vec >>> creation will always matter too. >> >> And I agree with Jed. Even if DM helps make a user's life easier, >> there are so many applications that just want to create a matrix, >> vector and let petsc solve the system without needing to worry about >> creating a DM Wrapper and hop another indirection. >> >> >> On Tue, Aug 27, 2013 at 5:50 PM, Jed Brown <[email protected]> wrote: >>> Barry Smith <[email protected]> writes: >>>> Our longer term plan is that most PETSc programs would not directly >>>> be creating Vecs and Mats with VecCreate… or MatCreate… rather they >>>> would create a DM and then use the DM object to create the >>>> appropriately laid out vectors and matrices for the users and >>>> solvers with DMCreateGlobalVector() etc. >>> >>> I don't think that's ever going to be a general solution, so "raw" Vec >>> creation will always matter too. >
