Problems with 64-bit PETSc

[Jason Bacon]

Have you guys tested with a 64-bit PETSc yet? ( PETSc built with --with-64-bit-indices and/or --with-64-bit-pointers).

The Dolfin code interfacing with PETSc uses int in a lot of places where it should use PetscInt. I can send a minimal set of patches required to make it compile, but there are still runtime problems, so the code is going to need more thorough examination and testing.

Cheers,

   Jason

[Anders Logg (logg)]

On Wed, May 23, 2012 at 02:02:57PM -0000, Jason Bacon wrote:
> Public bug reported:
>
>
> Have you guys tested with a 64-bit PETSc yet? ( PETSc built with --with-64-bit-indices and/or --with-64-bit-pointers).
>
> The Dolfin code interfacing with PETSc uses int in a lot of places where
> it should use PetscInt. I can send a minimal set of patches required to
> make it compile, but there are still runtime problems, so the code is
> going to need more thorough examination and testing.

We also use a lot of reinterpret_cast<> from 'unsigned int'. How will
that work with 64 bit PETSc?

--
Anders

[Jason Bacon (jwbacon)]

Well, I think the code will have to be carefully examined and altered to
avoid truncation errors when mixing PetscInt and smaller types. I
attached the patches necessary to make it compile, but there may still
be truncation issues where int arithmetic is used on subscripts elsewhere.

I think this is an important issue, given that "int" subscripts limit
arrays to 2^31 elements, and Dolfin will be used on many systems with
far more address space than that.

I personally make a point of using size_t for all array subscripts.
It's standard, unsigned, and matches the address size on the underlying
architecture. That would eliminate the issue on 64-bit systems, which
is the only place it will matter anyway.

Cheers,

     -J

On 05/24/12 11:53, Anders Logg wrote:
> On Wed, May 23, 2012 at 02:02:57PM -0000, Jason Bacon wrote:
>> Public bug reported:
>>
>>
>> Have you guys tested with a 64-bit PETSc yet? ( PETSc built with --with-64-bit-indices and/or --with-64-bit-pointers).
>>
>> The Dolfin code interfacing with PETSc uses int in a lot of places where
>> it should use PetscInt. I can send a minimal set of patches required to
>> make it compile, but there are still runtime problems, so the code is
>> going to need more thorough examination and testing.
> We also use a lot of reinterpret_cast<> from 'unsigned int'. How will
> that work with 64 bit PETSc?
>
> --
> Anders
>

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jason W. Bacon
<email address hidden>
http://personalpages.tds.net/~jwbacon
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Johan Hake (johan-hake)]

On 05/24/2012 07:28 PM, Jason Bacon wrote:
> Well, I think the code will have to be carefully examined and altered to
> avoid truncation errors when mixing PetscInt and smaller types. I
> attached the patches necessary to make it compile, but there may still
> be truncation issues where int arithmetic is used on subscripts elsewhere.
>
> I think this is an important issue, given that "int" subscripts limit
> arrays to 2^31 elements, and Dolfin will be used on many systems with
> far more address space than that.
>
> I personally make a point of using size_t for all array subscripts.
> It's standard, unsigned, and matches the address size on the underlying
> architecture. That would eliminate the issue on 64-bit systems, which
> is the only place it will matter anyway.

Sounds like a good solution, but it will take some thorough search and
replace...

Johan

> Cheers,
>
> -J
>
> On 05/24/12 11:53, Anders Logg wrote:
>> On Wed, May 23, 2012 at 02:02:57PM -0000, Jason Bacon wrote:
>>> Public bug reported:
>>>
>>>
>>> Have you guys tested with a 64-bit PETSc yet? ( PETSc built with --with-64-bit-indices and/or --with-64-bit-pointers).
>>>
>>> The Dolfin code interfacing with PETSc uses int in a lot of places where
>>> it should use PetscInt. I can send a minimal set of patches required to
>>> make it compile, but there are still runtime problems, so the code is
>>> going to need more thorough examination and testing.
>> We also use a lot of reinterpret_cast<> from 'unsigned int'. How will
>> that work with 64 bit PETSc?
>>
>> --
>> Anders
>>
>
>

[Anders Logg (logg)]

