[Dune-devel] dune-istl umfpack support

[Benedikt Oswald]

that is quite interesting. In fact, in the very beginning I used the serial SuperLU and
then transitioned to SuperLU Dist. There, I realised that even for the serial operation
of SuperLU Dist it was considerably better and more efficient than SuperLU,

Thus, I think even in the serial case it pays off to use SuperLU Dist.

Greetings, Benedikt



On Oct 31, 2013, at 2:53 PM, Dominic Kempf <dominic.r.kempf at gmail.com> wrote:

> Hey Benedikt,
> I was referring to the serial version of SuperLU, as there is no
> solver in ISTL using SuperLUDist.
> Best,
> Dominic
> 
> On Thu, Oct 31, 2013 at 2:42 PM, Benedikt Oswald
> <benedikt.oswald at lspr.ch> wrote:
>> Hello Dominic, thanks for these numbers!
>> In fact, I am using SuperLU Dist (MPI, parallel, complex distributed
>> matrix).
>> 
>> When you say SuperLU, do you mean SuperLU Dist or the serial version ?
>> 
>> Greetings, Benedikt
>> 
>> 
>> 
>> --------------------------------------------------------------------------------------------------------------------------------------------------------------
>> Dr. sc. techn. Benedikt Oswald - first engineer - LSPR AG - phone - +41 43
>> 366 90 74
>> Technoparkstrasse 1, CH-8005 Zürich, benedikt.oswald at lspr.ch
>> "Passion is required for any great work, and for the Revolution passion and
>> audacity are required in big doses."
>> Ernesto 'Che' Guevara, Letter to his parents.
>> --------------------------------------------------------------------------------------------------------------------------------------------------------------
>> 
>> On Oct 31, 2013, at 1:45 PM, Dominic Kempf <dominic.r.kempf at gmail.com>
>> wrote:
>> 
>> Hey Christoph,
>> Hey devel-list,
>> 
>> while doing a writeup of my work for Markus, I reran some of the
>> performance tests and realized that infact SuperLU and UMFPack
>> performance results are NOT within the same order of magnitude.
>> UMFPack shows significantly better performance, see this table (I hope
>> its somehwat readable)
>> 
>> dofs                   1e4           4e4         1.6e5          6.4e5
>> T_{superlu}         0.076        0.395       2.707         19.839
>> T_{umfpack}       0.064        0.245       1.367         9.176
>> time savings      15.79%      37.98%    49.51%      53.75%
>> $M_{superlu}      30.78 MB  123.23 MB 493.2 MB
>> $M_{umfpack}    25.72 MB  88.66 MB  418.9 MB
>> mem savings     16.44%     28.06%     15.07%
>> $P_{superlu}      13.4 MB    55.64 MB  253.18 MB  1.16 GB
>> $P_{umfpack}    11.8 MB    41.33 MB  177.14 MB  771.16 MB
>> peakmem sav.   11.95%     25.72%     30.04%       33.53%
>> 
>> T is the wallclock time here, M the total allocation size as given by
>> valgrind and P the peak memory usage as given by /usr/bin/time -v.
>> As you can see, there is something to be gained here!
>> 
>> Best,
>> Dominic
>> 
>> On Thu, Oct 17, 2013 at 10:33 AM, Dominic Kempf
>> <dominic.r.kempf at gmail.com> wrote:
>> 
>> Hey Christoph,
>> thanks for testing the branch. My system gave me memory with zeroes,
>> yours didnt... thats exactly where I need you.
>> 
>> I did a bit of measurements to compare superlu and umfpack, though not
>> on hard problems. In those tests umfpack was a bit faster and needed
>> less memory, within the same order of magnitude though. The original
>> reasons to implement umfpack support were conceptional difficulties
>> with superlu in multithreaded environment. Markus can elaborate more
>> on that (and whether umfpack actually solved the issue).
>> 
>> 
>> Best,
>> Dominic
>> 
>> 2013/10/17 Christoph Grüninger <christoph.grueninger at iws.uni-stuttgart.de>:
>> 
>> Hi Dominic,
>> thanks for the quick patch. Using commit ...da3510863 it does no longer
>> segfault.
>> 
>> Bye
>> Christoph
>> 
>> --
>> Une science n'était vraiment développée que quand elle
>> pouvait utiliser les mathématiques.    (Paul Lafargue)
>> *********************************************
>> CMWR 2014: 10th - 13th June 2014 in Stuttgart
>>        Please visit www.cmwr14.de
>> *********************************************
>> 
>> _______________________________________________
>> Dune-devel mailing list
>> Dune-devel at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune-devel
>> 
>> 
>> _______________________________________________
>> Dune-devel mailing list
>> Dune-devel at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune-devel
>> 
>> 
>> 
>> _______________________________________________
>> Dune-devel mailing list
>> Dune-devel at dune-project.org
>> http://lists.dune-project.org/mailman/listinfo/dune-devel
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20131031/bb145233/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dune-project.org/pipermail/dune-devel/attachments/20131031/bb145233/attachment.sig>