dolfin team mailing list archive

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

2008/12/6 Johan Hake <hake@xxxxxxxxx>:
> 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?

I like that better than the "batch=True" variant.

>> 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 _only_ thing I care about is that pure UFC should be supported, and
therefore that compiling functions works when using pure UFC code.

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

On the second run of the application, cache diminishes the cost,
but the first time it may be costly. But I agree, it's not a big issue.

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

That's not the same thing. TestFunctions returns subfunctions in a mixed space,
while Functions here would return multiple functions in different spaces.
Slightly confusing?

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

--
Martin