ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, Jan 29, 2010 at 11:38:38AM +0100, Mehdi Nikbakht wrote:
> On Fri, 2010-01-29 at 10:57 +0100, 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.
>
> For the restriction with Measure(i.e. dc), it is not exactly the case.
> The corresponding shape functions for thier dofs are defined in part of
> cell and the rest are zeroed. We don't throw away any dofs in
> compilation stage.
> Note that they might be inactive which will be determined in the solver.
>
> For my case, I am using the restriction just as a marker to determine
> discontinuous space.

Is that part currently broken and what needs to be added to make it
work?

--
Anders

Attachment: signature.asc
Description: Digital signature