On Thu, May 24, 2012 at 06:02:58PM -0000, Johan Hake wrote:
> On 05/24/2012 07:28 PM, Jason Bacon wrote:
> > Well, I think the code will have to be carefully examined and altered to
> > avoid truncation errors when mixing PetscInt and smaller types. I
> > attached the patches necessary to make it compile, but there may still
> > be truncation issues where int arithmetic is used on subscripts elsewhere.
> >
> > I think this is an important issue, given that "int" subscripts limit
> > arrays to 2^31 elements, and Dolfin will be used on many systems with
> > far more address space than that.
> >
> > I personally make a point of using size_t for all array subscripts.
> > It's standard, unsigned, and matches the address size on the underlying
> > architecture. That would eliminate the issue on 64-bit systems, which
> > is the only place it will matter anyway.
>
> Sounds like a good solution, but it will take some thorough search and
> replace...

We can make dolfin::uint a typedef for size_t.

And I expect some SWIG fixes will be necessary...

--
Anders

> Johan
>
> > Cheers,
> >
> > -J
> >
> > On 05/24/12 11:53, Anders Logg wrote:
> >> On Wed, May 23, 2012 at 02:02:57PM -0000, Jason Bacon wrote:
> >>> Public bug reported:
> >>>
> >>>
> >>> Have you guys tested with a 64-bit PETSc yet? ( PETSc built with --with-64-bit-indices and/or --with-64-bit-pointers).
> >>>
> >>> The Dolfin code interfacing with PETSc uses int in a lot of places where
> >>> it should use PetscInt. I can send a minimal set of patches required to
> >>> make it compile, but there are still runtime problems, so the code is
> >>> going to need more thorough examination and testing.
> >> We also use a lot of reinterpret_cast<> from 'unsigned int'. How will
> >> that work with 64 bit PETSc?
> >>
> >>
> >
> >
>

[Jason Bacon (jwbacon)]

Any reason not to call it dolfin::size_t? The name size_t is meant to
indicate the size of a pointer, which is not the same size as a standard
uint on 64-bit systems.

Cheers,

     -J

On 05/24/12 13:12, Anders Logg wrote:
> On Thu, May 24, 2012 at 06:02:58PM -0000, Johan Hake wrote:
>> On 05/24/2012 07:28 PM, Jason Bacon wrote:
>>> Well, I think the code will have to be carefully examined and altered to
>>> avoid truncation errors when mixing PetscInt and smaller types. I
>>> attached the patches necessary to make it compile, but there may still
>>> be truncation issues where int arithmetic is used on subscripts elsewhere.
>>>
>>> I think this is an important issue, given that "int" subscripts limit
>>> arrays to 2^31 elements, and Dolfin will be used on many systems with
>>> far more address space than that.
>>>
>>> I personally make a point of using size_t for all array subscripts.
>>> It's standard, unsigned, and matches the address size on the underlying
>>> architecture. That would eliminate the issue on 64-bit systems, which
>>> is the only place it will matter anyway.
>> Sounds like a good solution, but it will take some thorough search and
>> replace...
> We can make dolfin::uint a typedef for size_t.
>
> And I expect some SWIG fixes will be necessary...
>
> --
> Anders
>
>
>> Johan
>>
>>> Cheers,
>>>
>>> -J
>>>
>>> On 05/24/12 11:53, Anders Logg wrote:
>>>> On Wed, May 23, 2012 at 02:02:57PM -0000, Jason Bacon wrote:
>>>>> Public bug reported:
>>>>>
>>>>>
>>>>> Have you guys tested with a 64-bit PETSc yet? ( PETSc built with --with-64-bit-indices and/or --with-64-bit-pointers).
>>>>>
>>>>> The Dolfin code interfacing with PETSc uses int in a lot of places where
>>>>> it should use PetscInt. I can send a minimal set of patches required to
>>>>> make it compile, but there are still runtime problems, so the code is
>>>>> going to need more thorough examination and testing.
>>>> We also use a lot of reinterpret_cast<> from 'unsigned int'. How will
>>>> that work with 64 bit PETSc?
>>>>
>>>>
>>>

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jason W. Bacon
<email address hidden>
http://personalpages.tds.net/~jwbacon
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Jason Bacon (jwbacon)]

BTW, I had meant to send my compliments on the overall project
organization and code portability. I think it was wise to distribute it
as separate modules (ffc, fiat, ..., dolfin), and there were very few
patches necessary for each of them to run on FreeBSD.

Regards,

     -J

