<div class="gmail_quote">On Fri, Jun 29, 2012 at 1:10 AM, Thomas DE-SOZA <span dir="ltr"><<a href="mailto:thomas.de-soza@edf.fr" target="_blank">thomas.de-soza@edf.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<br><font size="3" face="sans-serif">Or does it mean that in the preallocation we have to take care of the values that come from the stash of another processor even if they are added to preexisting entries on the process ?</font><font size="3" face="Times New Roman"> </font>
<br>
<br><font size="3" face="Times New Roman">You only have to allocate the entries once, but there are entries that were not preallocated at all.</font>
<br>
<br></div><font face="sans-serif">We haven't been able to narrow the problem in our preallocation yet but by preallocating the entries for the incoming stash values (even if it should not be needed as you pointed out) we're now overestimating the nnz and performance is OK (log attached for those curious) : no more mallocs in MatSetValues.</font>
<br></blockquote><div><br></div><div>Run in a debugger with -mat_new_nonzero_allocation_err. It will stop at the first inserted value that was not preallocated. This usually helps you to figure out why that value (or one already inserted in that row) was not preallocated.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><font face="sans-serif">Many thanks for your help !</font>
<br>
<br><font face="sans-serif">Thomas</font>
<br>
<br>
<br>
<br>
<br>
<p></p><table width="100%">
<tbody><tr valign="top">
<td>
</td><td><font size="1" face="sans-serif"><b><a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a></b></font>
<br><font size="1" face="sans-serif">Envoyé par : <a href="mailto:petsc-users-bounces@mcs.anl.gov" target="_blank">petsc-users-bounces@mcs.anl.gov</a></font>
<p><font size="1" face="sans-serif">28/06/2012 19:33</font>
<br><font size="1" face="sans-serif">Veuillez répondre à petsc-users</font>
<br>
</p></td><td><div class="im"><font size="1" face="Arial"> </font>
<br><font size="1" face="sans-serif"> Pour : <a href="mailto:petsc-users@mcs.anl.gov" target="_blank">petsc-users@mcs.anl.gov</a></font>
<br><font size="1" face="sans-serif"> cc : <a href="mailto:nicolas.sellenet@edf.fr" target="_blank">nicolas.sellenet@edf.fr</a>, (ccc : Thomas DE-SOZA/A/EDF/FR)</font>
<br></div><font size="1" face="sans-serif"> Objet : Re: [petsc-users] Réf. : Re: Avoiding malloc overhead for unstructured finite element meshes</font></td></tr></tbody></table><div class="HOEnZb"><div class="h5">
<br>
<br>
<br><font size="3" face="Times New Roman">On Thu, Jun 28, 2012 at 9:29 AM, Thomas DE-SOZA <</font><a href="mailto:thomas.de-soza@edf.fr" target="_blank"><font size="3" color="blue" face="Times New Roman"><u>thomas.de-soza@edf.fr</u></font></a><font size="3" face="Times New Roman">> wrote:</font>
<br><font size="3" face="sans-serif">Since 9900 coefficients were uneeded, we had first thought that enough room was preallocated. <br>
>From what you're telling us, I understand that we may have given an overall size which is large enough to contain the diagonal block but whose nnz line by line is not correct hence the mallocs. Is that correct ?</font><font size="3" face="Times New Roman"> </font>
<br>
<br><font size="3" face="Times New Roman">Unlikely, extra space is dynamically allocated in bigger chunks so there is usually some left over when mallocs are needed in MatSetValues. You should be careful to get nnz correct, but that is not the only problem here.</font>
<br><font size="3" face="Times New Roman"> </font>
<br><font size="3" face="sans-serif"><br>
Or does it mean that in the preallocation we have to take care of the values that come from the stash of another processor even if they are added to preexisting entries on the process ?</font><font size="3" face="Times New Roman"> </font>
<br>
<br><font size="3" face="Times New Roman">You only have to allocate the entries once, but there are entries that were not preallocated at all.</font>
<br>
<br><p></p>
</div></div><div class="HOEnZb"><div class="h5"><p><br>
Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse.</p>
<p>Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message.</p>
<p>Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus.<br>
____________________________________________________</p>
<p>This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.</p>
<p>If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message.</p>
<p>E-mail communication cannot be guaranteed to be timely secure, error or virus-free.</p></div></div></blockquote></div><br>