Subject: [UFC-dev] python and shared_ptr status

From: Johan Hake <[email-masked]>
Date: Tue, 6 Jan 2009 23:29:56 +0100

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.

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.

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

---

From: "Garth N. Wells" <[email-masked]>
Date: Tue, 06 Jan 2009 23:29:52 +0000

Johan Hake wrote:
> used. 

demo/la/trilinos/python/demo.py

All la stuff in pure dolfin library use wants a GenericMatrix, (right?)
> Epetra_FeVector in the PyTrilinos interface. 

What isn't this possible?

Garth

This means that we either way
> _______________________________________________
> DOLFIN-dev mailing list
> [email-masked]
> http://www.fenics.org/mailman/listinfo/dolfin-dev

---

From: Johan Hake <[email-masked]>
Date: Wed, 7 Jan 2009 10:22:49 +0100

On Wednesday 07 January 2009 00:29:52 Garth N. Wells wrote:
> > 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.
> >
> > I havn't looked into the la objects yet. I lack a good example of where
> > it is used.
>

Short answer, no.

Long answer:

PyTrilinos need to be compiled with shared_ptr support. If the underlying 
library does not have a shared_ptr interface, which I am quite sure Trilinos 
does not have, it is that libraries responsability to include a shared_ptr 
typemaps to handle situations where it get this type. These typemaps is what 
I am about to include for PyDOLFIN, i.e., making it possible to pass a python 
objects that are stored using shared_ptr to function accepting pointers, 
references, or shared_ptr, but I doubt PyTrilinos is compiled with this 
support.

Johan

> > 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:
> >

---

From: "Martin Sandve Alnæs" <[email-masked]>
Date: Wed, 7 Jan 2009 10:29:52 +0100

> references, or shared_ptr, but I doubt PyTrilinos is compiled with this

And to complicate further PyTrilinos has wrapper classes around the
C++ Epetra classes...

Martin

---

From: Kent Andre <[email-masked]>
Date: Wed, 07 Jan 2009 10:30:44 +0100

> compatible with other Py-library.

Good! It seems to work now. 

Kent

> need access of the underlaying pointer or reference to interact with 

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 ? 

Kent

---

From: Johan Hake <[email-masked]>
Date: Wed, 7 Jan 2009 11:00:59 +0100

> Good! It seems to work now.

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

> > 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.
>

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

---

From: Johan Hake <[email-masked]>
Date: Wed, 7 Jan 2009 11:22:40 +0100

On Wednesday 07 January 2009 10:29:52 Martin Sandve Alnæs wrote:
> >> > 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.
> >> >
> >> > I havn't looked into the la objects yet. I lack a good example of
> >> > where it is used.
> >>
> >> > and as far as I am concerned we cannot use a shared Epetra_FECrsMatrix
> >> > or Epetra_FeVector in the PyTrilinos interface.
> >>
> > library does not have a shared_ptr interface, which I am quite sure
> > Trilinos does not have, it is that libraries responsability to include a
> > shared_ptr typemaps to handle situations where it get this type. These
> > typemaps is what I am about to include for PyDOLFIN, i.e., making it
> > possible to pass a python objects that are stored using shared_ptr to
> > function accepting pointers, references, or shared_ptr, but I doubt
> > PyTrilinos is compiled with this support.
> >
> > Johan
>

That's true. 

But if PyTrilinos was swigged using shared_ptr typemaps it should in theory 
just work. Then we could for example %import this interface while swigging 
DOLFIN, and produce full fledged swigwrapped Epetra objects, using 
shared_ptrs, which then could be passed to the PyTrilinos library.

Johan