← Back to team overview

dolfin team mailing list archive

Re: Integer type transition

 

On Sat, Nov 17, 2012 at 2:47 AM, Anders Logg <logg@xxxxxxxxx> wrote:
> On Thu, Nov 15, 2012 at 09:09:52PM +0000, Garth N. Wells wrote:
>> The first stage of the transition to a new integer type is complete.
>
> Great!
>
>> Most of DOLFIN now uses std::size_t, and a new typedef 'DolfinIndex'
>> has been introduced for compatibility with linear algebra backends.
>> Please feel free to suggest a better name for this typedef. Presently,
>> DolfinIndex is just a typedef for int. This typedef should rarely be
>> visible to a user, and it should have a name that discourages its
>> unnecessary use.
>
> I'm a bit confused. We now have
>
> PETScMatrix::add(const double* block, std::size_t m, const DolfinIndex* rows,
>                                       std::size_t n, const DolfinIndex* cols);
>
> Here, the only thing being size_t is the dimension of the local
> stiffness matrix, which is never big (so the 4 bytes of uint should
> be sufficient).

We could use unsigned int or DolfinIndex for the block size. It
doesn't really make any difference. I would like to change these
interfaces anyway and use std::vector<DolfinIndex> and/or
boost::multi_array.

> On the other hand the rows and cols pointers contain
> global indices and they now use int which have an even smaller range
> than uint. I would expect to have
>
> PETScMatrix::add(const double* block, uint m, size_t* rows,
>                                       uint n, size_t* cols);
>
> or size_t all over.
>

That doesn't work. The point of DolfinIndex is that it must *match*
the index type of the linear algebra backend, e.g. it can be a typedef
for PetscInt.

With the change I just pushed, if you make DolfinIndex a typedef for
'long long int', Trilinos works with 64 bit integers. I did some basic
testing and it worked fine (with Krylov solvers). You need Trilinos 11
for this.

> And if we want to use PETSc for large index ranges, then we need to
> use PETScInt which may or may not be compatible with size_t.
>

Which a typedef can handle. Block sizes are passed by value, which
takes care of any casting.

Garth

> --
> Anders
>
>
>> There are some small changes on the Python size, most notably the need
>> to use "sizet" in place of "uint" for MeshFunctions. One can create
>> both uint (unsigned int)  and sizet (std::size_t) MeshFunctions, but
>> most interfaces expect sizet. We could eliminate the "uint" versions
>> and map "uint" to the sizet case. Opinions?
>>
>> Some thought is required to figure out the mapping to numpy integer
>> types. std::size_t is easy because numpy has a type 'uintp' which is
>> the same as std::size_t. Dealing with DolfinIndex is harder because
>> figuring out its type from the SWIG side doesn't seem easy. One
>> solution is to use more data copying for in typemaps.
>>
>> Garth
>>
>> _______________________________________________
>> 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