[MITgcm-support] adjoint compilation on 64bit system

[Martin Losch]

Hi Patrick,

my error log was not complete, as usual. In fact, the problems are not 
limited to adconvective_adjustments: Many routines have the similar 
problem, i have not found a pattern, yet. (all error messages of the 
link step are attached in make.log fyi).

Still another question, (maybe more urgent, as the flag -fpic seems to 
solve my problem):
I need to switch platforms in the middle of an optimization, from a 
linux_ia32 system with ifc to an linux_amd64 system with pgf77. after 
recompiling mitgcmuv_ad I thought, all i need are the current 
ecco_ctrl*opt???? ecco_cost*opt???? files to extract the control 
vector, but when reading the new control vector, there is a problem: 
mitgcmuv_ad tried to read past the end of the file. Is that supposed to 
work, or is that a problem that I cannot fix? (this is not an exclusive 
"or", is it? (o:) I have not even tried reading OPWARMD and OPWARMI 
with a optim.x on the amd64 machine, that's probably even more 
problematic?

Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: make.log
Type: application/octet-stream
Size: 74537 bytes
Desc: not available
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20050224/2a7d7801/attachment.obj>
-------------- next part --------------

On Feb 24, 2005, at 1:46 PM, Patrick Heimbach wrote:

>
> Hi Martin,
>
> you know I'm not a compiler guy, so the following
> might be complete nonsense:
>
> Quite a few adjoint routines contain loop inversions,
> in particular w.r.t. K.
> You'll see for adconvective_adjustment that the forward loop
>           DO K=kTop,kBottom,kDir
> gets transformed into
>         do k = ktop+kdir*(int((kbottom-ktop+kdir)/kdir)-1), ktop, -kdir
> (which of course is the same as do k = kbottom,ktop,-kdir).
>
> I suspect that this gives the compiler optimization a few headaches.
> One way to check is to see whether S/R mdconvective_adjustment
> has the same problems. It does access the same tapes/common blocks,
> but in "forward order".
>
> You could also check, what effect has replacing
>         do k = ktop+kdir*(int((kbottom-ktop+kdir)/kdir)-1), ktop, -kdir
> by
>         do k = kbottom, ktop, -kdir
>
> Re. S/R barrier.F, try to put this routine in the NOOPTFILES list.
>
> -p.
>
>
>
> On Thursday 24 February 2005 05:11, Martin Losch wrote:
>> Hi,
>>
>> I am trying to compile the adjoint MITgcm on an AMD 64bit opteron
>> machine with the Portland Group fortran compiler. I have no problems
>> with my build options file linux_amd64_pgf77_ocl (that I am 
>> responsible
>> for anyway) as long as I don't ALLOW_ECCO_ADJOINT_RUN (in
>> ECCO_CPPOPTIONS.h), but use ALLOW_ECCO_FORWARD_RUN. But as soon as
>> there is the adjoint model involved (ad_taf_output.f) I get funny 
>> error
>>
>> messages at the link step:
>>> ad_taf_output.o: In function `adconvective_adjustment_':
>>> ad_taf_output.o(.text+0xf018): relocation truncated to fit:
>>> R_X86_64_32S cadtheta_
>>> ad_taf_output.o(.text+0xf038): relocation truncated to fit:
>>> R_X86_64_32S cadtheta_
>>> ad_taf_output.o(.text+0xf4e0): relocation truncated to fit:
>>> R_X86_64_32S cadthetb_
>>> ad_taf_output.o(.text+0xf501): relocation truncated to fit:
>>> R_X86_64_32S cadthetb_
>>
>> (most of them concern common blocks defined in ad_taf_output.f for the
>>
>> tapes) but also:
>>> /var/tmp.shared/pgi/linux86-64/5.2/lib/libpgc.a(barrier.o): In
>>> function `_mp_get_parpar':
>>> barrier.o(.text+0x69): relocation truncated to fit: R_X86_64_32S
>>> _mp_parpar
>>> /var/tmp.shared/pgi/linux86-64/5.2/lib/libpgc.a(barrier.o): In
>>> function `_mp_lcpu2':
>>> barrier.o(.text+0x34e): relocation truncated to fit: R_X86_64_32S
>>> _mp_parpar
>>
>> which doesn't have anything to do with ad_taf_output.f
>> These errors go away when I use an additional optiong: -fpic, which
>> according to the man pages "(Linux only) Instructs the compiler to
>> generate position-independent code with can be used to create shared
>> object files ..."
>>
>> I don't see why the TAMC/TAF generated code should need this option
>> while the remaining part of the code doesn't need it. Any ideas?
>>
>> Martin
>>
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://dev.mitgcm.org/mailman/listinfo/mitgcm-support
>
> -- 
> ----------------------------------------------------------
> Patrick Heimbach     Massachusetts Institute of Technology
> 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
>