dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Nov 19, 2012 at 08:13:10AM +0000, Garth N. Wells wrote:

> Then configure the backend to support 64 bit integers.
>
> > So why do we need size_t? Shouldn't we rather use the LA int type for
> > everything that needs to be big (and dolfin::uint (typedef for
> > unsigned int as before) for all other integers?
>
> Because Mesh, etc should not depend on the backend int type.

ok. So the logic is:

- Bigger problems need bigger numbers

- This implies bigger numbers for LA backends and we can't dictate what
  they use, hence PetscInt in PETScMatrix::add

- It also implies bigger numbers for numbering of mesh entities and we
  don't want to use PETScInt for the mesh, hence size_t

?

If so, why don't we use size_t all over, except for the linear algebra
interfaces? Any performance hit will mostly be visible for large
arrays and for those we use size_t anyway so it would just mean
changing the small numbers from dolfin::uint to size_t.

> >> 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.
> >
> > Does Trilinos have a typedef for this like PETSc?
> >
>
> No. It overloads functions.

ok.

> >> > 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.
> >
> > Sure, but it's confusing with 3 index types: the LA type (now
> > dolfin::DolfinIndex), size_t and dolfin::uint).
> >
> > My suggestion would be:
> >
> > - typedef dolfin::Index (not dolfin::DolfinIndex) used for integers
> >   that need to be large
> >
> >   This can be a typedef for either PetscInt or whatever Epetra uses.
> >
>
> We shouldn't couple all of DOLFIN to the backend typedef.
>
> > - typedef dolfin::uint for unsigned int as now for all other integers
> >   that don't need to be large
> >
> > - don't use size_t
> >
>
> I think we should use std::size_t because it signals intent. It also
> maps naturally onto the STL and numpy (numpy.uintp). I would like to
> remove dolfin::uint and use 'unsigned int' when we want an 'unsigned
> int'. The integer type for backend compatibly should be localised as
> much as possible. Otherwise we will get into the situation we have
> now: a typedef for uint that cannot be changed without breakages all
> over.

I'll think more about it. I'm still not comfortable with 3 different
integer types.

--
Anders