dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Wednesday 04 March 2009 14:17:44 Anders Logg wrote:
> On Wed, Mar 04, 2009 at 02:06:53PM +0100, Johan Hake wrote:
> > On Wednesday 04 March 2009 13:50:18 Anders Logg wrote:
> > > On Wed, Mar 04, 2009 at 01:39:10PM +0100, Johan Hake wrote:
> > > > On Wednesday 04 March 2009 13:34:17 Anders Logg wrote:
> > > > > On Wed, Mar 04, 2009 at 01:28:10PM +0100, Johan Hake wrote:
> > > > > > On Wednesday 04 March 2009 13:17:37 Garth N. Wells wrote:
> > > > > > > When running demo/mesh/intersection/demo.py, I get
> > > > > > >
> > > > > > >      Traceback (most recent call last):
> > > > > > >        File "demo.py", line 33, in <module>
> > > > > > >          cells = STLVectorUInt()
> > > > > > >      NameError: name 'STLVectorUInt' is not defined
> > > > > > >
> > > > > > > Any ideas?
> > > > > >
> > > > > > Should be fixed now
> > > > >
> > > > > How is the STL integration with Python lists? The optimal thing
> > > > > would be if one could write
> > > > >
> > > > >   cells = omega0.intersection(boundary, False)
> > > > >
> > > > > instead of
> > > > >
> > > > >   cells = STLVectorUInt()
> > > > >   omega0.intersection(boundary, cells, False)
> > > > >
> > > > > and cells would be a Python list.
> > > >
> > > > Agree on this.
> > > >
> > > > Should be doable with the right typemaps.
> > > >
> > > > I can fix it but not right now...
> > >
> > > ok, nice.
> > >
> > > > Is this the only place where we use STLVectorFoo?
> > >
> > > Yes, at least in the demos. It (std::vector) appears in quite a few
> > > places now in function calls in the C++ interface, but it's mostly
> > > invisible from Python. For example, the Assembler uses this but it's
> > > wrapped and handled from Python with standard Python lists or tuples.
> >
> > Ok, I see that it is needed in assemble_system and VariationalProblem
> > also use it. I think it would be doable to remove all these from the
> > python interface, with a proper typemap.
> >
> > I could e.g. add a typemap macro for all type Foo, that we want to be
> > able to pass to the c++ as std::vector<Foo>, using any iterable from
> > python, e.g., tuple, list and numpy arrays.
>
> Sounds good.
>
> > The output typemap of intersection detector will probably need some extra
> > attention.
> >
> > Johan
>
> Is there a nice way to handle those cases where functions return
> something. Another such example is eval() in Function which now
> requires the value as an argument. The demo function/eval/python/
> looks pretty silly now:
>
>   x = array((0.31, 0.32, 0.33))
>   values = array((0.0,))
>   f.eval(values, x)
>
> Instead of just
>
>   x = array((0.31, 0.32, 0.33))
>   values = f.eval(x)

Probably, but there are times you do not want that, e.g., when you want to 
evaluate the function into an allready excisting array. That could be handled 
with optional args.

These typemaps wont kick in for python overloaded evals. Which means that the 
user need to implement it him self, e.g:

...
   def eval(values, x=None):
       if x is None:
           return_values = True
           x = values
           values = numpy.zeros(self.geometric_dimension())
        ...
        if return_values:
           return values


Johan