← Back to team overview

ffc team mailing list archive

Re: Release plans

 

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.

Mehdi

> 
> 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?
> 
> 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.
> 
> --
> 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.
> > >>>
> > >>
> >
> >
> _______________________________________________
> Mailing list: https://launchpad.net/~ffc
> Post to     : ffc@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ffc
> More help   : https://help.launchpad.net/ListHelp




Follow ups

References