[petsc-dev] Semantics for v.getArray()
Lisandro Dalcin
dalcinl at gmail.com
Mon Aug 23 09:04:21 CDT 2010
On 23 August 2010 10:38, Matthew Knepley <knepley at gmail.com> wrote:
> I am unclear what they are. There is no restoreArray() and I do not
> understand setArray().
This is something we should have to discuss and eventually improve...
* For older Python and NumPy versions (actually, not so older, let say
Py<=2.6), getArray() only works for 'native' PETSc vectors... it is
implemented by calling VecGetArray() and immediatly VecRestoreArray(),
but I hold the pointer value and use it for creating a NumPy array
sharing memory with the vector.
* For newer Python (2.7) and NumPy (1.5) versions, this is implemented
using other Python protocols. In this case, when you call getArray(),
VecGetArray() is called and a NumPy array is built... When the NumPy
array is garbage collected, VecRestoreArray() is called.
* vec.setArray(a) is just sugar for copying the contentes of array 'a'
in the vector 'vec', i.e, VecGetArray()+memcpy()+VecRestoreArray().
Additionally, it handles scalar (i.e, non-array) arguments specially,
eg. vec.setArray(vec.comm.rank) will fill with zeros at P0, with ones
at P1, and so on (note that VecSet() would not work for this).
getArray()/restoreArray() is unpythonic, and relying in garbage
collection for calling restoreArray() is really dangerous. Perhaps I
should add restoreArray() anyway? What do you think the semantics
should be? What should happen with the NumPy array after
restoreArray() ? I would hate to maintain in Python land a NumPy array
with a dangling pointer.
--
Lisandro Dalcin
---------------
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169
More information about the petsc-dev
mailing list