[petsc-users] Réf. : Re: Réf. : Re: Avoiding malloc overhead for unstructured finite element meshes

Jed Brown jedbrown at mcs.anl.gov
Fri Jun 29 04:17:13 CDT 2012


On Fri, Jun 29, 2012 at 1:10 AM, Thomas DE-SOZA <thomas.de-soza at edf.fr>wrote:

>
> 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 ?
>
> You only have to allocate the entries once, but there are entries that
> were not preallocated at all.
>
> 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.
>

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.


>
> Many thanks for your help !
>
> Thomas
>
>
>
>
>   *jedbrown at mcs.anl.gov*
> Envoyé par : petsc-users-bounces at mcs.anl.gov
>
> 28/06/2012 19:33
> Veuillez répondre à petsc-users
>
>         Pour :        petsc-users at mcs.anl.gov
>         cc :        nicolas.sellenet at edf.fr, (ccc : Thomas
> DE-SOZA/A/EDF/FR)
>         Objet :        Re: [petsc-users]        Réf. : Re: Avoiding malloc
> overhead for unstructured finite element meshes
>
>
>
> On Thu, Jun 28, 2012 at 9:29 AM, Thomas DE-SOZA <*thomas.de-soza at edf.fr*<thomas.de-soza at edf.fr>>
> wrote:
> Since 9900 coefficients were uneeded, we had first thought that enough
> room was preallocated.
> 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 ?
>
> 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.
>
>
> 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 ?
>
> You only have to allocate the entries once, but there are entries that
> were not preallocated at all.
>
>
> 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.
>
> 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.
>
> 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.
> ____________________________________________________
>
> 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.
>
> 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.
>
> E-mail communication cannot be guaranteed to be timely secure, error or
> virus-free.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20120629/8188e69a/attachment-0001.html>


More information about the petsc-users mailing list