Jed, so to use VecGetSubVector() with a regular Vec; it would need to set Vec->map->bs = no_of_components<div>that I want to solve for? I understand that a wrapper code needs to be written for gelling SAMRAI data field and PETSc Vec; I am referring to such vector wrapper here. <br>

<br><div class="gmail_quote">On Thu, Feb 21, 2013 at 5:33 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</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"><br><div class="gmail_quote"><div class="im">On Thu, Feb 21, 2013 at 5:12 PM, Boyce Griffith <span dir="ltr"><<a href="mailto:griffith@cims.nyu.edu" target="_blank">griffith@cims.nyu.edu</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Sorry I couldn't jump in earlier --- I had a proposal going out today and am just now catching up on other email.<br>



<br>
Amneet is trying to solve a system the couples together some field data that is described using SAMRAI data structures along with particles that are stored in a standard PETSc Vec.  The hook between the SAMRAI data and PETSc is via a version of Bobby Philip's SAMRAI-to-PETSc interface that I've bastardized for my own purposes.  There is no support for {Mat,Vec}SetValues here --- the wrapper just provides standard vector space operations required by Krylov and Newton-Krylov solvers.<br>


</div></blockquote><div><br></div></div><div>Boyce, thanks for explaining. We *always* need to know this sort of background in order to make useful suggestions.<br></div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>
<br>
I used to have some code to make collections of Mat's and Vec's to make it feasible to solve systems involving both native and non-native PETSc data structures.  (It was similar to some code for making Vec's of Vec's that someone --- Dave May? --- used to maintain.)  I ripped this stuff out of my code a while ago, and I suggested that Amneet investigate {Vec,Mat}Nest before we tried to resurrect that old code.</div>


</blockquote></div></div><br></div><div class="gmail_extra">That was called PetscExt. Dave and I wrote MatNest out of desire to do the sort of things that PetscExt did in a way that was more flexible and would interoperate better with the rest of PETSc. It, and PCFieldSplit should be a complete replacement for anything you might have used PetscExt for in the past.<br>


<br></div><div class="gmail_extra">If you already have MatShells around for all the blocks, you can easily wire them together with MatNest.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Note that MatNest does *not* depend on VecNest, and in general, I recommend not using VecNest. If you call VecGetSubVector() with a contiguous index set, you'll get a subvec back without a copy. This means that your residual evaluation only needs to provide a map from your non-contiguous local representation to a contiguous global representation. This should be no overhead and will interoperate better.<br>


<br>But if you really want to use those other vector space wrappers, you can use VecNest.<br></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Amneet <br><br></div><div><br></div><div><br></div>
</div>