<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Feb 1, 2014 at 1:35 PM, Klaus Zimmermann <span dir="ltr"><<a href="mailto:klaus.zimmermann@physik.uni-freiburg.de" target="_blank">klaus.zimmermann@physik.uni-freiburg.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Hi everyone,<br>
<br>
Am 01.02.2014 20:17, schrieb Matthew Knepley:<br>
> On Sat, Feb 1, 2014 at 1:16 PM, David Liu <<a href="mailto:daveliu@mit.edu">daveliu@mit.edu</a><br>
> <mailto:<a href="mailto:daveliu@mit.edu">daveliu@mit.edu</a>>> wrote:<br>
><br>
> I see. Does that s^2 memory scaling mean that sparse direct<br>
> solvers are not meant to be used beyond a certain point? I.e. if<br>
> the supercomputer I'm using doesn't have enough memory per core to<br>
> store even a single row of the factored matrix, then I'm out of<br>
> luck?<br>
><br>
><br>
> Yes exactly<br>
Isn’t that a bit pessimistic? After all there is the out-of-core<br>
facility with mumps.<br></blockquote><div><br></div><div>The question was "sparse direct solvers are not meant to be used beyond a certain point"?</div><div>The answer is definitely yes.</div><div><br></div><div>
   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
In any case I believe the problem here is different:<br>
As you rightly noted there will be some fill-in in the factorization.<br>
It seems to be difficult to know how much beforehand. As I understand<br>
it, mumps takes an educated guess. If the amount of fill-in is large<br>
this just can be too small. If that happens you just should tell mumps<br>
to expect more fill-in by the mentioned icntl(14). From the manual:<br>
- ---<br>
ICNTL(14) is accessed by the host both during the analysis and the<br>
factorization phases. It corresponds<br>
to the percentage increase in the estimated working space. When<br>
significant extra fill-in is caused<br>
by numerical pivoting, increasing ICNTL(14) may help. Except in<br>
special cases, the default value<br>
is 20 (which corresponds to a 20 % increase).<br>
- ---<br>
<br>
There is an alternative: Using icntl(23) you can provide mumps with<br>
the maximum amount of memory in mb that it can use per processor. On<br>
supercomputers you usually have a good idea of the available memory.<br>
Subtract from that the footprint of your program right before the call<br>
to mumps and you should have an optimal value of memory for mumps to<br>
work with.<br>
If the memory then turns out to be insufficient, at least mumps will<br>
notice prior to the factorization and safe your precious cpu hours.<br>
<br>
I use this approach with an additional command line parameter to feed<br>
the total available memory to the program. Actually I thought about<br>
integrating this directly in petsc, but never got around to doing it.<br>
What do you think: Would this find its way into petsc? Or is it to<br>
mumps specific?<br>
<br>
Kind regards<br>
Klaus<br>
<br>
><br>
> Matt<br>
><br>
><br>
> On Fri, Jan 31, 2014 at 9:51 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a><br>
> <mailto:<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>>> wrote:<br>
><br>
> David Liu <<a href="mailto:daveliu@mit.edu">daveliu@mit.edu</a> <mailto:<a href="mailto:daveliu@mit.edu">daveliu@mit.edu</a>>> writes:<br>
><br>
>> Hi, I'm solving a 3d problem with mumps. When I increased the<br>
> grid size to<br>
>> 70x60x20 with 6 unknowns per point, I started noticing that<br>
> the program was<br>
>> crashing at runtime at the factoring stage, with the mumps<br>
> error code:<br>
>><br>
>> -17 The internal send buffer that was allocated dynamically by<br>
> MUMPS on the<br>
>> processor is too small. The user should increase the value of<br>
>> ICNTL(14) before calling<br>
> MUMPS again.<br>
>><br>
>> However, when I increase the grid spacing in the z direction<br>
> by about 50%,<br>
>> this crash does not happen.<br>
>><br>
>> Why would how much memory an LU factorization uses depend on<br>
> an overall<br>
>> numerical factor (for part of the matrix at least) like this?<br>
><br>
> I'm not sure exactly what you're asking, but the complexity of<br>
> direct solves depend on the minimal vertex separators in the<br>
> sparse matrix/graph.  Yours will be s=60*20*6 (more if your stencil<br>
> needs second neighbors).  The memory usage scales with s^2 and the<br>
> factorization time scales with s^3.<br>
><br>
><br>
><br>
><br>
><br>
> -- What most experimenters take for granted before they begin<br>
> their experiments is infinitely more interesting than any results<br>
> to which their experiments lead. -- Norbert Wiener<br>
<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.14 (GNU/Linux)<br>
Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
iQEcBAEBAgAGBQJS7UyKAAoJEHGtO1Agqpgxx0sIAIEVY81Sh6jyJC7ScSVuC+P7<br>
2iaCKOmVwDb5yD6QaM88AGIdIiOHA5yFehU3IYBM2GhbWkvgiT3ylEgfjh5akp5R<br>
MNbn0FFmD4ycq83CBIg1TsiQj6V9fX+7Y6ROAABGdLlk0qNolN0apRKFfn/H7FnT<br>
YqExKSgoBp+ctt5/XsK2BdyHxiopTPjSx6J0xd+KjHhpbE97KxxURbm4vsPv+clj<br>
7PrRpXbJnannMvHYQVfmVmmurw/yC47KeX8aqQTGWYrRZUfOnQ8K4Z3uzT5XzQ1l<br>
TW6lruaFPu+y1r8oJAA8+Fp1pf06Jjx85fDb9VelRwaIoNIS1B41KEmByHpsf3w=<br>
=nXDH<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>