On 05/24/12 13:12, Anders Logg wrote:
> On Thu, May 24, 2012 at 06:02:58PM -0000, Johan Hake wrote:
>> On 05/24/2012 07:28 PM, Jason Bacon wrote:
>>> Well, I think the code will have to be carefully examined and altered to
>>> avoid truncation errors when mixing PetscInt and smaller types. I
>>> attached the patches necessary to make it compile, but there may still
>>> be truncation issues where int arithmetic is used on subscripts elsewhere.
>>>
>>> I think this is an important issue, given that "int" subscripts limit
>>> arrays to 2^31 elements, and Dolfin will be used on many systems with
>>> far more address space than that.
>>>
>>> I personally make a point of using size_t for all array subscripts.
>>> It's standard, unsigned, and matches the address size on the underlying
>>> architecture. That would eliminate the issue on 64-bit systems, which
>>> is the only place it will matter anyway.
>> Sounds like a good solution, but it will take some thorough search and
>> replace...
> We can make dolfin::uint a typedef for size_t.
>
> And I expect some SWIG fixes will be necessary...
>
> --
> Anders
>
>
>> Johan
>>
>>> Cheers,
>>>
>>> -J
>>>
>>> On 05/24/12 11:53, Anders Logg wrote:
>>>> On Wed, May 23, 2012 at 02:02:57PM -0000, Jason Bacon wrote:
>>>>> Public bug reported:
>>>>>
>>>>>
>>>>> Have you guys tested with a 64-bit PETSc yet? ( PETSc built with --with-64-bit-indices and/or --with-64-bit-pointers).
>>>>>
>>>>> The Dolfin code interfacing with PETSc uses int in a lot of places where
>>>>> it should use PetscInt. I can send a minimal set of patches required to
>>>>> make it compile, but there are still runtime problems, so the code is
>>>>> going to need more thorough examination and testing.
>>>> We also use a lot of reinterpret_cast<> from 'unsigned int'. How will
>>>> that work with 64 bit PETSc?
>>>>
>>>>
>>>

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jason W. Bacon
<email address hidden>
http://personalpages.tds.net/~jwbacon
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Anders Logg (logg)]

Then we might as well use size_t. :-)

If I remember correctly, we discussed at some point (5 years back or
so) whether to use size_t or dolfin:uint = unsigned int. A related
discussion was which type to use for UFC. We landed on unsigned
int. So a change will be needed also in UFC.

Is PetscInt = size_t?

PS: I'm Cc:ing the list for further discussion. Quite a lot of traffic
has moved off the list to questions/bug reports which means it will
not be visible to everyone.

--
Anders

On Thu, May 24, 2012 at 06:37:25PM -0000, Jason Bacon wrote:
> Any reason not to call it dolfin::size_t? The name size_t is meant to
> indicate the size of a pointer, which is not the same size as a standard
> uint on 64-bit systems.
>
> Cheers,
>
> -J
>
> On 05/24/12 13:12, Anders Logg wrote:
> > On Thu, May 24, 2012 at 06:02:58PM -0000, Johan Hake wrote:
> >> On 05/24/2012 07:28 PM, Jason Bacon wrote:
> >>> Well, I think the code will have to be carefully examined and altered to
> >>> avoid truncation errors when mixing PetscInt and smaller types. I
> >>> attached the patches necessary to make it compile, but there may still
> >>> be truncation issues where int arithmetic is used on subscripts elsewhere.
> >>>
> >>> I think this is an important issue, given that "int" subscripts limit
> >>> arrays to 2^31 elements, and Dolfin will be used on many systems with
> >>> far more address space than that.
> >>>
> >>> I personally make a point of using size_t for all array subscripts.
> >>> It's standard, unsigned, and matches the address size on the underlying
> >>> architecture. That would eliminate the issue on 64-bit systems, which
> >>> is the only place it will matter anyway.
> >> Sounds like a good solution, but it will take some thorough search and
> >> replace...
> > We can make dolfin::uint a typedef for size_t.
> >
> > And I expect some SWIG fixes will be necessary...
> >
> >
> >
> >> Johan
> >>
> >>> Cheers,
> >>>
> >>> -J
> >>>
> >>> On 05/24/12 11:53, Anders Logg wrote:
> >>>> On Wed, May 23, 2012 at 02:02:57PM -0000, Jason Bacon wrote:
> >>>>> Public bug reported:
> >>>>>
> >>>>>
> >>>>> Have you guys tested with a 64-bit PETSc yet? ( PETSc built with --with-64-bit-indices and/or --with-64-bit-pointers).
> >>>>>
> >>>>> The Dolfin code interfacing with PETSc uses int in a lot of places where
> >>>>> it should use PetscInt. I can send a minimal set of patches required to
> >>>>> make it compile, but there are still runtime problems, so the code is
> >>>>> going to need more thorough examination and testing.
> >>>> We also use a lot of reinterpret_cast<> from 'unsigned int'. How will
> >>>> that work with 64 bit PETSc?
> >>>>
> >>>>
> >>>
>
>

