← Back to team overview

dolfin team mailing list archive

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

 


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


Follow ups

References