[MITgcm-support] TAMC bug?
Patrick Heimbach
heimbach at MIT.EDU
Sun Aug 3 15:23:42 EDT 2003
Hi Chris,
that's party correct.
However, the set64bitConst.sh does not get rid of the blanks,
thus still produces 1.0 D 1 instead of 1.0D1
(at least on some platforms).
TAMC can handle this, as long as it's not in a PARAMETER statement.
I had made a quick attempt to modify the set64bitConst.sh
but had dropped the issue.
-p.
Chris Hill wrote:
> Hi Patrick,
>
> I thought that was what the set64Const.sh script was for
> i.e
> http://dev.mitgcm.org/cgi-bin/viewcvs.cgi/MITgcm/tools/set64bitConst.sh?
> only_with_tag=MAIN
>
> Doesn't getting rid of _d give us annoying bit reproducibility problems
> across platforms?
>
>
> Chris
>
>
>>-----Original Message-----
>>From: mitgcm-support-bounces at mitgcm.org
>>[mailto:mitgcm-support-bounces at mitgcm.org] On Behalf Of
>>Patrick Heimbach
>>Sent: Friday, August 01, 2003 8:13 PM
>>To: mitgcm-support at mitgcm.org
>>Subject: Re: [MITgcm-support] TAMC bug?
>>
>>
>>Daniel,
>>
>>this is an old TAMC (but not TAF) problem which Ralf chose
>>not to fix. Indeed, TAMC does not unerdstand blanks in
>>PARAMETER statements of the sort you describe (it does
>>understand blanks in other assignments). I had thought I had
>>removed all the _d assignments in PARAMETER statements, but
>>it seems I've overlooked a few. Thanks for the heads-up, I'll
>>commit them soon.
>>
>>Cheers
>>-p.
>>
>>Daniel Lea wrote:
>>
>>>Hi,
>>>
>>>I've been having fun trying to adjoint a recent ECCO version of the
>>>mitgcm. (ecco_c50_e29). I managed to solve the problem I was having
>>>but I thought you might be interested in my travails. I got several
>>>TAMC errors, the first time, for example:
>>>
>>> parsing subroutine ** exf_readparms **
>>>674192 & exf_half = 0.5 D 0 ,
>>> ^
>>>*ERROR* : expected )
>>>674193 & exf_one = 1.0 D 0 ,
>>> ^
>>>*ERROR* : expected (
>>>674194 & exf_two = 2.0 D 0
>>> ^
>>>*ERROR* : expected (
>>>
>>>In the file exf_constants.h these parameter definitions are as
>>>follows:
>>>
>>> parameter(
>>> & exf_half = 0.5 _d 0 ,
>>> & exf_one = 1.0 _d 0 ,
>>> & exf_two = 2.0 _d 0
>>> & )
>>>
>>>CPP replaces the _d with D. This compiles OK so the problem
>>
>>must lie
>>
>>>with TAMC not understanding the spaces in the parameter definition.
>>>
>>>I modified the above to:
>>>
>>> parameter(
>>> & exf_half = 0.5D0 ,
>>> & exf_one = 1.0D0 ,
>>> & exf_two = 2.0D0
>>> & )
>>>
>>>I also modified all other parameter definitions in the same
>>
>>way which
>>
>>>eliminated the problem. Strangely this issue about spacing
>>
>>seems to be
>>
>>>a only a problem to TAMC within parameter statements so it
>>
>>could have
>>
>>>been worse!
>>>
>>>It looks like there might be a policy of migrating to using the _d
>>>form throughout the code. I would vote against this unless TAMC can
>>>understand the resulting code.
>>>
>>>Dan
>>>
>>>_______________________________________________
>>>MITgcm-support mailing list
>>>MITgcm-support at mitgcm.org
>>>http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
>>
>>
>>--
>>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>>Patrick Heimbach ............................. MIT
>>FON: +1/617/253-5259 .......... EAPS, Room 54-1518
>>FAX: +1/617/253-4464 ..... 77 Massachusetts Avenue
>
> mailto:heimbach at mit.edu ....... Cambridge MA 02139
> http://www.mit.edu/~heimbach/ ................ USA
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Patrick Heimbach ............................. MIT
FON: +1/617/253-5259 .......... EAPS, Room 54-1518
FAX: +1/617/253-4464 ..... 77 Massachusetts Avenue
mailto:heimbach at mit.edu ....... Cambridge MA 02139
http://www.mit.edu/~heimbach/ ................ USA
More information about the MITgcm-support
mailing list