<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 2, 2019 at 2:08 PM Jed Brown via petsc-dev <<a href="mailto:petsc-dev@mcs.anl.gov">petsc-dev@mcs.anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">John Peterson <<a href="mailto:jwpeterson@gmail.com" target="_blank">jwpeterson@gmail.com</a>> writes:<br>
<br>
>> Do you add values many times into the same location?  The array length<br>
>> will be the number of misses to the local part of the matrix.  We could<br>
>> (and maybe should) make the stash use a hash instead of building the<br>
>> array with multiplicity and combining duplicates later.<br>
>><br>
><br>
>  This is a 3D model with a so-called "spider" node that is connected to<br>
> (and constrained in terms of) many other nodes by 1D "beam" elements. So,<br>
> yes, I would imagine the dofs of the spider node would be assembled into<br>
> from many (possibly off-processor) elements.<br>
<br>
Makes sense.<br>
<br>
> The "legacy" variant sends all that redundant data and inserts one at a<br>
>> time into the local data structures.<br>
>><br>
><br>
> OK, I guess in this case the problem is so small that we don't even notice<br>
> the communication time, even for the legacy algorithm.<br>
<br>
Fande said it took a second, which sounds like a long time to me -- it's<br>
enough time to move many GB in memory.<br></blockquote><div><br></div><div>Just to be clear, I did not put a timer on. I hit the button, and then code was done. I thought that were about one second.</div><div>"One second" thing was not the point at the first place, and I was emphasizing  that BTS was way slower than the legacy for that particular run.</div><div><br></div><div><br></div><div>Thanks,</div><div><br></div><div>Fande,</div><div><br></div><div><br></div><div> </div></div></div>