Definitely a good plan. 1.1 release in december would be nice, then we can think more freely in january.
Martin On 15 November 2012 21:35, Marie E. Rognes <m...@simula.no> wrote: > > > On 15. nov. 2012, at 21:23, Anders Logg <l...@simula.no> wrote: > > > On Thu, Nov 15, 2012 at 10:22:05AM +0100, Johan Hake wrote: > >> On 11/15/2012 08:54 AM, Anders Logg wrote: > >>> It might be a good thing to move it to la but then we need a new > >>> fem/mesh independent abstraction to replace the current DofMap class. > >>> Instead of the letting a dolfin::Cell be a central concept, it can be > >>> something else corresponding to a cell, a facet, subsets or even > >>> groups of mesh entities. > >> > >> Why would this be necessary? > > > > To support more general finite element spaces and to simplify the code. > > > >>> One thing I want to do when we're anyway talking about big changes is > >>> to work out a very different design for UFC 3.0 which will get rid of > >>> all the copying between ufc::foo and dolfin::Foo classes. We tried > >>> really hard to make minimal assumptions in UFC on data structures so > >>> the code could be used from other libraries, but as far as I know all > >>> other libraries using some part of the toolchain (UFL or form > >>> compilers) generate code directly for their own backend anyway, > >>> completely bypassing UFC. It was a nice idea, but it looks like the > >>> assumption it could be reused has failed. > >> > >> Now we are talking! I guess several things could go into such a rewrite. > >> Maybe fire up a Blueprint? > > > > Yes, but I'm not sure I would be able to write it up as a > > blueprint. Some experiments will be necessary first. > > > >>> I believe we could make the DofMap class much simpler by improving > >>> the code generation to fit better to DOLFIN. > >> > >> That part might be simpler but with huge cost in refactoring existing > >> code... > > > > Yes, it will cost. But it's 5 years since we designed UFC and the > > add-ons on top of it (the DofMap, DofMapBuilder, SparsityPattern, > > SparsityPatternBuilder, AssemblerBase classes) are growing more and > > more complex and making it hard to maintain and add new > > features. Since UFC 1.0, we have also gone parallel so we (mostly > > Garth) have quite a bit of experience we didn't have back then. > > > > I discussed this with Garth and the suggestion is we make the buildbot > > happy, fix bugs, get the size_t stuff in place and release 1.1.0. Then > > we can take larger steps towards a new design for 2.0. > > > > > Sounds like a good plan! > > -- > Marie > > > -- > > Anders > > > > > >>>> Would it be possible to move DofMaps to dolfin/la and make them > backend > >>>> specific? > >>>> > >>>> Johan > >>>> > >>>> On 11/15/2012 08:16 AM, Garth N. Wells wrote: > >>>>> On Thu, Nov 15, 2012 at 6:37 AM, Martin Sandve Alnæs < > marti...@simula.no> wrote: > >>>>>> ---------- Videresendt melding ---------- > >>>>>> Fra: > >>>>>> Dato: 15. nov. 2012 07:35 > >>>>>> Emne: Re: [Dolfin] unsigned int -> std::size_t > >>>>>> Til: "Garth N. Wells" <gn...@cam.ac.uk> > >>>>>> > >>>>>> > >>>>>> A typedef for the chosen linear algebra backend? How is that > possible with > >>>>>> dynamic choice of backend? > >>>>> > >>>>> A 'primary' backend will need to be decided at configure time, and > the > >>>>> index type will match the index type of the primary backend. I don't > >>>>> see any way to get around this. Templating some functions will not > >>>>> help because the dof map needs to use a compatible index type, and > >>>>> this would tie a dof map to a backend (and templates will make the > >>>>> code more complicated). > >>>>> > >>>>> At present we just assume that all backends use an index type that is > >>>>> compatible with unsigned int, but we can't justify this assumption. > >>>>> Flaws in DOLFIN la handling have shown up with the release of > Trilinos > >>>>> 11, which introduces 64-bit ints to its interface. PETSc uses > >>>>> PetscInt, and we have just assumed that it's compatible with unsigned > >>>>> int. > >>>>> > >>>>> Garth > >>>>> > >>>>> > >>>>>> Martin > >>>>>> > >>>>>> Den 14. nov. 2012 18:06 skrev "Garth N. Wells" <gn...@cam.ac.uk> > følgende: > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Mailing list: https://launchpad.net/~dolfin > >>>>>> Post to : dolfin@lists.launchpad.net > >>>>>> Unsubscribe : https://launchpad.net/~dolfin > >>>>>> More help : https://help.launchpad.net/ListHelp > >>>>> > >>>>> _______________________________________________ > >>>>> Mailing list: https://launchpad.net/~dolfin > >>>>> Post to : dolfin@lists.launchpad.net > >>>>> Unsubscribe : https://launchpad.net/~dolfin > >>>>> More help : https://help.launchpad.net/ListHelp > >>>> > >>>> > >>>> _______________________________________________ > >>>> Mailing list: https://launchpad.net/~dolfin > >>>> Post to : dolfin@lists.launchpad.net > >>>> Unsubscribe : https://launchpad.net/~dolfin > >>>> More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~dolfin > > Post to : dolfin@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~dolfin > > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~dolfin > Post to : dolfin@lists.launchpad.net > Unsubscribe : https://launchpad.net/~dolfin > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
