← Back to team overview

dolfin team mailing list archive

Re: Fwd: Re: unsigned int -> std::size_t

 

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 <meg@xxxxxxxxx> wrote:

>
>
> On 15. nov. 2012, at 21:23, Anders Logg <logg@xxxxxxxxx> 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 <
> martinal@xxxxxxxxx> wrote:
> >>>>>> ---------- Videresendt melding ----------
> >>>>>> Fra:
> >>>>>> Dato: 15. nov. 2012 07:35
> >>>>>> Emne: Re: [Dolfin] unsigned int -> std::size_t
> >>>>>> Til: "Garth N. Wells" <gnw20@xxxxxxxxx>
> >>>>>>
> >>>>>>
> >>>>>> 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" <gnw20@xxxxxxxxx>
> følgende:
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Mailing list: https://launchpad.net/~dolfin
> >>>>>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> >>>>>> Unsubscribe : https://launchpad.net/~dolfin
> >>>>>> More help   : https://help.launchpad.net/ListHelp
> >>>>>
> >>>>> _______________________________________________
> >>>>> Mailing list: https://launchpad.net/~dolfin
> >>>>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> >>>>> Unsubscribe : https://launchpad.net/~dolfin
> >>>>> More help   : https://help.launchpad.net/ListHelp
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Mailing list: https://launchpad.net/~dolfin
> >>>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> >>>> Unsubscribe : https://launchpad.net/~dolfin
> >>>> More help   : https://help.launchpad.net/ListHelp
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~dolfin
> > Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~dolfin
> > More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp
>

Follow ups

References