dolfin team mailing list archive

[Johan Hake <hake@xxxxxxxxx>]

On Saturday 06 December 2008 14:58:29 Martin Sandve Alnæs wrote:
> 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.

This is a case for the assemble function, and not for the compile function 
interface. It has nothing to say for that implementation if you send a pure 
cpp.Function or full fledged dolfin.Function (which also is a cpp.Function) 
in the coefficient list to assemble().

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

Thats true, but the real estate of the code is smaller with a batch 
expression. 

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

Ok.

Johan

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