ufl team mailing list archive

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

So... This obviously doesn't construct Form instances, but long tuples.
I see how this tuple can be interpreted if you _know_ that it is supposed
to be a Form, so in principle all UFL algorithms can do "form = as_form(form)"
at the top to convert input argument.

But... In load_forms, how can I differentiate between the variables
  a = (u, v) # supposed to be a form
and
  tmp = (u, v) # just a random tuple
or equivalently
  foo = bar() # returns some tuple of expressions that are handy to
compute together
?

The point being, this is not only additional syntax sugar,
but it restricts the features you can use as a side-effect.

Perhaps this should be a PyDOLFIN feature?

Martin



2009/3/30 Anders Logg <logg@xxxxxxxxx>:
> On Mon, Mar 30, 2009 at 02:15:25AM +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:   778:540ea93daca99a3893f2a1417d1c97eeea2e9479
>> tag:         tip
>> user:        Anders Logg <logg@xxxxxxxxx>
>> date:        Mon Mar 30 02:14:58 2009 +0200
>> files:       ufl/form.py
>> description:
>> Implement short-hand inner product notation (v, u)
>
> Just arrived in LA and wanted to push something I played with on the
> plane.
>
> I've modified form.py to allow a Form to be initialized from a tuple
> of integrands and optional measures. It's a small fix, just an added
> function call in the constructor that extracts the proper
> integrals. Note that no operator overloading is used to accomplish
> this. The expression is just written as a common Python tuple from
> which the UFL Form is extracted.
>
> The new notation (which is optional) allows the use of the inner
> product notation commonly used in the formulation of most finite
> element methods.
>
> Here are some examples:
>
> Poisson:
>
>  a = (grad(v), grad(u))
>
> Convection-diffusion-reaction:
>
>  a = (v, dot(beta, grad(u))) + (grad(v), grad(u)) + (v, u)
>
> DG Poisson:
>
>  a = (grad(v), grad(u))
>    + (alpha/h('+')*jump(v, n), jump(u, n), dS)
>    + (gamma/h*v, u, ds)
>    ...
>
> A term is specified either as a tuple
>
>  (expr1, expr2)
>
> or as a triple
>
>  (expr1, expr2, measure)
>
> If no measure is specified, then dx is used.
>
> Caveats:
>
> 1. Subtraction does not work, so one needs to do
>
>  a = (grad(v), grad(u)) + (-v, u)
>
> 2. Mixing notation does not work:
>
>  a = (grad(v), grad(u)) + v*u*dx
>
> Does this seem ok? I think it's pretty cool. :-)
>
> --
> Anders
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAknQEn0ACgkQTuwUCDsYZdG4mQCeIkCbjXFrj3xniVMpJEFky9j5
> 1QcAn3D5Q0eR9zVSF2Bh0X0DpCPDwkjC
> =bkQc
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> UFL-dev mailing list
> UFL-dev@xxxxxxxxxx
> http://fenics.org/mailman/listinfo/ufl-dev
>
>