[petsc-dev] Weird interaction between VecDuplicate and VecSetBlockSize

[Barry Smith]

  No one has commented. If no one shouts I will start modifying towards Matt's suggested approach.

   Barry

On Mar 31, 2012, at 10:03 PM, Barry Smith wrote:

> 
>  I'd like to see us come to a resolution to the issue of setting block sizes for Vecs and Mats . Also could we decide on the order (and how much flexibility there can be) in the order the creation and set routines are called.
> 
>   Back ground and current situation:
>   ----------------------------------------------
> 
>   Currently you can call   VecSetType(), VecSetBlockSize(), and VecSetSize() in any order and you can change the block size anytime (since the layout of the vector is likely shared by other vectors there is a very bad side affect of changing the block size later since it may affect many vectors.) There is no VecSetUp(). 
> 
>   Currently you can call MatSetType(), MatSetSize()* in either order. For non-blocked matrices you can call MatSetBlockSize() anytime (as with vectors changing the blocksize later will also change the block size of any other vectors/matrices that share the layout) , for blocked matrices you CANNOT ever call MatSetBlockSize() and must set it with the appropriate preallocation routine. For all matrices one must either call 
> MatSetUp() or MatXXXSetPreallocation() before use.   
> 
>   The convenience routines VecCreateSeq(), VecCreateMPI() etc do not have a way of passing in block size
> 
>   The convenience routines for non-block matrices MatCreateSeq/MPIAIJ() do not have a way of passing in block size. The blocksize must be passed in for the block matrix convenience routines.
> 
>  Goals of reorganization:
>  ---------------------------------
> 
>  Eliminate situation where changing Vec or Mat blocksize "late" changes block size of other vectors/matrices (a very bad thing)
> 
>   Make things more consistent between block and nonblock matrices and vectors
> 
>   Not make allowed usage patterns overly rigid
> 
>   Not have lots of complicated logic in implementation code
> 
>  Possible approaches:
>  ------------------------------
> 
>   Matt's suggestion from a while ago we never followed up on: REQUIRE MatSetBlockSize() to be called ONLY before MatSetUp() or MatXXXSetPreallocation() and remove blocksize argument in MatXXXSetPreallocation(). Similarly we could require VecSetBlockSize() to be called ONLY before  VecSetUp() (blocksize default to 1 if not set before SetUp() is reached.)
> 
>           If we do this it solves the problems of changing blocksizes later affecting other objects and has a nice consistency. Also no complicated "remembering logic"
> 
>           It means we cannot do VecCreateSeq(), VecSetBlockSize(). We could add block size to all the convenience routines, drawback change to many user codes or just say tough, you want to set the blocksize don't use the convenience routines.
> 
>            Introduces VecSetUp() possibly, both good consistent with Mat, and bad, more complicated for everyone
> 
>  Lisandro's 1st suggestion: Allow VecSetBlockSize() to be called anytime, and same with MatSetBlockSize() for non-block matrices but create a new Layout object so doesn't mess up the other vectors/matrices/ 
> 
>           Maximum flexibility power to user, good.
> 
>           Inconsistent between different matrix types, could be confusing bad
> 
>  Lisandro's 2nd suggestion: Allow VecSetBlockSize() and MatSetBlockSize() to be called "just a tiny bit later than creation" (for example before VecDuplicate/MatGetVecs() etc are done so the layout is not yet shared. 
> 
>          A bit more flexibility to the user (they can use VecCreateSeq() and then immediately set the block size, we don't need to change VecCreateSeq()) but maybe confusing in "how long" one can delay changing the block size
> 
>          Inconsistent between different matrix types, could be confusing bad
> 
>          More logic in code to see if it is still "safe" to change the block size
> 
> 
> Barry's feelings:
> -----------------------
> 
>        I like the Matt approach. I am not sure about changing the bindings for the convenience routines.
> 
>   Barry
> 
> * MATSEQDENSE has this strange ability to call MatSetSize() later if it does not expand beyond its original maximum size; this is so special and perverse I'd like to remove it but LAPACKy folks like this feature.
> 
> On Mar 30, 2012, at 12:44 PM, Lisandro Dalcin wrote:
> 
>> On 30 March 2012 19:34, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>> 
>>> On Mar 30, 2012, at 11:07 AM, Lisandro Dalcin wrote:
>>> 
>>>> On 30 March 2012 19:00, Lisandro Dalcin <dalcinl at gmail.com> wrote:
>>>>> 
>> 
>>> 
>>> I think this can be done by having VecSetBlockSize() simple error out it if the map->bs != -1 and new block size not equals current block size.
>>> 
>> 
>> Are you sure? How are we going to support the usage below?:
>> 
>> VecCreateSeq(comm,n,&vec)
>> VecSetBlockSize(vec,bs)
>> 
>> We cannot certainly have a long-living vec with bs=-1, right?
>> 
>> 
>> -- 
>> Lisandro Dalcin
>> ---------------
>> CIMEC (INTEC/CONICET-UNL)
>> Predio CONICET-Santa Fe
>> Colectora RN 168 Km 472, Paraje El Pozo
>> 3000 Santa Fe, Argentina
>> Tel: +54-342-4511594 (ext 1011)
>> Tel/Fax: +54-342-4511169
>