ufl team mailing list archive

[kent-and@xxxxxxxxx]

> 2008/6/19 Kent-Andre Mardal <kent-and@xxxxxxxxx>:
>> to., 19.06.2008 kl. 15.39 +0200, skrev Martin Sandve Alnæs:
>>> We could collect them more explicitly:
>>>   a = u*v*dx
>>>   L = f*v*ds
>>>   bc = T*u == g
>>>   Axb = System(a, L, bc)
>>
>>
>> Yes, or even
>>
>> Axb = System ( u*v*dx == f*vdx, T*u == g)
>
> Even better!
>
>
>>> Basically, we could do something like:
>>>
>>>   bc = T*u_components == expression
>>>
>>> Here expression is any UFL-expression, which is compiled into some
>>> future extension of UFC.
>>>
>>> u_components will typically be:
>>>   u - all values (in case of non-scalar element)
>>>   u[0] - a single component (vector valued element, must be fixed
>>> integer)
>>>   u[0, 1] - a single component (tensor valued element, must be fixed
>>> integers)
>>>   dot(u, n) - normal component of u (handled differently depending on
>>> element!)
>>>
>>> We _could_ define a small set of valid expressions for u_components
>>> like the list above, if we are sure we can cover everything we need.
>>
>> But aren't these already in UFL.
>
> The syntax for the items in the list above, yes, and we'll reuse that.
> But it doesn't make sense in this context to write f.ex.
>   T*exp(f)*u == g,
> so the list above is a suggestion for what we define as valid in place
> of u_components.
>
>

I see.

>>> Also, in many cases you'll want to just fix one point to avoid
>>> translation.
>>> This kind of situation makes it difficult...
>>>
>>
>> I guess one would the mark one node and have a subdomain which is really
>> only a node (?).
>
> That should work.
>
>
> I'm convinced that we can at least cover most boundary conditions
> with this, but I'd like to see how it's best implemented in the
> assembler before we design the UFC extension and incorporate
> this into the form compilers.
>
> --
> Martin
>

I will start playing with the Assembler shortly and will probably get back
to you
next week.

Kent