request for comments/advices about mapping PetscCookie -> Python Type

[Barry Smith]

     Lisandro,

       In the current model of initializations there are two submodels

1) no dynamic libraries (example Mat, others should be the same)

    MatCreate() ALWAYS calls MatInitializePackage(). Inside  
MatInitializePackage()
is a static variable indicating if initialization has take place.

    The user is not allowed to call any other Mat... methods BEFORE  
MatCreate(),
if they do bad things could happen. For example, you cannot call  
MatNorm() if you
have not yet created a Mat.

2) dynamic libraries

     when the libpetscmat.so dynamic library is opened by PETSc,  
MatInitializePackage()
is automatically called.  PetscInitialize() automatically opens all  
the standard
dynamic libraries like libpetscmat.so

    If the user calls any Mat routine before PetscInitialize() it  
won't work. If the
user calls MatNorm() before a MatCreate() it will not work, but not  
for the same
reason as 1), only because they are not passing a matrix in.


   With python you care about the dynamic case: so long as your python  
initialization
occurs after PetscInitialize() which it must and will ALL packages  
have been registered
(unless we have a bug).  So I think your code should be fine. You say  
that you can use the PETSC_COOKIE of zero
to find such a bug, a pretty weak argument.

   I don't like the idea of you using the MAT_COOKIE directly at all  
for your cool
python dictionary building. Reason: it is not extensible. Some one  
adds a new
ZAP_COOKIE and you don't know about it and when you find out you have  
to go
change your code. Correct?

   Here is an alternative model that I think is much better. Every  
call to PetscCookieRegister()
actually registers the cookie (currently it is not recorded in any  
way,  it is only registered in the logging)
with the name; could be into something as ugly as a global array or   
linked list.  Your python "caster"
(each times it needs to cast) then could look in this global array or  
linked list and do the
translation. This way your caster will always work; if later in the  
run someone registers
new cookies your caster now has access to it. Now your python code  
doesn't ever
need to see, touch or taste a XXX_COOKIE variable directly; I view the  
global XXX_COOKIE variables
as private to that class implementation and really don't want any  
other code outside that class
touching them directly.

   Sound workable?

    Barry

I am assuming that your Python caster only needs to know the string  
name of the class (like "Mat") to manage the
caste.  If it actually needs specific code written for each class then  
I would like that specific code to be inside
that class and not managed in some central location (that is, it would  
go somewhere in the src/mat/.... directory tree.








On Oct 10, 2008, at 1:31 PM, Lisandro Dalcin wrote:

> In petsc4py, I've just implemented support for compose()/query() in my
> base Object class. However, I wanted to implement query() in such a
> way that 'dynamic_cast' (in the C++ sense, i.e, downcast) the composed
> PETSc object and return to Python code an instance of the appropriate
> Python type. Then, if you compose() a Mat, then query() will return a
> Mat.
>
> I manages all this inside a private python dictionary mapping
> PetscCookie -> Python type. Of course, this required to make sure that
> ALL PetscXXXInitializePackage() have been called before adding stuff
> to my dict. All is working fine; moreover, this machinery is also
> being used in slepc4py and tao4py (yes, I have those...), then after
> importing slepc4py or tao4py, the dictionary is populated as
> appropriate.
>
> Then, the question are: Do this approach sound good enough? Is it too
> much hackery? Can I relly in the long future that this approach will
> always work?
>
> BTW, now I have a clear use case for initalizing all the XXX_COOKIE's
> to 0 in core PETSc. This will really help me to spot package
> initialization problems. In fact, I had to manage some of those
> problems in petsc-2.3.2, petsc-2.3.3 and tao-1.9 .
>
> PS: The renaming DA_COOKIE -> DM_COOKIE does not play well with all
> this, but I do not care about it right now.
>
>
> -- 
> 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
>