dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Nov 15, 2012 at 09:56:45PM +0100, Martin Sandve Alnæs wrote:
>    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.

My suggestion would be to put some more advanced data structures in
UFC and use them from DOLFIN so the dependency is still DOLFIN --> UFC.

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

Yes.

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

Agree. Discussions and experimentation will be needed.

--
Anders


>    Martin
>
>    On 15 November 2012 08:54, Anders Logg <[1]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.
>
>    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
>    <[2]martinal@xxxxxxxxx> wrote:
>    > >> ---------- Videresendt melding ----------
>    > >> Fra:
>    > >> Dato: 15. nov. 2012 07:35
>    > >> Emne: Re: [Dolfin] unsigned int -> std::size_t
>    > >> Til: "Garth N. Wells" <[3]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"
>    <[4]gnw20@xxxxxxxxx> følgende:
>    > >>
>    > >> _______________________________________________
>    > >> Mailing list: [5]https://launchpad.net/~dolfin
>    > >> Post to     : [6]dolfin@xxxxxxxxxxxxxxxxxxx
>    > >> Unsubscribe : [7]https://launchpad.net/~dolfin
>    > >> More help   : [8]https://help.launchpad.net/ListHelp
>    > >>
>    > >
>    > > _______________________________________________
>    > > Mailing list: [9]https://launchpad.net/~dolfin
>    > > Post to     : [10]dolfin@xxxxxxxxxxxxxxxxxxx
>    > > Unsubscribe : [11]https://launchpad.net/~dolfin
>    > > More help   : [12]https://help.launchpad.net/ListHelp
>    > >
>    >
>    >
>    > _______________________________________________
>    > Mailing list: [13]https://launchpad.net/~dolfin
>    > Post to     : [14]dolfin@xxxxxxxxxxxxxxxxxxx
>    > Unsubscribe : [15]https://launchpad.net/~dolfin
>    > More help   : [16]https://help.launchpad.net/ListHelp
>    _______________________________________________
>    Mailing list: [17]https://launchpad.net/~dolfin
>    Post to     : [18]dolfin@xxxxxxxxxxxxxxxxxxx
>    Unsubscribe : [19]https://launchpad.net/~dolfin
>    More help   : [20]https://help.launchpad.net/ListHelp
>
> Referenser
>
>    1. mailto:logg@xxxxxxxxx
>    2. mailto:martinal@xxxxxxxxx
>    3. mailto:gnw20@xxxxxxxxx
>    4. mailto:gnw20@xxxxxxxxx
>    5. https://launchpad.net/~dolfin
>    6. mailto:dolfin@xxxxxxxxxxxxxxxxxxx
>    7. https://launchpad.net/~dolfin
>    8. https://help.launchpad.net/ListHelp
>    9. https://launchpad.net/~dolfin
>   10. mailto:dolfin@xxxxxxxxxxxxxxxxxxx
>   11. https://launchpad.net/~dolfin
>   12. https://help.launchpad.net/ListHelp
>   13. https://launchpad.net/~dolfin
>   14. mailto:dolfin@xxxxxxxxxxxxxxxxxxx
>   15. https://launchpad.net/~dolfin
>   16. https://help.launchpad.net/ListHelp
>   17. https://launchpad.net/~dolfin
>   18. mailto:dolfin@xxxxxxxxxxxxxxxxxxx
>   19. https://launchpad.net/~dolfin
>   20. https://help.launchpad.net/ListHelp