[MITgcm-support] optim.x compilation

Matthew Mazloff mmazloff at MIT.EDU
Sat Sep 20 18:02:45 EDT 2008 

Solved!

well, at least it compiled.

I switched to Intel ifort compiler and compiled lsopt with
FFLAGS          = -mcmodel=medium  -O3 -xW
and optim with
FFLAGS          = -i_dynamic  -mcmodel=medium  -O3 -xW

(I found this from thread:  http://forge.csail.mit.edu/pipermail/ 
mitgcm-support/2005-October/003505.html ), so thanks Constantinos.

so now I'll try running

-Matt



On Sep 20, 2008, at 2: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

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

More information about the MITgcm-support mailing list