<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 9, 2017 at 11:04 AM, "Leidy Catherine Ramirez Villalba" <span dir="ltr"><<a href="mailto:leidy-catherine.ramirez-villalba@ec-nantes.fr" target="_blank">leidy-catherine.ramirez-villalba@ec-nantes.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:#000000"><div>Dear <span id="m_4419724633398146223DWT146" class="m_4419724633398146223ZmSearchResult"><span id="m_4419724633398146223DWT154" class="m_4419724633398146223ZmSearchResult">PETSc</span></span> team,<br><div><br></div><div><div>I'm currently working on the parallelization of the assembling of a system, previously assembled in a serial way (manual), but  solved using <span id="m_4419724633398146223DWT148" class="m_4419724633398146223ZmSearchResult"><span id="m_4419724633398146223DWT156" class="m_4419724633398146223ZmSearchResult">PETSc</span></span> in parallel.<br></div><div>The problem I have is that when comparing computational time with the previous implementation, it seem that the parallel version is slower than the serial one.<br></div><div><br></div><div>The type of matrices we deal with are sparse and might change their size in a significant order (kind of contact problems, where relations between elements change).<br></div></div></div><div><div>For the example I'm using, for giving an example, the initial size of the matrix is : 139905, after several iteratinos it changes to: 141501 and finally to: 254172.</div><div><br></div></div><div>The system is assembled and solved at each iteration and the matrix can not be re-used, therefore for each new iteration the matrix is set to zero keeping the previous non-zero pattern, and the option 'MAT_NEW_NONZERO_LOCATIONS' is set to 'TRUE'.<br></div><div>In order to do the assembling I use the function 'MatSetValues' , inserting 3 lines and 3 rows, which might not be next to each other, and thus might no constitute a block. </div><div><br></div><div>I believe that, what makes an important difference in time is the fact of adding almost the double of elements (from 139905 to  254172), but i don't know how what could I implement to retain a larger preallocation or to solve in any other way.<br></div><div>I don't know, neither, in advance the position of new elements so that I can think in placing zeros to, maybe, generate a pre-pattern.</div></div></div></blockquote><div><br></div><div>1) Conceivably, the difference in parallel might be that you are setting elements owned by other processes. However for all performance questions, we need to</div><div>    see the output of -log_view</div><div><br></div><div>2) Certainly inserting new elements is slow because reallocating the matrix is slow. It would be faster to</div><div><br></div><div>  a) Throw away the first matrix</div><div>  b) Count all nonzeros in the second matrix</div><div>  c) Set preallocation for the second matrix</div><div>  d) Fill in the second matrix</div><div><br></div><div>  Thanks,</div><div><br></div><div>     Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:#000000"><div>Do you have any idea of how could I improve the time of the parallel version?<br></div><div><br></div><div>Thanks in advance!<br></div><div><br></div><div>Regards, <br></div><div>Catherine<br></div><div><br></div><div><br></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">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></div>