OK, let's way for Barry's opinion...
I just make always a bit of 'pressure' for fixing stuff in 'release'
just because I want to make petsc4py usable with at least the latest
two PETSc releases. Currently petsc4py can build and work almost as
expected in 2.3.2, 2.3.3 and current petsc-dev. And then is more
convenient for me to push fixes in latest release that letting vile
hakery be living in all my backward compatibility stuff (and because
some fixes are impossible to get right if not pushed to core PETSc
code).
In short, any time I'll find something to fix that could go to
release, I'll ask here about this. If my requests just do not make
sense, any of you have to just stop me with a one-line mail saying
"push that in petsc-dev". I hope this is not too much annoyance for
you.
On 6/10/08, Satish Balay <balay(a)mcs.anl.gov> wrote:
> Lisandro,
>
> Normally I would say a big change/fix should go into petsc-dev
> [currently dev has many fixes that are not in petsc-2.3.3].
>
> However - if you feel strongly that this fix should go into
> petsc-2.3.3 - and are able to merge it back to petsc-dev, then I have
> no objections..
>
> but you might want to wait for Barry's opinion before doing this.
>
>
> Satish
>
>
> On Tue, 10 Jun 2008, Lisandro Dalcin wrote:
>
> > Some fixes are needed for BAIJ matrices are:
> >
> > (1) MatMPIBAIJSetPreallocationCSR_MPIBAIJ -> BROKEN
> > (2) MatSeqBAIJSetPreallocationCSR_SeqBAIJ -> MISSING
> >
> > Regarding (1), the fix needs to call PetscMapSetUp() for setting-up
> > the row and column maps (rmap&cmap fields) at the very begining,
> > before anything else. If this is not done, the stuff is the row/column
> > maps are not properly initialized at the point (1) is called. But
> > then, PetscMapSetUp() will be called again as (1) calls
> > MatMPIBAIJSetPreallocation_MPIBAIJ with nnz information. However, I
> > believe this is not an issue, as the second call will be a no-op (at
> > least for optimized builds). Additionally, there is a bug at the point
> > MatSetValuesBlocked_MPIBAIJ() is being called, as the block-size is
> > not being taking into accout for the 'values' array (when it is
> > provided).
> >
> > Regarding (2), the issues in (1) for rmap/cmap are the same.
> >
> > It is fine to push the fixes in release-2.3.3, particularly regarding
> > that (2) could be seen a 'new functionality'? I would prefer to add it
> > to release-2.3.3.
> >
> > -------------------------
> >
> > Finally, for MPIAIJ, something I'm not sure what to do is the following:
> >
> > - for MatSeq[B]AIJ one can pass nz=MAT_SKIP_PREALLOCATION
> > - for MatMPI[B]AIJ, passing d_nz/o_nz=MAT_SKIP_PREALLOCATION generates
> > an error.
> >
> > Should MatMPI[B]AIJ support MAT_SKIP_PREALLOCATION for d_nz/o_nz arguments?
> >
> > Again, it is fine to push this to release-2.3.3 ?
> >
> >
> >
> >
>
>
--
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
