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? > 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? > 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... Johan > -- > Anders > > > On Thu, Nov 15, 2012 at 08:43:01AM +0100, Johan Hake wrote: >> 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
