an small and perhaps unimportant gotcha
Barry Smith
bsmith at mcs.anl.gov
Tue Dec 2 12:46:04 CST 2008
Yup, this comes from trying to patch more and more flexibility on
a system
that wasn't originally designed for that particular flexibility. The
matrix and vector
are in a strange state at this point that is not defined by our
original design.
One way we can mangle our minds around this is to say "the TYPE of
the
Vec/Mat has not been set yet", we have merely "changed the default type
it will become". This isn't completely accurate but that's what
happens when
you pretend there is dark matter to explain why some observation doesn't
match relativity theory and it sounds real cool.
At this point I think we just have to live with this weirdness,
unless
you have a solution.
Barry
On Dec 2, 2008, at 9:12 AM, Lisandro Dalcin wrote:
> Other (really nice!) change I've noticed is that now we can call
> {Vec|Mat}Create() and next {Vec|Mat}SetType() and it works!
>
> However, see this.
>
> In [1]: from petsc4py import PETSc
>
> In [2]: x = PETSc.Vec().create()
>
> In [3]: x.setType('seq')
>
> In [4]: print x.getType()
>
> None
>
> In [5]: A = PETSc.Mat().create()
>
> In [6]: A.setType('seqaij')
>
> In [7]: print A.getType()
>
> None
>
>
> Internally, the "type_name" field is never set, it still is NULL (then
> petsc4y returns None).
> The problem is that forcing the "type_name" to be set will be really
> dangerous (rmember PetscValidType macro).
> Any comments?
>
>
>
> --
> 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
>
More information about the petsc-dev
mailing list