ufl team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Sep 30, 2008 at 09:42:46AM +0200, Martin Sandve Alnæs wrote:
> 2008/9/30 Anders Logg <logg@xxxxxxxxx>:
> > On Mon, Sep 29, 2008 at 11:49:31PM +0200, Martin Sandve Alnæs wrote:
> >> 2008/9/29 Anders Logg <logg@xxxxxxxxx>:
> >> > On Mon, Sep 29, 2008 at 11:03:14PM +0200, Martin Sandve Alnæs wrote:
> >> >> I was wondering how you intended to use that :)
> >> >
> >> > I was planning to count the number of products each basis function
> >> > appeared in. That worked but then I realized that's not what we need.
> >> > We need to know how many of each basis function appears in a product.
> >>
> >> And that no basis functions appear as arguments to nonlinear functions like exp.
> >
> > Yes.
> >
> >> You commented that is_multilinear is FFC-specific. But a valid form must
> >> always be multilinear in the basis functions, but not in functions. Right?
> >
> > Yes.
> >
> >> >> Lets discuss how to best do this soon, I can show you
> >> >> how I've been thinking in the other algorithms as well.
> >> >
> >> > It can be easily implemented using the monomials() function I just
> >> > added. It returns a list of tuples, where each tuple is a product of
> >> > basis functions.
> >> >
> >> > The final monomials() function will do some more, like propagating all
> >> > linear (differential) operators to the basis functions.
> >>
> >> I was considering that propagation a part of the AD implementation.
> >> If we write algorithms separately we'll probably duplicate several things
> >> in different but non-orthogonal ways.
> >>
> >> Is this monomials() approach to is_multilinear possible to generalize
> >> to non-polynomial forms? Otherwise it's very FFC specific.
> >
> > Yes, maybe. Perhaps I should move that code to FFC?
> 
> It's difficult to know what we'll need both places. It's not a problem to have
> algorithms in UFL that we don't use in both SFC and FFC though, as long
> as the algorithms are general and don't have external dependencies.

ok, I'll keep it in UFL until it becomes obvious it should be moved to
FFC. I don't plan to add any new dependencies, just one or two
functions that extract data from UFL expressions.

> > I can try to implement is_multilinear (in the sense that all forms
> > must be multilinear, not just FFC forms) based on monomials(), remove
> > monomials(), and put an extended version of monomials() in FFC if it's
> > not something that is generally useful to have in UFL.
> >
> 
> Add as much as you like to UFL, but please be careful about modifying
> existing algorithms without asking me first, in case there's something
> I'm using.

I promise. ;-)

-- 
Anders

Attachment: signature.asc
Description: Digital signature