[Developers] what datatype to use in inter-language APIs (was: Re: [Patches] more efficient synchronisation of groups)
schnetter at cct.lsu.edu
Mon Jul 3 12:43:25 CDT 2006
On Jul 3, 2006, at 11:49:53, Thomas Radke wrote:
> Tom Goodale wrote:
>> 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
>>>>> 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
>>> Many compilers use the same back end for both Fortran and C code,
>>> 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
>>> 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
>>> 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
>>> 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.
> I tend to follow Tom's suggestion to stick with the current scheme
> of using
> * native datatypes for passing scalar arguments
> * CCTK datatypes for passing array arguments
That is not quite the scheme we use currently; this scheme is used
only in the interpolation API. For example,
CCTK_GroupStorageIncrease passes integer arrays, and so do
CCTK_Grouplsh and friends, and CCTK_StaggerDirArray and friends. The
cctkGH entries are also integer arrays.
I would rather describe the current scheme as "flesh uses int,
aliased functions use CCTK_INT", with interpolation being the exception.
> in inter-language APIs. This shouldn't introduce any inconvenience for
> Fortran programmers when setting up their function array arguments;
> scalars can still be passed as native Fortran datatypes, for passing
> literal constants in F77 code that is the only thing possible anyway.
Not quite. Consider the case where a user wants to synchronise two
groups at the same time. He/she would then write
call CCTK_GroupIndex (groups1(1), "bla")
call CCTK_Groupindex (groups1(2), "bla")
groups2 = groups1
call CCTK_SyncGroupsI (cctkGH, 2, groups2)
The conversion from "integer" to "CCTK_INT" has to be explicit, which
is an inconvenience. Alternatively, one can write
CCTK_INT, parameter :: idummy = 0
integer, parameter :: ik = kind(idummy)
call CCTK_GroupIndex (groups(1), "bla")
call CCTK_Groupindex (groups(2), "bla")
call CCTK_SyncGroupsI (cctkGH, 2, int(groups,ik))
Here, the conversion is done with the array operation "int(..., ik)".
> This will work as long as the (so far) implicite assumption is true
> a native Fortran datatype is equivalent to the corresponding native C
> datatype. If we had a machine where this is not true then I can't
> how Cactus would ever run there.
If we assume that anyway... then why make some arguments integers,
> It also leaves us with the possibility to make it an explicite
> assumption later, ie. determine in the configure script the C
> to a native Fortran integer, and use that C datatype in all the
> wrappers, without changing all the APIs again.
That would be nice. We can do that also with arrays, especially with
small arrays like this one containing grid function indices.
> But let's keep this latter issue separate from the first so that I can
> proceed with my revised patch for optimising group synchronisation in
> Is that common agreement ?
Given the current ambiguities with some functions using int, others
using CCTK_INT, I don't know what is best. I seem to be advocating
using int instead of CCTK_INT, but I really only want to point out
some of the problems. I don't know what the best solution would be.
Erik Schnetter <schnetter at cct.lsu.edu>
My email is as private as my paper mail. I therefore support encrypting
and signing email messages. Get my PGP key from www.keyserver.net.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.cactuscode.org/pipermail/developers/attachments/20060703/c32f1389/attachment-0001.bin
More information about the Developers