<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 15, 2015 at 11:15 AM, K. N. Ramachandran <span dir="ltr"><<a href="mailto:knram06@gmail.com" target="_blank">knram06@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello Matt,<br><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 15, 2015 at 11:46 AM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span></span><span><div><br></div></span><div>This seems like the hardest way to do this. We have running examples, that scale well, and produce exactly the matrix</div><div>you are using. In addition, they create the matrix in parallel, so the whole thing is scalable.</div><div><br></div><div>In order to do it the way you want, you would need to match the partitioning, which is hard.</div></div></div></div></blockquote><div><br></div><div>Yes, I understand. I am trying to keep the solver module separate from the problem physics (like boundary conditions), i.e. my code has knowledge of the physics and I generate the matrix in sparse format. I then hand it over to some Solver module (say, PETSc) which can efficiently solve this.<br><br></div><div>Examples like snes/ex5.c, ksp/ex45.c, etc. use knowledge of the boundary conditions to fill up the matrix and the RHS and this makes sense, if the entire code is written using PETSc's native data structures. But from a modularity point of view, if my problem needs a different partitioning based on the physics, I feel like my code should generate the relevant matrices on each rank and send it to PETSc.<br><br></div><div>I am trying to simulate the movement of charged particles in a domain, and these particles become collimated along a particular direction. So one way to partition might be 1D slabs perpendicular to the collimated direction, so each rank can calculate the field and move the particles on each timestep. Of course communication across the slabs would be inevitable. But this way, the partitioning is based on the physics of the problem and the solver module just efficiently solves the system without having to know the boundary conditions, which makes sense to me overall.<br><br></div><div>Hope this description helps.</div></div></div></div></blockquote><div><br></div><div>The bad design decision is using a storage format designed for high speed MatMult() to use for data interchange. You should be</div><div>using the API for value insertion rather than some storage format.</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 dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">Thanking You,<br></div><div class="gmail_extra"><div><div dir="ltr">K.N.Ramachandran<br><div>Ph: <a href="tel:814-441-4279" value="+18144414279" target="_blank">814-441-4279</a></div></div></div>
</div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="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>