dolfin team mailing list archive

[Johan Hake <hake.dev@xxxxxxxxx>]

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