dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Apr 20, 2009 at 05:17:26PM -0400, Shawn Walker wrote:
>
>
> On Mon, 20 Apr 2009, kent-and@xxxxxxxxx wrote:
>
>>>
>>> On Mon, 20 Apr 2009, Anders Logg wrote:
>>>
>>>> On Thu, Apr 16, 2009 at 09:19:51PM -0400, Shawn Walker wrote:
>>>>>
>>>>> On Fri, 17 Apr 2009, Garth N. Wells wrote:
>>>>>
>>>>>> kent-and@xxxxxxxxx wrote:
>>>>>>> I would also like this capability! It is  something that often shows
>>>>>>> up
>>>>>>> in inverse/optimal control problems.
>>>>>>>
>>>>>>> Written in FFC/UFL your first equation reads:
>>>>>>>
>>>>>>> dot(u,v)*dx - p*div(v)*dx + lmbda*dot(v,n)*ds
>>>>>>>
>>>>>>> where u, p, lmbda are trial functions.
>>>>>>>
>>>>>>> You could form one system or create a block matrix. Anyhow
>>>>>>> the term
>>>>>>>   lmbda*dot(v,n)*ds
>>>>>>> would lead to a matrix with a very big kernel since you are not able
>>>>>>> to
>>>>>>> restrict the dofs of lmbda only to the boundary.
>>>>>>>
>>>>>>> What you can currently do is to restrict the functionspace for lmbda
>>>>>>> to
>>>>>>> all the cells
>>>>>>> associated with the boundary.
>>>>>>>
>>>>>>> Using restricted functionspaces (in a simpler fashion) can be found
>>>>>>> in
>>>>>>> demo/function/restriction.
>>>>>>>
>>>>>>> The restriction does only work on cells for now.
>>>>>>>
>>>>>>> We could discuss Uzawa and/or block matrices for this problem but I
>>>>>>> think
>>>>>>> the simplest start is to create one system to begin with.
>>>>>>>
>>>>>>> Whether it makes sense that lmbda lives on the whole cell associated
>>>>>>> with
>>>>>>> the boundary, I don't know.
>>>>>>>
>>>>>>
>>>>>> It should live only on the boundary. In practice this only becomes an
>>>>>> issue for higher-order elements with internal dofs.
>>>>>>
>>>>>> Garth
>>>>>
>>>>> Yes, I agree.
>>>>>
>>>>> So how ridiculous is it to enable FFC/DOLFIN to have finite element
>>>>> functions that are only defined on the boundary of the domain?  I'm
>>>>> guessing there would be some special DoFmappings to go from the global
>>>>> domain numbering to a boundary numbering only.  This would be really
>>>>> nice
>>>>> to have.  There are lots of cases in practice that have these kinds of
>>>>> boundary functions.
>>>>>
>>>>> - Shawn
>>>>
>>>> It's not impossible but it requires some thought. I think Garth has
>>>> asked about this for a long time as well (to have function spaces that
>>>> only live on facets). I don't really know how to best handle it.
>>>>
>>>
>>> ok.  I just implemented what I needed in MATLAB and that formulation
>>> works.  But it would certainly be great to have it in FENICS.
>>>
>>> - Shawn
>>
>> A possible way to do it with not to much work (?) in FEniCS would be to
>> to create the matrix on the space with to many degrees of freedom and
>> a large kernel. Then create a projection matrix based on the degrees
>> of freedom you want. You may then project the matrix onto the space you
>> want. This is similar to what is currently done in the function restriction
>> (allthought it is between the lines here). Both PETSc and Trilinos support
>> matrix matrix multiplication (I think).
>>
>> This is maybe not the most elegant solution, but it is not all bad.
>>
>> Kent
>
> Is it really that bad to put this directly into FENICS?  It seems that 
> all you need is a separate DoFmap for the variables that live on the 
> boundary only.  Is it not possible to setup a DoF numbering on the 
> boundary only? Maybe, in addition, have a way of mapping the DoF's on the 
> boundary to the corresponding DoF's in the global numbering?

It would not be very difficult to create a DofMap that numbers only the
dofs on the boundary but I suspect it will be difficult to handle
all the cells where there are no dofs considering one assumption that
both form compilers, UFC, and DOLFIN make is that each cell has the
same number of dofs. Maybe this is simpler since it's either zero dofs
or n dofs in a cell.

> Wasn't something like this done for the parallel stuff?  I seem to  
> remember something about having mapping between DoF's on different  
> sub-domains, but I wasn't really paying attention.
>
> If someone could summarize the difficulties here, that would be great. I 
> am not that familiar with this aspect of FENICS.

I can't really say what the problems are without trying.

-- 
Anders

Attachment: signature.asc
Description: Digital signature