[FLASH-USERS] Question about grid size

Wed May 24 13:06:58 EDT 2017

Hi Malia :

  To add to the other comments, the key point is that even though FLASH
employs adaptive mesh refinement, it allocates all memory for all possible
blocks that will ever exist in the simulation at build time. This is in
contrast to other packages where the memory allocation is also fully
dynamic.

  To circumvent your memory issues, if you are certain you will only be
using a 512^2 mesh, you should either employ the uniform grid option as I
suggested earlier (+ug on setup) or otherwise dial your MAXBLOCKS may down.
Additionally, as John suggested, you can experiment with the block size to
optimize performance.

  -B

On Wed, May 24, 2017 at 1:00 PM, John ZuHone <jzuhone at gmail.com> wrote:

> From a computational perspective, having blocks with that many zones is
> pretty impractical. FLASH’s performance is much better with far smaller
> sizes (such as 16x16).
>
> I’d recommend picking nblock[xy] in the parameter file such that when you
> multiply it by whatever you pick for -n[xy]b (something like 16 or 32)
> yields 512. It should be fairly easy that writes a setup that maps from the
> initial condition to that pattern of blocks.
>
> On May 24, 2017, at 12:56 PM, Jenks, Malia T. <mjenks at ou.edu> wrote:
>
> Tomek,
>
> Where does the 2000 come from?
> Maxblocks is auto set to 1000.
>
> The point is I am reading in an external grid that is 512x512 and I want
> the FLASH grid to match it exactly  so that I can do a trivial map of the
> physical quantities.
>
> I'm missing something.
>
> Malia
> ------------------------------
> *From:* Jenks, Malia T.
> *Sent:* Wednesday, May 24, 2017 10:32:34 AM
> *To:* flash-users at flash.uchicago.edu
> *Subject:* Re: Question about grid size
>
> Hmm, somehow Flash is statically allocating more than the Linux 2GB limit.
> I'm surprised that anything is statically allocated.
>
> I did a parallel compile but assuming (for debugging purposes) that I
> would just use 1 CPU. Thus, I set iProcs =1
> jProcs=1  and
>
> setup -2d +cylindrical +usm -nxb=512 -nyb=512 -auto
>
> Then at link time I get:
>
> Burn.o: In function `burn':
> /home/mjenks/FLASH4.4/object/Burn.F90:107:(.text+0xe3): relocation
> truncated to fit: R_X86_64_PC32 against symbol `burn_data_mp_bn_useburn_'
> defined in COMMON section in Burn_data.o
> /home/mjenks/FLASH4.4/object/Burn.F90:115:(.text+0x2ad): relocation
> truncated to fit: R_X86_64_PC32 against symbol
> `burn_data_mp_bn_useshockburn_' defined in COMMON section in Burn_data.o
> /home/mjenks/FLASH4.4/object/Burn.F90:145:(.text+0x604): relocation
> truncated to fit: R_X86_64_PC32 against symbol
> `burn_data_mp_bn_useshockburn_' defined in COMMON section in Burn_data.o
> /home/mjenks/FLASH4.4/object/Burn.F90:172:(.text+0x897): relocation
> truncated to fit: R_X86_64_PC32 against symbol `burn_data_mp_bn_nucleartempmin_'
> defined in COMMON section in Burn_data.o
> /home/mjenks/FLASH4.4/object/Burn.F90:175:(.text+0x8bc): relocation
> truncated to fit: R_X86_64_PC32 against symbol `burn_data_mp_bn_nucleartempmax_'
> defined in COMMON section in Burn_data.o
> /home/mjenks/FLASH4.4/object/Burn.F90:174:(.text+0x8dc): relocation
> truncated to fit: R_X86_64_PC32 against symbol
> `burn_data_mp_bn_useshockburn_' defined in COMMON section in Burn_data.o
> /home/mjenks/FLASH4.4/object/Burn.F90:173:(.text+0x8f1): relocation
> truncated to fit: R_X86_64_PC32 against symbol `burn_data_mp_bn_nucleardensmin_'
> defined in COMMON section in Burn_data.o
> /home/mjenks/FLASH4.4/object/Burn.F90:173:(.text+0x8f9): relocation
> truncated to fit: R_X86_64_PC32 against symbol `burn_data_mp_bn_nucleardensmax_'
> defined in COMMON section in Burn_data.o
> /home/mjenks/FLASH4.4/object/Burn.F90:181:(.text+0x961): relocation
> truncated to fit: R_X86_64_PC32 against symbol `burn_data_mp_bn_nuclearni56max_'
> defined in COMMON section in Burn_data.o
> Burn_computeDt.o: In function `burn_computedt':
> /home/mjenks/FLASH4.4/object/Burn_computeDt.F90:108:(.text+0x16):
> relocation truncated to fit: R_X86_64_PC32 against symbol
> `burn_data_mp_bn_useburn_' defined in COMMON section in Burn_data.o
> /home/mjenks/FLASH4.4/object/Burn_computeDt.F90:141:(.text+0x69):
> additional relocation overflows omitted from the output
> make: *** [flash4] Error 1
>
> which means that I have > 2GB of static data see https://software.intel.
> com/en-us/forums/intel-fortran-compiler-for-linux-
> and-mac-os-x/topic/268374
>
> which shouldn't be happening.
>
> Ideas?
>
> Malia
> relocation truncated to fit: R_X86_64_PC32 - Intel® Software
> <https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/268374>
> software.intel.com
> Hi, I'm trying to compile a big code that so far has been running
> fine.Now, we have surpassed the 2GB in statically allocated data limit. I
> knew that would bring us ...
>
>
> ------------------------------
> *From:* Jenks, Malia T.
> *Sent:* Tuesday, May 23, 2017 4:29:17 PM
> *To:* flash-users at flash.uchicago.edu
> *Subject:* Question about grid size
>
> I tried to increase the number of cells in my 2d model to 512 by 512. It
> will not compile at this size and I get an error about static memory. Is
> there a way I can solve this?
>
> Malia Jenks
>
>
>

-- 
Dr. Robert Fisher
Associate Professor / Graduate Program Director
University of Massachusetts/Dartmouth
Department of Physics
285 Old Westport Road
North Dartmouth, Massachusetts 02747
robert.fisher at umassd.edu
http://www.novastella.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20170524/5e89a730/attachment.htm>