ffc team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

Anders Logg wrote:
> On Fri, Jan 29, 2010 at 09:31:54AM +0000, Garth N. Wells wrote:
>>
>> Anders Logg wrote:
>>> On Fri, Jan 29, 2010 at 08:35:23AM +0000, Garth N. Wells wrote:
>>>> Anders Logg wrote:
>>>>> On Fri, Jan 29, 2010 at 12:26:32AM +0000, Garth N. Wells wrote:
>>>>>> Anders Logg wrote:
>>>>>>> There seem to be just a couple of issues remaining in order of importance:
>>>>>>>
>>>>>>> 1. QuadratureElement
>>>>>>>
>>>>>>> 2. DOLFIN fem unit test
>>>>>>>
>>>>>>> 3. evaluate_basis_derivatives
>>>>>>>
>>>>>>> 4. RestrictedElement
>>>>>>>
>>>>>>> Among these, I would say 1-2 are crucial to fix before 0.9.0,
>>>>>>> but 3-4 are less crucial.
>>>>>>>
>>>>>> Both 3 and 4 are crucial for me..
>>>>> I know, but I expect you are part of category (i) below, a limited
>>>>> number of users who are running bzr tip anyway. :-)
>>>>>
>>>> Not exactly, because I share some solvers which require this
>>>> functionality with less adventurous collaborators who do use the packages.
>>> If it's very important to you, could you help out with the design and
>>> implementation of RestrictedElement.
>> I'd like to, but I won't be able to look at the code until next week.
> 
> ok. Could Kristian comment on the possibility of finishing things up
> today (without breaking yourself)? If it's not possible, it's not
> possible and we should wait with the release 2-3 weeks so we have time
> to test properly and fix a few more bugs. But perhaps it's possible to
> fix almost everything, release 0.9.0 now and then 0.9.1 as a bug fix
> release in a few weeks.
> 
> I think it's possible to ask Ubuntu to pull 0.9.1 as a bug fix for
> 0.9.0 in a few weeks, but it's likely they will not want to pull 0.9.0
> as a major upgrade of 0.7.1.
> 
>>> There seems to be some confusion
>>> about what it should actually do. I still don't understand it.
>>>
>> Here's an example of its use:
>>
>>   http://www.dspace.cam.ac.uk/bitstream/1810/221687/1/solver.py
> 
> Looks good.
> 
>> In the simplest case, it is just a restriction to cell facets. Kristian
>> would like to approach it more generally with restriction to cells,
>> measures an subdomains, but I think that there is a difference. What
>> RestrictedElement did is define functions that live only on the facets
>> of a cell (i.e. no internal dofs associated with basis functions that
>> are zero on facets. Restriction to measures are different, since the
>> function still lives on the entire cell, but happens to be evaluated on
>> a lower-dimensional entity, e.g. a surface passing through a cell.
>> Subdomains are different again and are just defining a subdomain on
>> which function is defined (a subset of cells).
> 
> Sub domains seem to be very different, but the other two cases just
> seem to be a matter of some dofs being "active" and the other zeroed
> out. This is what Marie suggested yesterday, that a restricted element
> only considers a subset of the dofs of some given element.
> 

Sounds good.

> The thing I don't understand yet is the selection of which dofs should
> be active. If we think of the case with restriction to facets, then
> the element needs to be restricted to different facets depending on
> which facet we are integrating over, or are we always mapping one
> specific facet of the reference cell to the current facet?
> 
It works the same way as the DG elements, just the internal dofs are
thrown away, which is the latter if the above, right?

> Say we have P1 elements in 2D which have 3 dofs. Then we could
> restrict that element to the dofs on the first facet (facet 0). These
> dofs are then labeled 1 and 2. But sometimes a facet in the mesh will
> correspond to the edge between 0 and 1 or 0 and 2.
> 

We don't restrict to individual facets, but to all facts of a cell.

Garth

> --
> Anders
> 
> 
> 
>> Garth
>>
>>
>>
>>
>>>> Garth
>>>>
>>>>>> I think that it's all being rushed. With the major re-write of FFC it
>>>>>> should be given some time for user testing. I would be amazed if my
>>>>>> various solvers do not show up bugs.
>>>>> Yes, it's being rushed, but there is time to release bug fixes.
>>>>>
>>>>> To me, the minimum requirement is that we pass the regression tests in
>>>>> FFC (perhaps except for evaluate_basis_derivatives and
>>>>> ElementRestriction) and that we can compile and run all the DOLFIN
>>>>> demos without problems. That should be enough for 0.9.0.
>>>>>
>>>>> Even so, I'm not sure we will be able to manage to do that in time.
>>>>> We should settle on something before lunch today. If we decide not to
>>>>> press on with the release, we should take a good look at which
>>>>> versions are currently packaged and see if those packages are in good
>>>>> shape since those will go into the next Ubuntu LTS.
>>>>>
>>