dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Wednesday 07 January 2009 10:30:44 Kent Andre wrote:
> On ti., 2009-01-06 at 23:29 +0100, Johan Hake wrote:
> > Hello!
> >
> > I have now got some of the shared_ptr stuff combined with python up and
> > going.
> >
> > The function interface, with shared functions and function_space should
> > just work. This includes compiled functions. The nice thing with these is
> > they only refer to our own library, i.e., Py/DOLFIN and they don't have
> > to be compatible with other Py-library.
>
> Good! It seems to work now.

Well, this should be somthing that lives on your computer. I have not checked 
in anything.

> > I havn't looked into the la objects yet. I lack a good example of where
> > it is used. All la stuff in pure dolfin library use wants a
> > GenericMatrix, (right?) and as far as I am concerned we cannot use a
> > shared Epetra_FECrsMatrix or Epetra_FeVector in the PyTrilinos interface.
> > This means that we either way need access of the underlaying pointer or
> > reference to interact with PyTrilinos.
>
> How do we access the underlying pointer of a shared pointer from Python?
> When I tried yesterday it was of type 'SwigObject'. Did you fix this ?

Nope. 

But I think, you and I just solved this with a our small talk in real life ;) 

For the list:

We discussed tree user cases wrt shared_ptrs in python, please add more if you 
come across any (Martin?):

1) wrapping and passing of instances from pure PyDOLFIN classes. Here we can 
produce our own typemaps which all kicks in at the right place.

2) wrapping and passing of instance from classes produced by instant, e.g., 
ffc jit compiled objects. Here I think we need to include the type 
informations and the right typemaps from, let say an ufc.i file. This should 
be doable and should hopefully work, with ref counting and all that.

3) wrapping and passing of instances to other libraries, PyTrilinos comes in 
mind. Here we can %ignore the function returning the shared_ptr<foo> 
and %extend the c++ proxy class with the same function which just dereference 
the shared_ptr.

Any comments?

Johan

> Kent
>
> > I haven't been able to wrap the compiled ufc objects yet. I have an idea
> > of how this can be done and why it did not work the first time I gave it
> > a try. To be able to get it working I think we need to extend ufc.
> >
> > In ffc jit and in dolfin, where we all use derived classes of ufc::foo,
> > we need to be able to %import some definition of these classes from some
> > where. I have started to scetch on an ufc.i file which does this, but I
> > need some response to whether this is the right way to do it.
> >
> > The thing is that these shared_ptr base classes need to be defined at
> > _one_ place and then %imported where they are used, typically in ffc/jit
> > and in dolfin. Intuitively I think that it would be appropriate to define
> > them in ufc.
> >
> > Where such a file should then be installed is another thing but following
> > the convention of dolfin whould this then be installed in:
> >
> >   $PREFIX/include/swig/ufc.i
> >
> > Johan
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/mailman/listinfo/dolfin-dev