← Back to team overview

dolfin team mailing list archive

Re: [UFC-dev] python and shared_ptr status

 

On Wed, Jan 7, 2009 at 10:22 AM, Johan Hake <hake@xxxxxxxxx> wrote:
> On Wednesday 07 January 2009 00:29:52 Garth N. Wells wrote:
>> 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.
>> >
>> > I havn't looked into the la objects yet. I lack a good example of where
>> > it is used.
>>
>> demo/la/trilinos/python/demo.py
>>
>> 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.
>>
>> What isn't this possible?
>
> 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

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

Martin


Follow ups

References