dolfin team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

2008/12/6 Johan Hake <hake@xxxxxxxxx>:
> On Saturday 06 December 2008 14:48:34 Anders Logg wrote:
>> On Sat, Dec 06, 2008 at 02:41:55PM +0100, Johan Hake wrote:
>> > On Saturday 06 December 2008 14:23:40 Anders Logg wrote:
>> > > On Sat, Dec 06, 2008 at 12:02:43PM +0100, Johan Hake wrote:
>> > > > On Friday 05 December 2008 18:02:07 Anders Logg wrote:
>> > > > > I'm having problems getting vector-valued constants working. Take a
>> > > > > look at
>> > > > >
>> > > > >     demo/pde/stokes/taylor-hood/python
>> > > > >
>> > > > > It reports
>> > > > >
>> > > > >     assert(isinstance(defaults[i], (dict, types.NoneType)),"Wrong
>> > > > > type in 'defaults'")
>> > > > >    TypeError: 'NoneType' object is unsubscriptable
>> > > > >
>> > > > > It seems like defaults is set to None and then defaults is indexed.
>> > > > >
>> > > > > Any ideas?
>> > > >
>> > > > Should be fixed now. I have added better argument checking to
>> > > > compile_function. But you have to send in a tuple of strings to
>> > > > compile_function if you want to produce a vector values function. A
>> > > > list is interpreted as len(cppexpr) number of scalar functions.
>> > > >
>> > > > This is a bit fragile, but it is documented in the Function doc
>> > > > string.
>> > >
>> > > ok! I wasn't aware of the difference.
>> > >
>> > > Maybe we should have both compile_function and compile_functions
>> > > instead of differentiating between tuples and lists?
>> > >
>> > > There is already a compile_functions defined in compile_functions.py,
>> > > but that does not seem to be used. Should it be removed (and the name
>> > > reused for batch-processing functions)?
>> >
>> > compile_functions.py is the orginal work of Martin. It is depricated now.
>> >
>> > The compile_function module should not be exposed to the user, (Martin
>> > might have a different opinion here) so it should be sufficient with the
>> > Function interface.
>> >
>> > The differences between compiling one and several functions are so small
>> > that I do not think it is usefull to split the code into different
>> > modules.
>> >
>> > One could use the name Functions, instead of Function for batch
>> > processing. In this way we make clear for a user what it means. This also
>> > correlates with the TestFunction/TestFunctions.
>> >
>> > Unfortunaltly will not the case of defining several functions in a
>> > cppcode, argument be covered by this, as the number of compiled functions
>> > will depend on how many functions the user defines in the cppcode. For
>> > this case we could add CostumFunctions, or something.
>> >
>> > Or just keep it the way it is with clearer documentation?
>>
>> Wouldn't it be easy to add an additional argument batch=False to
>> compile_function? Then you could check that argument instead of
>> differentiating between lists and tuples.
>
> So,
>
>  f = Function(V,cppexpr = (("sin(x[0])","cos(x[1])"),
>                           (("sin(x[1])","exp(x[1])"))))
>
> would create a tensor valued function and:
>
>  f, g = Function(V,cppexpr = (("sin(x[0])","cos(x[1])"),
>                              (("sin(x[1])","exp(x[1])")),
>                               batch = True)
>
> would create two vector valued functions. Then we need to explain that the use
> of batch = True, change the meaning of the outermost parentesis from a matrix
> expression to a list expression of two vectors. I have bad feeling...
>
> We could also be a bit radical and adapt a pylab.plot interface to the
> compile_function module
>
>  f, c = FunctionExpression(V0,("sin(x[0])","cos(x[1])"),V1,"2.5")
>
> where a space followed by an expression will associate the space with that
> expression. We can have an optional number of (V, cppexpr) combinations. And
> the natural extension of:
>
>  f0, f1, f2  = FunctionExpression("sin(x[0])","cos(x[1])","2.5", space = V)
>
> where each compiled function is instantiated with the function space defined
> in 'space'. This could be followed up with e.g:
>
>  CostumFunction(V0,code0,V1,code1)
>
> and
>
>  CostumFunction(code0,code1, space = V)
>
> (The names may not be the best...)
>
> Johan

I like

f0, f1, f2 = Functions(V0, code0, V1, code1, V2, code2)

e.g.

f0, f1, f2 = Functions(V0, "sin(x[0])",
                                 V1, ("cos(x[0])", "sin(x[1])"),
                                 V2, (("a", "b"), ("c", "d")))

(we will remove Functions from UFL, so I guess the naming is ok after all).

Have you kept the automatic variable construction? The code above would
make a, b, c, d double variables of f2:
  f2.a = 1.23

--
Martin