<div dir="ltr">Dave --<div><br></div><div>You are right that I had a c<span style="color:rgb(0,0,0);font-size:16px">ut-paste-edit error in my VecGetArray() invocation in the email.</span>   Sorry about that.  I should of cut and pasted from my functioning, and DMDA-free, code.</div><div><br></div><div>In this context I meant</div><div><br></div><div>Vec v;</div><div>...  // create or load the Vec</div><div>Node *u;</div><div><div class="gmail_quote" style="font-size:16px"><span style="color:rgb(0,0,0)">VecGetArray(v,(PetscScalar**)&u);</span><br></div></div><div class="gmail_quote" style="font-size:16px"><br></div><div class="gmail_quote" style="font-size:16px"><span style="color:rgb(0,0,0)">This *is* correct, and it works fine in the right context, without memory leaks.  I am *not* using a DMDA in this case.  At all.</span></div><div class="gmail_quote" style="font-size:16px"><span style="color:rgb(0,0,0)"><br></span></div><div class="gmail_quote" style="font-size:16px"><div class="gmail_quote"><span style="color:rgb(0,0,0)">My original quote from the PETSc User Manual should be read *as is*, however.  It *does* refer to DMDAVecGetArray().  And you are right that *it* has an error: should be [j][i] not [i][j].  And DMDAVecGetArray() does a cast like the above, but internally.</span></div><div><span style="color:rgb(0,0,0)"><br></span></div></div><div class="gmail_quote" style="font-size:16px"><span style="color:rgb(0,0,0)">Again, my original question was about distinquishing/explaining the different types of the returned pointers from DMDAVecGetArray() and VecGetArray().</span></div><div class="gmail_quote" style="font-size:16px"><span style="color:rgb(0,0,0)"><br></span></div><div class="gmail_quote" style="font-size:16px"><span style="color:rgb(0,0,0)">Ed</span></div><div class="gmail_quote" style="font-size:16px"><span style="color:rgb(0,0,0)"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 27, 2016 at 2:47 PM, Dave May <span dir="ltr"><<a href="mailto:dave.mayhem23@gmail.com" target="_blank">dave.mayhem23@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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On 27 May 2016 at 21:24, Ed Bueler <span dir="ltr"><<a href="mailto:elbueler@alaska.edu" target="_blank">elbueler@alaska.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Dave --<br><br>Perhaps you should re-read my questions.  </div></blockquote><div><br></div></span><div>Actually - maybe we got our wires crossed from the beginning. <br>I'm going back to the original email as I missed something.<br><br></div><div><div><div><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>"""</div><div>The recommended approach for multi-component PDEs is to declare a struct representing the fields defined<div>at each node of the grid, e.g.</div><div><br></div><div>typedef struct {</div><div>PetscScalar u,v,omega,temperature;</div><div>} Node;</div><div><br></div><div>and write residual evaluation using</div><div><br></div><div>Node **f,**u;</div><div>DMDAVecGetArray(DM da,Vec local,&u);</div><div>DMDAVecGetArray(DM da,Vec global,&f);</div><div>...</div><br></div></div></blockquote></span></div></div></div></blockquote><br><br></span><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>1)  The third argument to DMDAVec{Get,Restore}Array() is of type "void *".  It makes the above convenient.  But the third argument of the unstructured version Vec{Get,Restore}Array() is of type "PetscScalar **", which means that in an unstructured case, with the same Node struct, I would write</div><div><div>"VecGetArray(DM da,Vec local,(PetscScalar **)&u);"</div></div><div>to get the same functionality.  Why is it this way?  More specifically, why not have the argument to VecGetArray() be of type "void *"?</div></div></div></blockquote><div><br></div></span></div></div></div></blockquote></span><div><br><span style="color:rgb(0,0,0)">Is the quoted text<br></span></div><span style="color:rgb(0,0,0)">  "VecGetArray(DM da,Vec local,(PetscScalar **)&u);"</span><span style="color:rgb(0,0,0)"><br>really what you meant?<br><br></span></div><div class="gmail_quote"><span style="color:rgb(0,0,0)">Sorry I didn't spot this on the first read, but probably you meant something else as VecGetArray() only takes two args (Vec,PetscScalar**).<br><br></span></div><div class="gmail_quote"><span style="color:rgb(0,0,0)">This code<br></span></div><div class="gmail_quote"><span style="color:rgb(0,0,0)"><br>  Node **u;<br></span></div><div class="gmail_quote"><span style="color:rgb(0,0,0)">  VecGetArray(Vec local,(PetscScalar**)&u);</span><br></div><div class="gmail_quote"><span style="color:rgb(0,0,0)"><br>would not be correct, neither would<br><br></span></div><div class="gmail_quote"><div class="gmail_quote"><span style="color:rgb(0,0,0)">  Node ***u;<br></span></div><div class="gmail_quote"><span style="color:rgb(0,0,0)">  VecGetArray(Vec local,(PetscScalar**)&u);<br></span></div></div><div class="gmail_quote"><span style="color:rgb(0,0,0)">if the DMDA was defined in 3d.<br></span><br><br></div><div><div class="h5"><div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div></div></span><div>I would say the reason why the last arg to VecGetArray() is not void* is because it is intended to give you direct access to the pointer associated with the entries within the vector - these are also PetscScalar's<br></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div><div>2) Given that the "recommended approach" </div></div></div></blockquote><div><br></div></span><div>I don't believe it is ever recommended anywhere to do the following:<br>  VecGetArray(DM da,Vec local,(PetscScalar**)&u)</div><div><br>Trying to trick the compile with such a cast is just begging for memory corruption to occur.<br></div><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>above works just fine, why do DMDAVec{Get,Restore}ArrayDOF() exist?  (I.e. is there something I am missing about C indexing?)</div></div></div></blockquote><div><br></div></span><div>As an additional point, DMDAVec{Get,Restore}ArrayDOF() return<br><pre>void *array</pre></div><div>so that the same API will work for 1D, 2D and 3D DMDA's which would require PetscScalar **data, PetscScalar ***data, PetscScalar ****data respectively.<br></div><div><br><br></div><div>Cheers,<br></div><div>  Dave<br></div><span><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div><div>3) There are parts of the PETSc API that refer to "dof" and parts that refer to "block size".  Is this a systematic distinction with an underlying reason?  It seems "block size" is more generic, but also it seems that it could replace "dof" everywhere.</div><div><br></div><div>Thanks for addressing silly questions.</div><span><font color="#888888"><div><br></div><div>Ed</div><div><br></div><div><br></div>-- <br><div data-smartmail="gmail_signature">Ed Bueler<br>Dept of Math and Stat and Geophysical Institute<br>University of Alaska Fairbanks<br>Fairbanks, AK 99775-6660<br>301C Chapman and 410D Elvey<br><a href="tel:907%20474-7693" value="+19074747693" target="_blank">907 474-7693</a> and <a href="tel:907%20474-7199" value="+19074747199" target="_blank">907 474-7199</a>  (fax <a href="tel:907%20474-5394" value="+19074745394" target="_blank">907 474-5394</a>)</div>
</font></span></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div data-smartmail="gmail_signature">Ed Bueler<br>Dept of Math and Stat and Geophysical Institute<br>University of Alaska Fairbanks<br>Fairbanks, AK 99775-6660<br>301C Chapman and 410D Elvey<br><a href="tel:907%20474-7693" value="+19074747693" target="_blank">907 474-7693</a> and <a href="tel:907%20474-7199" value="+19074747199" target="_blank">907 474-7199</a>  (fax <a href="tel:907%20474-5394" value="+19074745394" target="_blank">907 474-5394</a>)</div>
</div></div></div>
</div></div></div></div><br></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Ed Bueler<br>Dept of Math and Stat and Geophysical Institute<br>University of Alaska Fairbanks<br>Fairbanks, AK 99775-6660<br>301C Chapman and 410D Elvey<br>907 474-7693 and 907 474-7199  (fax 907 474-5394)</div>
</div>