← Back to team overview

ufl team mailing list archive

Re: Dirichlet boundary conditions

 

2008/6/19 Kent-Andre Mardal <kent-and@xxxxxxxxx>:
>
> tor, 19.06.2008 kl. 11.38 +0200, skrev Martin Sandve Alnæs:
>> 2008/6/19 Kent-Andre Mardal <kent-and@xxxxxxxxx>:
>> >
>> > Should we include Dirichlet conditions in UFL ?
>> >
>> > It could be done with the notion of traces:
>> >
>> > g = Function(...)
>> > u = TrialFunction(...)
>> > T = FacetTrace(...)
>>
>> From a programming point of view, this line makes no sense to me:
>>
>> > T*u = g
>>
>> What it means mathematically is clear, but this can never be valid Python.
>
> You're right. Maybe
> T*u == g.
> Is this possible in Python ? It is in C++...

The assignment operator doesn't exist in Python.

Even if it did work, say in C++ or using ==, "T*u" would a a temporary object,
and "(T*u) == g" would be a call to (T*u).operator==(g) returning another
temporary object, which would then dissapear on the next line.


>> Do you mean something like:
>>
>> a = u*v*dx + dot(u,n)*v*ds(0) + g*T(1)
>>
>> where T(i) and ds(i) would refer to the same boundary?
>>
>
> Could be but I think this is less mathematically clear
> (for one thing a would not be bilinear)
>
> c = T*u == g.
> a = u*v*dx + dot(u,n)*v*ds(0)

So you don't want the BC to be part of the form.
Where should it be used? Why should it be part of UFL
and not just a dolfin component?

If we are to include this in UFL, it should support arbitrary UFL expressions
in place of g, and we would also have to support component-wise conditions:

just_some_expression = (dot(g, n) + inner(grad(g), grad(g)))
c = T*(u[0]) == just_some_expression

This means we must generate code for it, and need to extend UFC to include it.

If we only support the basic "u = g" condition, I don't see the point
with adding it to UFL.

-- 
Martin

>> > meaning that u = g on the boundary.
>> > One could also have T(i) for the trace
>> > on subdomain i.
>> >
>> > I think it also could be put into the UFC assembly loop in a nice way,
>> >
>> > assembly(...){
>> >
>> >  ...
>> >
>> >  assembleCells(...);
>> >
>> >  assembleExteriorFacets(...);
>> >
>> >  assembleInteriorFacets(...);
>> >
>> >  enforceTraces(...);
>> >
>> > }
>> >
>> >
>> > The bad thing is that it affects both the right and left hand side so
>> > that the matrix and the right hand side need to be assembled at the same
>> > time (or one could make a very sparse matrix that resemble applying the
>> > constraints).
>> >
>> > Kent
>>
>> I don't think they'll _need to_ be assembled at the same time, this could
>> also be ignored during initial assembly and then done as a separate step.
>> In particular if it's only part of UFL and not UFC: the Assembler shouldn't
>> know about UFL at all, only UFC (which we may of course extend as well!).
>>
>> --
>> Martin
>
>


Follow ups

References