dolfin team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

Just throwing in a couple of sidecomments here about the UFC 3.0 talk:

1) Fixating the UFC interface was not done only to make it reusable from
both sides, but to avoid unnecessary work on form compilers whenever
something changes in dolfin. If UFC 3.0 gains dependencies on some
rudamentary dolfin classes (like dolfin::Cell), those should be small and
few and with a stable interface. Small and few so we can copy them or mock
them to write fast unit tests of generated code without linking with
dolfin. Stable interface such that form compiler updates stay rare.

2) Design points for UFC 3.0 should be considered in concert with or after
the upcoming multidomain discussions.

3) More direct dependencies on dolfin interfaces in generated code would
allow us to move some code out of the generated part and into library code,
such as the geometry computation snippets.

But lets not rush this, it's a big change.

Martin


On 15 November 2012 08:54, Anders Logg <logg@xxxxxxxxx> 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.
>
> 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.
>
> I believe we could make the DofMap class much simpler by improving
> the code generation to fit better to DOLFIN.
>
> --
> 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 <
> 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
>