← Back to team overview

ufl team mailing list archive

Re: [HG UFL] Implemented better version of tuple syntax:

 

I'm ok with the "forms / (a,L,M)" feature, and that pretty much
solves the interpretation problem for (u,v) in that context.
We should also have an optional list "elements" like "forms".
I like
  forms = [a, L]
better, quotes are unnecessary.

In the context of PyDOLFIN, PyDOLFIN can itself check for
tuple or Form, so we don't need to check it everywhere.

It is possible to have a function "as_form(form)" in UFL to
help with this, but it would be nice to not have to call this
all over the place just so you can write the mass matrix
with three letters less ;-P

But I think (f,v)*ds is more readable than (f,v,ds) and
they're exactly the same length,

  a = (u,v) + (f,v)*ds

so we don't need the (f,v,ds) syntax, ok?

Martin



2009/3/30 Anders Logg <logg@xxxxxxxxx>:
> On Mon, Mar 30, 2009 at 03:28:32PM +0200, Anders Logg wrote:
>> On Mon, Mar 30, 2009 at 02:00:51PM +0200, UFL wrote:
>> > One or more new changesets pushed to the primary ufl repository.
>> > A short summary of the last three changesets is included below.
>> >
>> > changeset:   780:bc9680be05bfd5048c3de1fbcc2f9281c3f2c5ef
>> > tag:         tip
>> > user:        "Martin Sandve Alnæs <martinal@xxxxxxxxx>"
>> > date:        Mon Mar 30 14:02:24 2009 +0200
>> > files:       ufl/algorithms/formfiles.py ufl/integral.py
>> > description:
>> > Implemented better version of tuple syntax:
>> >
>> >   a = (u,v)*dx + (f,v)*dx
>> >
>> > in this case a is a Form, so no changes are needed anywhere else.
>>
>> Nice. I thought about this (implementing __rmul__ to handle tuples)
>> but wanted the even shorter version (without dx).
>>
>> Can we keep both options?
>>
>> I haven't figured out how to make load_forms work though. The current
>> implementation seems to extract *all* forms from a file, which may not
>> always be appropriate. One might want to keep contributions in
>> separate variables and then add up the results:
>>
>>   CONV = (v, dot(beta, grad(u)))*dx
>>   DIFF = (grad(v), grad(u))*dx
>>   a = CONV + DIFF
>>
>> Code should here be generated only for the form a, not CONV and DIFF.
>>
>> FFC solves this by using reserved variable names for forms:
>>
>>   a: bilinear form
>>   L: linear form
>>   M: functional
>>
>>   element: single element
>
> If this is not enough, load_forms could also look for a variable named
> "forms" that lists the forms that should be compiled:
>
>  forms = [a0, a1, L]
>
> or
>
>  forms = ["a0", "a1", "L"]
>
> and if this is not found there could be a sensible default (like a, L,
> M).
>
> --
> Anders
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAknQyzYACgkQTuwUCDsYZdGHeQCfdv4PqTb/Hj5SEdiFbHnYKrKN
> mvcAn2URikn1MlQOSP56bBJq+QaY29Vu
> =e1k9
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> UFL-dev mailing list
> UFL-dev@xxxxxxxxxx
> http://fenics.org/mailman/listinfo/ufl-dev
>
>


Follow ups

References