[Anders Logg (logg)]

We currently don't test on FreeBSD but if there is demand for it, we
might consider adding a FreeBSD buildbot.

Our ambition is to be as cross-platform/standard as possible so if
you have any patches that improve portability, please post them.

--
Anders

On Thu, May 24, 2012 at 07:58:43PM -0000, Jason Bacon wrote:
> BTW, I had meant to send my compliments on the overall project
> organization and code portability. I think it was wise to distribute it
> as separate modules (ffc, fiat, ..., dolfin), and there were very few
> patches necessary for each of them to run on FreeBSD.
>
> Regards,
>
> -J
>
> On 05/24/12 13:12, Anders Logg wrote:
> > On Thu, May 24, 2012 at 06:02:58PM -0000, Johan Hake wrote:
> >> On 05/24/2012 07:28 PM, Jason Bacon wrote:
> >>> Well, I think the code will have to be carefully examined and altered to
> >>> avoid truncation errors when mixing PetscInt and smaller types. I
> >>> attached the patches necessary to make it compile, but there may still
> >>> be truncation issues where int arithmetic is used on subscripts elsewhere.
> >>>
> >>> I think this is an important issue, given that "int" subscripts limit
> >>> arrays to 2^31 elements, and Dolfin will be used on many systems with
> >>> far more address space than that.
> >>>
> >>> I personally make a point of using size_t for all array subscripts.
> >>> It's standard, unsigned, and matches the address size on the underlying
> >>> architecture. That would eliminate the issue on 64-bit systems, which
> >>> is the only place it will matter anyway.
> >> Sounds like a good solution, but it will take some thorough search and
> >> replace...
> > We can make dolfin::uint a typedef for size_t.
> >
> > And I expect some SWIG fixes will be necessary...
> >
> >
> >
> >> Johan
> >>
> >>> Cheers,
> >>>
> >>> -J
> >>>
> >>> On 05/24/12 11:53, Anders Logg wrote:
> >>>> On Wed, May 23, 2012 at 02:02:57PM -0000, Jason Bacon wrote:
> >>>>> Public bug reported:
> >>>>>
> >>>>>
> >>>>> Have you guys tested with a 64-bit PETSc yet? ( PETSc built with --with-64-bit-indices and/or --with-64-bit-pointers).
> >>>>>
> >>>>> The Dolfin code interfacing with PETSc uses int in a lot of places where
> >>>>> it should use PetscInt. I can send a minimal set of patches required to
> >>>>> make it compile, but there are still runtime problems, so the code is
> >>>>> going to need more thorough examination and testing.
> >>>> We also use a lot of reinterpret_cast<> from 'unsigned int'. How will
> >>>> that work with 64 bit PETSc?
> >>>>
> >>>>
> >>>
>
>

[Jason Bacon (jwbacon)]

No, PetscInt is manually controlled by the configure flag
--use-64-bit-indices, regardless of the underlying architecture. It
defaults to "int" on all platforms.

I inquired about this, and they have reasons for doing it this way. The
sparse matrix data structure embeds indices for every column, so using
smaller indices saves memory and improves performance even on 64-bit
processors.

I'm not sure if dolfin has any such memory concerns. What I came across
in patching the dolfin code was a mainly scalar int variables being
passed to PetscInt arguments of PETSc functions.

One of the PETSc developers also brought up the possibility of large
distributed matrices requiring 64-bit indices on systems with 32-bit
processors (Blue Gene). So it would seem that the standard size_t might
not be big enough in certain circumstances.

I still like the idea of using the size_t name and having it default to
the standard size_t, but maybe there could be an option to force
dolfin::size_t to 64-bits for Blue Gene users?

Regards,

     -J

