Done, see below
[dalcinl at botafogo petsc-dev]$ hg log -r 13064
changeset: 13064:733a706c5f5b
user:Lisandro Dalcin
date:Wed Dec 03 20:00:58 2008 -0300
summary: smarter VecPlaceArray/VecResetArray
[dalcinl at botafogo petsc-dev]$ hg backout -r 13064
reverting src/vec/vec/im
On Wed, Dec 3, 2008 at 9:17 PM, Barry Smith wrote:
>
> That is wierd; it seems strange that it would even compile.
OK, I'll try to review all this tomorrow, there are some other weird
Vec calls with such "const".
>BTW: I think your new change
> 7 - v->unplacedarray = v->array; /* save prev
Yes, but those VecCreateXXXWithArray() and null arrays are intended
for create stub vecs for something like creating a VecScatter(). If
PETSc creates such vector, it sould never return, or expose them to
users, they do not have allocated space.
I cannot see a use case of placing a NULL array. The
Barry, please revert the commit, I'll try to re-review this tomorrow.
I'm goin to bed.
On Wed, Dec 3, 2008 at 10:40 PM, Lisandro Dalcin wrote:
> Barry, are you talking about Vec's of local size zero? Damn me! I
> completelly forgot this case... But then, will not it be better to
> check and speci
Barry, are you talking about Vec's of local size zero? Damn me! I
completelly forgot this case... But then, will not it be better to
check and special case zero local sizes ??
On Wed, Dec 3, 2008 at 10:37 PM, Lisandro Dalcin wrote:
> On Wed, Dec 3, 2008 at 9:17 PM, Barry Smith wrote:
>>
>> Tha
On Wed, Dec 3, 2008 at 9:17 PM, Barry Smith wrote:
>
> That is wierd; it seems strange that it would even compile.
OK, I'll try to review all this tomorrow, there are some other weird
Vec calls with such "const".
>BTW: I think your new change
> 7 - v->unplacedarray = v->array; /* save prev
On Wed, Dec 3, 2008 at 8:08 PM, Matthew Knepley wrote:
> On Wed, Dec 3, 2008 at 5:04 PM, Lisandro Dalcin wrote:
>>
>> I've pushed some fixes for VecPlaceArray/VecResetArray, trying to the
>> pair a bit more smarter. However, the I'm not sure what's the use case
>> in VecPlaceArray for accepting N
I've pushed some fixes for VecPlaceArray/VecResetArray, trying to the
pair a bit more smarter. However, the I'm not sure what's the use case
in VecPlaceArray for accepting NULL for the array. Just in case, I did
not changed this, but if NULL is actually pased, then the call is now
non-op. Is this f
VecPlaceArray(Vec vec,const PetscScalar array[])
VecReplaceArray(Vec vec,const PetscScalar array[])
--
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 In
Sorry, I don't know how to revert something that has been pushed.
Can someone do it who has a brain?
Barry
On Dec 3, 2008, at 7:41 PM, Lisandro Dalcin wrote:
> Barry, please revert the commit, I'll try to re-review this tomorrow.
> I'm goin to bed.
>
> On Wed, Dec 3, 2008 at 10:40 PM, L
One can call VecCreateXXXWithArray() with a null pointer for the
array so that
means there is already an established history of valid Vecs with null
arrays.
I'd like you do undo the changes you made unless you have a specific
reason
for making the change (besides the reason of not having
That is wierd; it seems strange that it would even compile.
BTW: I think your new change
7 - v->unplacedarray = v->array; /* save previous array so reset can
bring it back */ 8
- v->array = (PetscScalar *)a; 9 +
if (a) { 10 + v->unplacedarray = v->array; /* save previous array so
r
On Wed, Dec 3, 2008 at 5:28 PM, Barry Smith wrote:
>
> The normal pattern (for example MPIAIJ, MPIBAIJ) is for the PetscMap setup
> being done in the associated MatXXXSetPreallocation() routine.
>
> I think the correct fix is
> 1) change the ierr = MatSetSizes(*A,m,n,PETSC_DETERMINE,n);CHKERR
It's my guess, too. I'm going to push this.
On Wed, Dec 3, 2008 at 4:41 PM, Barry Smith wrote:
>
> My guess is you can/should remove the zero completely.
>
> Barry
>
> On Dec 3, 2008, at 12:09 PM, Lisandro Dalcin wrote:
>
>> Please, review the changeset below, just pushed. Why is the memzero
>>
s scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20081203/b7ddf925/attachment.html>
Please, review the changeset below, just pushed. Why is the memzero
call being issued? Should it be completely removed?
changeset: 13056:4ea189951503
tag: tip
user:Lisandro Dalcin
date:Wed Dec 03 16:06:12 2008 -0200
summary: protect memzero call in MatSetSizes_SeqDen
Sorry, my comment about PETSC_COMM_SELF was a nonsense :-(
Let me write the rule in C-Python-pseudocode
rank = mat->comm->rank
size = mat->comm->size
cmap->N = # total_columns
for p in range(size):
if p == rank:
mat->cmap->n = cmap->N
else:
mat->cmap->n = 0
# and finally
Pets
The normal pattern (for example MPIAIJ, MPIBAIJ) is for the
PetscMap setup
being done in the associated MatXXXSetPreallocation() routine.
I think the correct fix is
1) change the ierr =
MatSetSizes(*A,m,n,PETSC_DETERMINE,n);CHKERRQ(ierr);
in MatCreateMPIAdj to ierr =
MatSetSizes(*
Can someone help me to review this routine?
MatCreate_MPIAdj(Mat B)
I understand that MATMPIADJ is rather special, but the call above is never made
PetscMapSetUp(B->cmap)
then It seems that some stuff (ranges) in the column map will be uninitialized.
What values should have the entries in "cma
My guess is you can/should remove the zero completely.
Barry
On Dec 3, 2008, at 12:09 PM, Lisandro Dalcin wrote:
> Please, review the changeset below, just pushed. Why is the memzero
> call being issued? Should it be completely removed?
>
> changeset: 13056:4ea189951503
> tag: t
20 matches
Mail list logo
