dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Nov 19, 2012 at 09:15:07AM +0000, Garth N. Wells wrote:
> On Mon, Nov 19, 2012 at 9:08 AM, Anders Logg <logg@xxxxxxxxx> wrote:
> > On Mon, Nov 19, 2012 at 09:04:29AM +0000, Garth N. Wells wrote:
> >> On Mon, Nov 19, 2012 at 8:41 AM, Anders Logg <logg@xxxxxxxxx> wrote:
> >> > 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
> >> >
> >>
> >> Yes, although for our own backends we can dictate the type (e.g.
> >> STLMatrix, which use std::size_t for data storage).
> >
> > Is that relevant for big problems?
> >
>
> Could be. I use STLMatrix to interface to 3rd party solver than cannot
> be used via PETSc, or for which the PETSc interface is too old or too
> limited.

ok.

> For consistency with the GenericMatrux interface, STLMatrix has to use
> DolfinIndex for the add/set functions.

What are the implications for the Trilinos backend with that typedef?

> > If so, would an option be to always assemble into our own matrix, then
> > copy to whatever backend and isolate the special indexing that way?
> >
> >> > - It also implies bigger numbers for numbering of mesh entities and we
> >> >   don't want to use PETScInt for the mesh, hence size_t
> >> >
> >>
> >> Yes.
> >>
> >> Here's a currect example: I would like to test for some very large
> >> meshes (including for parallel mesh refinement), but I can't get PETSc
> >> to build with 64 bit integers. I don't want a PETSc build problem to
> >> mean that I can't move on with testing a big mesh.
> >>
> >> > ?
> >> >
> >> > 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.
> >>
> >> Yes, I think that std::size_t should be the default integer type.
> >
> > ok, good. The more standard types we can use, the better.
> >
> >> This however does not preclude using 'unsigned int' if there is a
> >> compelling reason, just as there may be cases where 'unsigned short
> >> int; might be appropriate (in both cases likely due to memory
> >> issues).
> >
> > Sure.
> >
> >> >> 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.
> >> >
> >>
> >> C++ provides more than three integer types.
> >>
> >> We should get rid dolfin::uint and default to std::size_t. That gives
> >> one integer type in over 95% of the interface.
> >
> > Sounds good then.
> >
>
> OK. Let's rid of dolfin::uint usage from within DOLFIN, but keep it as
> a typedef for the next release.

ok. Sounds good.

What about the name? DolfinIndex does not seem appropriate if we don't
use it to index meshes. How about dolfin::la_int?

--
Anders