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 _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
