Or just throw away separate specification of block size completely  
from Vec and Mat and always have
blocksize as an argument to Vec/MatSetSizes(). With languages that  
support it, the blocksize would be an
optional argument.

    Barry

One could take two points of view

1) block size is just an implementation issues (for BAIJ matrices) so  
sticking it into the basic interface is bad design or
2) block size is actually providing additional information about the  
application to the library so belongs in the basic interface

Originally with PETSc design I had point of view 1. Now I am not so  
sure.

On Jul 24, 2009, at 11:09 AM, Lisandro Dalcin wrote:

> On Fri, Jul 24, 2009 at 12:33 PM, Barry Smith<bsmith at mcs.anl.gov>  
> wrote:
>>
>>   If all the types,sizes,blocksize are going to be REQUIRED calls  
>> then the
>> object can keep track of what it has received and as soon as it  
>> receives all
>> the "required" information do the final creation (this is what Matt  
>> proposed
>> in his more flowery language). If something like blocksize is  
>> optional then
>> it makes things more complicated (hate to make blocksize required  
>> or require
>> it before setting the sizes).
>
> What about this?
>
> 1) Remove VecSetBlockSize()
>
> 2) Add VecSetSizesBlock(vec, bs, n, N), implement here all the checks
> and logics (perhaps even the PetscMapSetup?)
>
> 3) Now VecSetSizes(vec, n, N) just calls VecSetSizesBlock(vec, 1, n,  
> N)
>
> After that, of course you cannot change the vec's block size. This
> way, the block size if more or less optional, but if you no pass it,
> it becomes 1 (one) and you cannot change it anymore...We should also
> add convenience calls VecCreateSeqBlock() and VecCreateMPIBlock()...
>
>
>
> -- 
> Lisandro Dalc?n
> ---------------
> Centro Internacional de M?todos Computacionales en Ingenier?a (CIMEC)
> Instituto de Desarrollo Tecnol?gico para la Industria Qu?mica (INTEC)
> Consejo Nacional de Investigaciones Cient?ficas y T?cnicas (CONICET)
> PTLC - G?emes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594


Reply via email to