[Nek5000-users] Question - SIZE Parameters And Compilation Errors

[nek5000-users at lists.mcs.anl.gov]

Hi,

You can also search the user-list email archives to see if others have had
similar problems:

http://lists.mcs.anl.gov/pipermail/nek5000-users/

Best,
Katie


On Mon, Apr 15, 2013 at 11:14 AM, <nek5000-users at lists.mcs.anl.gov> wrote:

>
> Hi Murph,
>
> A couple of options here:
>
> 1) Try recompiling with  G = "-mcmodel=medium" in makenek.
>
> 2) Use more than one core so that lelt can remain the same
>    but lelg can be as large as lelt*P, where P is the number
>    of cores you'd like to use.
>
> Raw email is the standard interface as far as I know...
>
> hth,
>
> Paul
>
>
> On Mon, 15 Apr 2013, nek5000-users at lists.mcs.anl.**gov<nek5000-users at lists.mcs.anl.gov>wrote:
>
>  Hi All,
>>
>> Trying to run some initial test cases of a problems I'm working on:
>> - Currently on single node (SMP Linux)
>> - MPI turned off (IFMPI="false")
>> - DOF at 5 (lx1=6, lxd=9, lelx=8)
>>
>> If I run with lp=1,lelt=2160, lelg=2160, for a 12x12x15 mesh, it compiles
>> and runs fine.
>>
>> If I up it to lp=1,lelt=4500,lelg=4500, for a 15x15x20 mesh, it crashes
>> the compile with:
>>
>> obj/drive2.o: In function `plan4_vol_':
>> drive2.f:(.text+0x82f): relocation truncated to fit: R_X86_64_32S against
>> symbol `scrvh_' defined in COMMON section in obj/hsmg.o
>> drive2.f:(.text+0x837): relocation truncated to fit: R_X86_64_32S against
>> symbol `scrvh_' defined in COMMON section in obj/hsmg.o
>> obj/drive2.o: In function `plan3_vol_':
>> drive2.f:(.text+0xac5): relocation truncated to fit: R_X86_64_32S against
>> symbol `scrvh_' defined in COMMON section in obj/hsmg.o
>> drive2.f:(.text+0xacd): relocation truncated to fit: R_X86_64_32S against
>> symbol `scrvh_' defined in COMMON section in obj/hsmg.o
>> obj/drive2.o: In function `plan2_vol_':
>> drive2.f:(.text+0xeb8): relocation truncated to fit: R_X86_64_32S against
>> symbol `scrvh_' defined in COMMON section in obj/hsmg.o
>> drive2.f:(.text+0xec0): relocation truncated to fit: R_X86_64_32S against
>> symbol `scrvh_' defined in COMMON section in obj/hsmg.o
>> obj/drive2.o: In function `dofcnt_':
>> drive2.f:(.text+0x170f): relocation truncated to fit: R_X86_64_PC32
>> against symbol `scrns_' defined in COMMON section in obj/convect.o
>> obj/drive2.o: In function `settime_':
>> drive2.f:(.text+0x7cc9): relocation truncated to fit: R_X86_64_PC32
>> against symbol `cprint_' defined in COMMON section in obj/navier1.o
>> drive2.f:(.text+0x7cef): relocation truncated to fit: R_X86_64_PC32
>> against symbol `cprint_' defined in COMMON section in obj/navier1.o
>> drive2.f:(.text+0x7d02): relocation truncated to fit: R_X86_64_PC32
>> against symbol `cprint_' defined in COMMON section in obj/navier1.o
>> obj/plan4.o: In function `crespsp_':
>> plan4.f:(.text+0xb23): additional relocation overflows omitted from the
>> output
>> collect2: ld returned 1 exit status
>> make: *** [nek5000] Error 1
>>
>> Just wondering if this is due to a true limit with the platform/word
>> size, or if I'm screwing something up...
>>
>> Thanks,
>> Murph
>>
>> PS - Is there any other interface to this list other than raw email?
>>
>>
>>
>> --
>>
>> *Murphy Leo O'Dea, PE"Murph"*
>>
>> PhD Student, Mechanical Engineering
>>
>> /School Of Engineering And Computer Science/
>>
>> /Oakland University/
>>
>> mlodea at oakland.edu <mailto:mlodea at oakland.edu>
>>
>> http://www.secs.oakland.edu/~**mlodea/<http://www.secs.oakland.edu/~mlodea/>
>>
>>
>>  ______________________________**_________________
> Nek5000-users mailing list
> Nek5000-users at lists.mcs.anl.**gov <Nek5000-users at lists.mcs.anl.gov>
> https://lists.mcs.anl.gov/**mailman/listinfo/nek5000-users<https://lists.mcs.anl.gov/mailman/listinfo/nek5000-users>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/nek5000-users/attachments/20130415/dff2ead8/attachment.html>