<div class="gmail_quote">On Sat, May 7, 2011 at 17:46, Milan Mitrovic <span dir="ltr"><<a href="mailto:milanm@student.ethz.ch">milanm@student.ethz.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":4vw">As far as I've seen the solvers were made to work with the petsc<br>
vector data type, but I need to use it with a different data structure<br>
that is already scattered onto different processors. Is there a way to<br>
create a custom version of petsc vector that would just wrap around<br>
the existing data? Something similar to how sundials provides a way to<br>
wrap custom data types.<br>
<br>
If there is a way to do this cleanly the wrappers could get included<br>
into ppm, so I thought that I should ask what the best way of doing<br>
this would be.</div></blockquote></div><div><br></div><div>You absolutely can, wrap your existing data, but let's discuss your needs first.</div><br><div>How is the existing data stored? If it is in a contiguous array, then you can use VecCreateMPIWithArray or VecCreateGhostWithArray or VecPlaceArray as appropriate to have PETSc use your data structures without a copy.</div>
<div><br></div><div>If it is not in a contiguous array, then you can essentially write your own (partial) Vec implementation and PETSc will use that. However, PETSc matrices (Mat) will not magically work with your new Vec implementation unless you provide access to the values as a contiguous array. This will force you to manage your own matrices and will significantly limit the number of preconditioners you have available. Also, many Vec operations will be much faster if you just make a copy so that they can all use a contiguous array.</div>
<div><br></div><div>The bottom line is that if your storage format is not contiguous, then it is very likely that end-to-end performance will be better if you make a copy, and it will give you access to many more solver combinations.</div>