<div dir="ltr">Hi Norbert,<div><br></div><div>Thanks.</div><div>I control the refinement criteria so that my code does not refine everywhere and as you can see the actual maximum number of leaf blocks that it creates is 932 i.e. no more than a block on a processor; needless to say it doesn't even go far to creates all required blocks on 512 processors. </div><div><br></div><div>Best,</div><div>rahul</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 11, 2016 at 8:57 AM, Norbert Flocke <span dir="ltr"><<a href="mailto:flocke@flash.uchicago.edu" target="_blank">flocke@flash.uchicago.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Rahul,<br>
<br>
>From your setup script I see that you are using:<br>
<br>
   lrefinemax = 7<br>
   nblockx = 4<br>
   +cube32<br>
<br>
This would mean that for your run you are asking for:<br>
<br>
   (2^3)^(lrefmax-1) * 4 = 1048576 = 1024^2 blocks<br>
<br>
Divide this by 1024 procs and you get: 1024 per proc.<br>
So you should at least put maxblocks > 1024. On the other<br>
hand +cube32 means 32^3 cells per block. So on each proc<br>
there should be at least 32^3 * 1024 = 33,554,432 of<br>
memory, if you are using only one variable per cell (which<br>
you are probably not, you are using more). Your memory<br>
requirements are excessive.<br>
<br>
Best,<br>
Norbert<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Wed, 10 Aug 2016, Rahul Kashyap wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Klaus,<br>
<br>
Thanks for replying.<br>
<br>
Yes, I forgot to mention that I'm using new multipole implementation with<br>
60 poles.<br>
<br>
I have attached a small txt files with short summary on three runs which<br>
very well describes my problem. 1024 proc have been used for all runs with<br>
fixed lrefinemax and base blocks. I get three differenet error for three<br>
different maxblocks value.<br>
<br>
My understanding was that reasonable use of maxblocks avoids any such<br>
memory failures.<br>
<br>
Best,<br>
-rahul<br>
<br>
On Wed, Aug 10, 2016 at 6:11 PM, Klaus Weide <<a href="mailto:klaus@flash.uchicago.edu" target="_blank">klaus@flash.uchicago.edu</a>><br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, 5 Aug 2016, Rahul Kashyap wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
More specifically, I'm having problem in using multipole Gravity solver<br>
which causes memory allocation failure during initialization and also<br>
evolution. I couldn't get far with my naive knowledge of FLASH's usage of<br>
'-maxblocks'.<br>
</blockquote>
<br>
Are you using the newer implementation of the multipole solver,<br>
<br>
  Grid/GridSolvers/Multipole_new<br>
<br>
rather than<br>
<br>
  Grid/GridSolvers/Multipole ?<br>
<br>
(One way to request the newer version is to use the setup shortcut<br>
 +newMpole .)<br>
<br>
The newer version should behave better in terms of memory usage.<br>
<br>
Klaus<br>
<br>
</blockquote>
<br>
</blockquote>
</div></div></blockquote></div><br></div>