← Back to team overview

dolfin team mailing list archive

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

 

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.

--
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
>


Follow ups

References