On 05/24/12 15:00, Anders Logg wrote:
> Then we might as well use size_t. :-)
>
> If I remember correctly, we discussed at some point (5 years back or
> so) whether to use size_t or dolfin:uint = unsigned int. A related
> discussion was which type to use for UFC. We landed on unsigned
> int. So a change will be needed also in UFC.
>
> Is PetscInt = size_t?
>
> PS: I'm Cc:ing the list for further discussion. Quite a lot of traffic
> has moved off the list to questions/bug reports which means it will
> not be visible to everyone.
>
> --
> Anders
>
>
> On Thu, May 24, 2012 at 06:37:25PM -0000, Jason Bacon wrote:
>> Any reason not to call it dolfin::size_t? The name size_t is meant to
>> indicate the size of a pointer, which is not the same size as a standard
>> uint on 64-bit systems.
>>
>> Cheers,
>>
>> -J
>>
>> On 05/24/12 13:12, Anders Logg wrote:
>>> On Thu, May 24, 2012 at 06:02:58PM -0000, Johan Hake wrote:
>>>> On 05/24/2012 07:28 PM, Jason Bacon wrote:
>>>>> Well, I think the code will have to be carefully examined and altered to
>>>>> avoid truncation errors when mixing PetscInt and smaller types. I
>>>>> attached the patches necessary to make it compile, but there may still
>>>>> be truncation issues where int arithmetic is used on subscripts elsewhere.
>>>>>
>>>>> I think this is an important issue, given that "int" subscripts limit
>>>>> arrays to 2^31 elements, and Dolfin will be used on many systems with
>>>>> far more address space than that.
>>>>>
>>>>> I personally make a point of using size_t for all array subscripts.
>>>>> It's standard, unsigned, and matches the address size on the underlying
>>>>> architecture. That would eliminate the issue on 64-bit systems, which
>>>>> is the only place it will matter anyway.
>>>> Sounds like a good solution, but it will take some thorough search and
>>>> replace...
>>> We can make dolfin::uint a typedef for size_t.
>>>
>>> And I expect some SWIG fixes will be necessary...
>>>
>>>
>>>
>>>> Johan
>>>>
>>>>> Cheers,
>>>>>
>>>>> -J
>>>>>
>>>>> On 05/24/12 11:53, Anders Logg wrote:
>>>>>> On Wed, May 23, 2012 at 02:02:57PM -0000, Jason Bacon ...

[Garth Wells (garth-wells)]

On 24 May 2012 21:00, Anders Logg <email address hidden> wrote:
> Then we might as well use size_t. :-)
>
> If I remember correctly, we discussed at some point (5 years back or
> so) whether to use size_t or dolfin:uint = unsigned int.

Yes, we did discuss it and we should use size_t. It also works better with STL.

Garth

> A related
> discussion was which type to use for UFC. We landed on unsigned
> int. So a change will be needed also in UFC.
>
> Is PetscInt = size_t?
>
> PS: I'm Cc:ing the list for further discussion. Quite a lot of traffic
> has moved off the list to questions/bug reports which means it will
> not be visible to everyone.
>
> --
> Anders
>
>
> On Thu, May 24, 2012 at 06:37:25PM -0000, Jason Bacon wrote:
>> Any reason not to call it dolfin::size_t?  The name size_t is meant to
>> indicate the size of a pointer, which is not the same size as a standard
>> uint on 64-bit systems.
>>
>> Cheers,
>>
>>      -J
>>
>> On 05/24/12 13:12, Anders Logg wrote:
>> > On Thu, May 24, 2012 at 06:02:58PM -0000, Johan Hake wrote:
>> >> On 05/24/2012 07:28 PM, Jason Bacon wrote:
>> >>> Well, I think the code will have to be carefully examined and altered to
>> >>> avoid truncation errors when mixing PetscInt and smaller types.  I
>> >>> attached the patches necessary to make it compile, but there may still
>> >>> be truncation issues where int arithmetic is used on subscripts elsewhere.
>> >>>
>> >>> I think this is an important issue, given that "int" subscripts limit
>> >>> arrays to 2^31 elements, and Dolfin will be used on many systems with
>> >>> far more address space than that.
>> >>>
>> >>> I personally make a point of using size_t for all array subscripts.
>> >>> It's standard, unsigned, and matches the address size on the underlying
>> >>> architecture.  That would eliminate the issue on 64-bit systems, which
>> >>> is the only place it will matter anyway.
>> >> Sounds like a good solution, but it will take some thorough search and
>> >> replace...
>> > We can make dolfin::uint a typedef for size_t.
>> >
>> > And I expect some SWIG fixes will be necessary...
>> >
>> >
>> >
>> >> Johan
>> >>
>> >>> Cheers,
>> >>>
>> >>>        -J
>> >>>
>> >>> On 05/24/12 11:53, Anders Logg wrote:
>> >>>> On Wed, May 23, 2012 at 02:02:57PM -0000, Jason Bacon wrote:
>> >>>>> Public bug reported:
>> >>>>>
>> >>>>>
>> >>>>> Have you guys tested with a 64-bit PETSc yet? ( PETSc built with --with-64-bit-indices and/or --with-64-bit-pointers).
>> >>>>>
>> >>>>> The Dolfin code interfacing with PETSc uses int in a lot of places where
>> >>>>> it should use PetscInt.  I can send a minimal set of patches required to
>> >>>>> make it compile, but there are still runtime problems, so the code is
>> >>>>> going to need more thorough examination and testing.
>> >>>> We also use a lot of reinterpret_cast<>    from 'unsigned int'. How will
>> >>>> that work with 64 bit PETSc?
>> >>>>
>> >>>>
>> >>>
>>
>>
>
> --
> You received this bug notification because you are a member of DOLFIN
> Core Team, which is subscribed to DOLFIN.
> https://bugs.launchpad.net/bugs/1003441
>
> Title:
>  Problems with 64-bit PETSc
>
> To manage notifications about this bug go to:
> https://bug...

