[MITgcm-support] optim.x compilation

Matthew Mazloff mmazloff at MIT.EDU
Sat Sep 20 18:10:25 EDT 2008 

Hi Samar,

I did try pgf77 and couldn't get it to work.  Maybe I just needed - 
byteswapio but I think I may have tried this...anyway, as you can see  
from the last email it worked with ifort so I'm not gonna go back and  
mess with it....unless it doesn't run well

-Matt

(oh, and for that run below I had just copied the goto blas libraries  
into the lsopt folder....probably not the best idea but i have some  
bad habits)


On Sep 20, 2008, at 2:56 PM, Samar Khatiwala wrote:

> Matt,
>
> Did you modify the optim/Makefile appropriately? 'f77' on ranger is  
> just g77 (or gfortran?), which may not really be setup for that
> system. Change the compiler to pgf77 or mpif77. You will need to do  
> that anyway to use acml or goto blas. As for compiler options,
> just uncomment the FFLAGS line in Makefile that starts with - 
> byteswapio. Also, you need to provide the path to goto blas (see my
> previous email).
>
> Samar
>
> On Sep 20, 2008, at 5:07 PM, Matthew Mazloff wrote:
>
>> Hi Samar and Patrick,
>>
>> Thanks! I followed the directions below and linked to the goto  
>> blas library.  This got rid of some of the compile error (i.e. the  
>> stuff about incompatible blas).  But I still have truncation issues:
>>
>> f77 -o optim.x  optim_main.o optim_sub.o optim_numbmod.o  
>> optim_initmod.o optim_readdata.o optim_writedata.o  
>> optim_write_control.o xerbla.o simul.o -L. -L../lsopt/  - 
>> llsopt_ecco -lgoto_lp64
>> optim_sub.o: In function `optim_sub__':
>> optim_sub.f:(.text+0x1df): relocation truncated to fit:  
>> R_X86_64_32 against symbol `optiparm_i__' defined in COMMON  
>> section in optim_sub.o
>> optim_sub.f:(.text+0x27f): relocation truncated to fit:  
>> R_X86_64_PC32 against symbol `optiparm_i__' defined in COMMON  
>> section in optim_sub.o
>> optim_sub.f:(.text+0x2b1): relocation truncated to fit:  
>> R_X86_64_32S against `.bss'
>> optim_sub.f:(.text+0x2ba): relocation truncated to fit:  
>> R_X86_64_32S against `.bss'
>> optim_sub.f:(.text+0x2c3): relocation truncated to fit:  
>> R_X86_64_32S against `.bss'
>> optim_sub.f:(.text+0x2c8): relocation truncated to fit:  
>> R_X86_64_32 against symbol `optiparm_i__' defined in COMMON  
>> section in optim_sub.o
>> optim_sub.f:(.text+0x2d6): relocation truncated to fit:  
>> R_X86_64_32 against symbol `optiparm_i__' defined in COMMON  
>> section in optim_sub.o
>> optim_sub.f:(.text+0x2f0): relocation truncated to fit:  
>> R_X86_64_32 against symbol `optiparm_i__' defined in COMMON  
>> section in optim_sub.o
>> optim_sub.f:(.text+0x2fe): relocation truncated to fit:  
>> R_X86_64_32 against symbol `optiparm_r__' defined in COMMON  
>> section in optim_sub.o
>> optim_sub.f:(.text+0x310): relocation truncated to fit:  
>> R_X86_64_32S against symbol `optiparm_r__' defined in COMMON  
>> section in optim_sub.o
>> optim_sub.f:(.text+0x315): additional relocation overflows omitted  
>> from the output
>> collect2: ld returned 1 exit status
>> make: *** [optim.x] Error 1
>>
>> which I feel is related to compiler having trouble with the code.   
>> There is probably some obscure flag I need or something.
>>
>> Any ideas?
>>
>> Thanks
>> Matt
>>
>>
>>
>>
>>
>>
>> On Sep 20, 2008, at 8:51 AM, Samar Khatiwala wrote:
>>
>>> Hi Matt, Patrick
>>>
>>> Just to add to this, ranger has other versions of the blas/lapack  
>>> libraries. If you want goto blas, do:
>>>
>>> module load gotoblas
>>>
>>> then link with:
>>>
>>> -L$TACC_PGI_GOTOBLAS_LIB -lgoto_lp64.a
>>>
>>> BLAS performance for your problem should be completely irrelevant  
>>> (since the bottleneck is the
>>> function/gradient evaluation). So it really doesn't matter which  
>>> library you use.
>>>
>>> Samar
>>>
>>>
>>> On Sep 20, 2008, at 11:07 AM, Patrick Heimbach wrote:
>>>
>>>>
>>>> Hi Matt,
>>>>
>>>> I'm supposed to be offline right now ;o)
>>>>
>>>> Samar is correct, on most platforms we don't use the BLAS  
>>>> libblas anymore.
>>>> E.g. on IBM you were using the ESSL library.
>>>> On the Altix we are using optimized routines by K. Goto
>>>> (see lsopt/README).
>>>>
>>>> Let me know if Samar's instructions work, and we'll add them to  
>>>> the doc.
>>>> Tom (and Samar?) were experimenting with the use of L-BFGS by  
>>>> Nocedal,
>>>> and found very good performance in optimization.
>>>> We should try those as well
>>>>
>>>> Cheers
>>>> -p.
>>>>
>>>> On Sep 19, 2008, at 8:35 PM, Samar Khatiwala wrote:
>>>>
>>>>> Hi Matt,
>>>>>
>>>>> A wild guess: don't you need to compile BLAS on ranger to use  
>>>>> optim? (I think its needed by the CG solver in the L-BFGS  
>>>>> algorithm.)
>>>>>
>>>>> BLAS performance is not critical for this, but you might as  
>>>>> well link to the optimized version available in the
>>>>> AMD acml library on ranger. Add this to your .login_user file:
>>>>>
>>>>> module load acml
>>>>>
>>>>> Then you can link against:
>>>>>
>>>>> /opt/apps/pgi7_1/acml/4.0.1/pgi64/lib/libacml.a
>>>>>
>>>>> or (safer)
>>>>>
>>>>> $TACC_ACML_LIB/libacml.a
>>>>>
>>>>> Samar
>>>>>
>>>>> On Sep 19, 2008, at 6:18 PM, Matthew Mazloff wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Well I am having a hard time compiling optim.x on ranger.  I  
>>>>>> am not sure what I'm doing wrong...the compilation log starts  
>>>>>> to look iffy at
>>>>>>
>>>>>> f77 -o optim.x  optim_main.o optim_sub.o optim_numbmod.o  
>>>>>> optim_initmod.o optim_readdata.o optim_writedata.o  
>>>>>> optim_write_control.o xerbla.o simul.o -L. -L../ 
>>>>>> lsopt/          -llsopt_ecco -lblas
>>>>>> /opt/apps/binutils-amd/070220/bin/ld: skipping incompatible ../ 
>>>>>> lsopt//libblas.so when searching for -lblas
>>>>>> /opt/apps/binutils-amd/070220/bin/ld: skipping incompatible ../ 
>>>>>> lsopt//libblas.a when searching for -lblas
>>>>>> optim_sub.o: In function `optim_sub__':
>>>>>> optim_sub.f:(.text+0x1df): relocation truncated to fit:  
>>>>>> R_X86_64_32 against symbol `optiparm_i__' defined in COMMON  
>>>>>> section in optim_sub.o
>>>>>> optim_sub.f:(.text+0x27f): relocation truncated to fit:  
>>>>>> R_X86_64_PC32 against symbol `optiparm_i__' defined in COMMON  
>>>>>> section in optim_sub.o
>>>>>> optim_sub.f:(.text+0x2b1): relocation truncated to fit:  
>>>>>> R_X86_64_32S against `.bss'
>>>>>> optim_sub.f:(.text+0x2ba): relocation truncated to fit:  
>>>>>> R_X86_64_32S against `.bss'
>>>>>> optim_sub.f:(.text+0x2c3): relocation truncated to fit:  
>>>>>> R_X86_64_32S against `.bss'
>>>>>> optim_sub.f:(.text+0x2c8): relocation truncated to fit:  
>>>>>> R_X86_64_32 against symbol `optiparm_i__' defined in COMMON  
>>>>>> section in optim_sub.o
>>>>>> optim_sub.f:(.text+0x2d6): relocation truncated to fit:  
>>>>>> R_X86_64_32 against symbol `optiparm_i__' defined in COMMON  
>>>>>> section in optim_sub.o
>>>>>> optim_sub.f:(.text+0x2f0): relocation truncated to fit:  
>>>>>> R_X86_64_32 against symbol `optiparm_i__' defined in COMMON  
>>>>>> section in optim_sub.o
>>>>>> optim_sub.f:(.text+0x2fe): relocation truncated to fit:  
>>>>>> R_X86_64_32 against symbol `optiparm_r__' defined in COMMON  
>>>>>> section in optim_sub.o
>>>>>> optim_sub.f:(.text+0x310): relocation truncated to fit:  
>>>>>> R_X86_64_32S against symbol `optiparm_r__' defined in COMMON  
>>>>>> section in optim_sub.o
>>>>>> optim_sub.f:(.text+0x315): additional relocation overflows  
>>>>>> omitted from the output
>>>>>> collect2: ld returned 1 exit status
>>>>>> make: *** [optim.x] Error 1
>>>>>>
>>>>>>
>>>>>>
>>>>>> any advice?
>>>>>> Thanks
>>>>>> Matt
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> MITgcm-support mailing list
>>>>>> MITgcm-support at mitgcm.org
>>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>>>>
>>>>> _______________________________________________
>>>>> MITgcm-support mailing list
>>>>> MITgcm-support at mitgcm.org
>>>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>>>
>>>> ---
>>>> Patrick Heimbach | heimbach at mit.edu | http://www.mit.edu/~heimbach
>>>> MIT | EAPS 54-1518 | 77 Massachusetts Ave | Cambridge MA 02139 USA
>>>> FON +1-617-253-5259 | FAX +1-617-253-4464 | SKYPE patrick.heimbach
>>>>
>>>>
>>>> _______________________________________________
>>>> MITgcm-support mailing list
>>>> MITgcm-support at mitgcm.org
>>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>>
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>>
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mitgcm.org/pipermail/mitgcm-support/attachments/20080920/d14d89d1/attachment.htm>

More information about the MITgcm-support mailing list