ufl team mailing list archive

[kent-and@xxxxxxxxx]

> 2008/6/23  <kent-and@xxxxxxxxx>:
>>> If we should add notation for boundary conditions to UFL, then I think
>>> it must also be supported through the UFC interface so that the
>>> assembler may assemble the correct matrix/vector directly (without
>>> zeroing out entries in a separate step).
>>
>> I don't understand what you mean with this. It has to be a separate step
>> that is performed after the tabulate_tensor functions.
>
> The assembler cannot use UFL directly, and UFL is supposed to pass
> through a form compiler. Somebody must convert the UFL to something
> the C++ assembler can eat, and UFC is the interface we hide equation
> details behind. Unless you have a better option?
>

I agree that UFL objects cannot be used directly.

>
>>> Regarding the notation, maybe it should be a constraint on the
>>> function spaces. Take for example Poisson with u = g on the boundary:
>>>
>>>   Find u in H^1_g : a(v, u) = L(v) for all v in H^1_0
>>>
>>> The boundary conditions are part of the test and trial spaces
>>> (subscripts g and 0 on H^1). We could do something like
>>>
>>>   V = FunctionSpace("Lagrange", "triangle", 1) # test space
>>>   W = FunctionSpace("Lagrange", "triangle", 1) # trial space
>>>   V.restrict(g)
>>>   W.restrict(0)
>>>
>>>   a = dot(grad(v), grad(u))*dx
>>>   L = v*f*dx
>>>
>>
>> We could do that.
>>
>> Boundary conditions are usually part of the test and trial space, but
>> this
>> is just short-hand
>> notation. Either you can say
>>
>> Find u in H^1_g : a(v, u) = L(v) for all v in H^1_0
>>
>> where H^1_g are the functions in H^1 with Tu=g on \partial \Omega
>> (and similar with H^1_0)
>>
>> or you can say
>>
>> Find u in H^1 : a(v, u) = L(v) for all v in H^1 with Tu = g on \partial
>> \Omega
>> (and similar with v).
>>
>> It is just that H^1_0 is so established that we hardly think of traces.
>>
>> But I think
>>
>> T(i) * u == g
>>
>> looks good, it can also be done on the test or trial space
>
> I think you've still not answered the question about how this is used.

I'll get back to that. I have not looked at all details yet. :)

> The line above won't work alone, we'll have to do at least
>
>   bc = T(i) * u == g
>
> which looks a bit more strange than your line alone,
> and then 'bc' must be attached to an equation somehow
> if we are to pass around simple objects like we do with forms.
>
>
>> V = FunctionSpace("Lagrange", "triangle", 1)
>> T(i)* V == g
>>
>> But we can also do restrict (in both cases).
>
> I don't think I like the V.restrict(g) option.
> One reason is purely visual, it doesn't quite
> "fit" with the rest of UFL. More importantly,
> I'd like to use the same element object for
> coefficient functions and basis functions.
> Maybe we can do:
>
> V = FiniteElement("Lagrange", "triangle", 1)
> Vg = Restricted(V, g, i) # subspace of V with u=g on dS_i
> u = TrialFunction(Vg)
> f = Function(V)
>
> --
> Martin
>

I like the abstraction/name trace better than restriction, but no hard
feelings.
It could also be 'Constraints'.

Kent