[Jason Bacon (jwbacon)]

I plan to send patches, after some substantial testing. I have a
working serial version that runs most of the PDE demos, but I'm waiting
for an update to the PETSc port and will have to finish porting Trilinos
and SLEPc to get the MPI version running.

     -J

On 05/24/12 15:15, Anders Logg wrote:
> We currently don't test on FreeBSD but if there is demand for it, we
> might consider adding a FreeBSD buildbot.
>
> Our ambition is to be as cross-platform/standard as possible so if
> you have any patches that improve portability, please post them.
>
> --
> Anders
>
>
> On Thu, May 24, 2012 at 07:58:43PM -0000, Jason Bacon wrote:
>> BTW, I had meant to send my compliments on the overall project
>> organization and code portability. I think it was wise to distribute it
>> as separate modules (ffc, fiat, ..., dolfin), and there were very few
>> patches necessary for each of them to run on FreeBSD.
>>
>> Regards,
>>
>> -J
>>
>> On 05/24/12 13:12, Anders Logg wrote:
>>> On Thu, May 24, 2012 at 06:02:58PM -0000, Johan Hake wrote:
>>>> On 05/24/2012 07:28 PM, Jason Bacon wrote:
>>>>> Well, I think the code will have to be carefully examined and altered to
>>>>> avoid truncation errors when mixing PetscInt and smaller types. I
>>>>> attached the patches necessary to make it compile, but there may still
>>>>> be truncation issues where int arithmetic is used on subscripts elsewhere.
>>>>>
>>>>> I think this is an important issue, given that "int" subscripts limit
>>>>> arrays to 2^31 elements, and Dolfin will be used on many systems with
>>>>> far more address space than that.
>>>>>
>>>>> I personally make a point of using size_t for all array subscripts.
>>>>> It's standard, unsigned, and matches the address size on the underlying
>>>>> architecture. That would eliminate the issue on 64-bit systems, which
>>>>> is the only place it will matter anyway.
>>>> Sounds like a good solution, but it will take some thorough search and
>>>> replace...
>>> We can make dolfin::uint a typedef for size_t.
>>>
>>> And I expect some SWIG fixes will be necessary...
>>>
>>>
>>>
>>>> Johan
>>>>
>>>>> Cheers,
>>>>>
>>>>> -J
>>>>>
>>>>> On 05/24/12 11:53, Anders Logg wrote:
>>>>>> On Wed, May 23, 2012 at 02:02:57PM -0000, Jason Bacon wrote:
>>>>>>> Public bug reported:
>>>>>>>
>>>>>>>
>>>>>>> Have you guys tested with a 64-bit PETSc yet? ( PETSc built with --with-64-bit-indices and/or --with-64-bit-pointers).
>>>>>>>
>>>>>>> The Dolfin code interfacing with PETSc uses int in a lot of places where
>>>>>>> it should use PetscInt. I can send a minimal set of patches required to
>>>>>>> make it compile, but there are still runtime problems, so the code is
>>>>>>> going to need more thorough examination and testing.
>>>>>> We also use a lot of reinterpret_cast<> from 'unsigned int'. How will
>>>>>> that work with 64 bit PETSc?
>>>>>>
>>>>>>
>>

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jason W. Bacon
<email address hidden>
http://personalpages.tds.net/~jwbacon
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Garth Wells (garth-wells)]

Tested with Trilinos. Still need to test with PETSc.