[petsc-users] Setting block size for MPI vectors

[Vijay S. Mahadevan]

>    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 <bsmith at mcs.anl.gov> wrote:
>
> On Aug 27, 2013, at 6:21 PM, "Vijay S. Mahadevan" <vijay.m at gmail.com> 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 <jedbrown at mcs.anl.gov> wrote:
>>> Barry Smith <bsmith at mcs.anl.gov> 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.
>