<div dir="ltr">This might be more basic than what you're trying to find out, but the reason that "assembly" is required in the first place (even for serial code) is that that during the process of defining the matrix, it's useful to be able to insert values anywhere in the matrix. I'm not sure what PETSc does precisely with digging into the source, but a common way to approach things is to maintain a data structure which looks like a C array of (row,col,val) entries (if you have ever used the Eigen library, they call these "Triples" and you can work with C++ STL vector of them). This is the COO ("COOrdinate list") format for storing a sparse matrix. Typically one uses a more highly-compressed format, like CSR ("Compressed Row Storage") , which does not allow of efficient insertion and deletion of entries. This tension motivates requiring the user to explicitly assemble the matrix. </div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 26, 2015 at 7:13 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Justin Chang <<a href="mailto:jychang48@gmail.com">jychang48@gmail.com</a>> writes:<br>
<br>
> Jed,<br>
><br>
> Thank you for the response. But where exactly are the values from<br>
> MatSetValues() stored or located? That is, are they in main memory, or are<br>
> they occupying space in the L1/L2/L3 cache?<br>
<br>
</span>Caches are not programmable in that way.  PETSc incrementally allocates<br>
a data structure that holds the "stashed" values.  It depends on the<br>
details of your application and the hardware cache semantics whether a<br>
particular access will trigger a cache miss or not.  You can find out<br>
using hardware performance counters, but it's not likely to be worth<br>
your time unless you just want to learn those tools.<br>
</blockquote></div><br></div>