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