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.
