[Developers] [Patches] more efficient synchronisation of groups
goodale at cct.lsu.edu
Mon Jul 3 10:37:42 CDT 2006
On Mon, 3 Jul 2006, Erik Schnetter wrote:
> On Jul 3, 2006, at 09:54:14, Tom Goodale wrote:
>> On Mon, 3 Jul 2006, Tom Goodale wrote:
>>> On Mon, 3 Jul 2006, Thomas Radke wrote:
>>>> After some discussion, Jonathan and I came to the same conclusion. So I
>>>> will change the API back to using C integers then.
>>>> I wonder why we designed other flesh interfaces to take CCTK_INT arrays,
>>>> for instance CCTK_InterpGridArrays() or CCTK_ReduceGridArrays() ?
>>>> [If this starts a whole new discussion thread we should probably change
>>>> the subject.]
>>> CCTK_INT is supposed to guarantee the same size for the type in both
>>> languages; just using 'int' and 'INTEGER' do not.
>> This has caused problems on machines in the past - e.g. the T3E.
> Consider the Fortran code:
> integer idx
> call CCTK_VarIndex (idx, "thorn::var")
> which calls the C wrapper:
> void CCTK_FNAME (CCTK_VarIndex) (int * idx, CCTK_ONE_FORTRANSTRING);
> This works only if int and integer have the same size. Many compilers have
> switches, especially Fortran compilers, to select the size of an integer.
> Many compilers use the same back end for both Fortran and C code, and
> presumably Fortran and C will become more "similar" (i.e., interoperable) in
> the future, not less. The T3E is dead.
> If you are really concerned about integer sizes, then you have to make all
> arguments CCTK_INT, not just the arrays.
> Howver, look e.g. at the Fortran WaveToy examples. None of them handle
> CCTK_INT correctly in their calls to Boundary_SelectVarForBC; they all assume
> that CCTK_INT is the same as integer. This is even worse than assuming that
> int and integer are the same, since CCTK_INT can be set to be integer*8.
> Using different integer types is a place where Fortran and C differ much. In
> C, using a different integer types is not much of a deal, since routine
> arguments are automatically converted. They are not automatically converted
> in Fortran, and this leads to complicated code.
I'm not saying we have always been consistent in the past. We have not,
and this has caused problems. What I am saying is that we should do
better in future.
More information about the Developers