<div dir="ltr">Dave --<br><br>Perhaps you should re-read my questions. My points were missed. But you motivated me to look slightly deeper; see below.<br><br>> I would say the reason why the last arg to VecGetArray() is not void* is because<br>> it is intended to give you direct access to the pointer associated with the entries<br>> within the vector - these are also PetscScalar's<br><br>Yes, that is fine. But DMDAVecGetArray() does it the other way, using "void *" instead. The question was, why does the PETSc API have two different approaches.<div><br></div><div>Jed's "more information" answer about unstructured grids is a bit vague, but it must be the one that motivates the difference.<br><br>> I don't believe it is ever recommended anywhere to do the following:<br>> VecGetArray(DM da,Vec local,(PetscScalar**)&u)<br><br>I do not recommend it; I am annoyed that I need it!<div><br></div><div>My point was that this awkward construct allowed the "recommended approach"---which is a quote from the PETSc manual and not my own recommendation---to proceed with VecGetArray(). Whereas this awkward construct is not needed in user code which uses DMDAVecGetArray().<br><br>> Trying to trick the compile with such a cast is just begging for memory</div><div>> corruption to occur.<br><br>Maybe so, but you do it all the time with PETSc structured grids. In fact, the third line of the implementation of DMDAVecGetArray() is<br><br>" VecGetArray(vec,(PetscScalar**)array); "<br><br>That is, in the "recommended approach", the cast occurs inside DMDAVecGetArray(). The same cast is simply exposed to the user if they want to get a struct-valued pointer from VecGetArray().<br><br>Ed<br><div><div><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 27, 2016 at 12:06 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 20:34, 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">Dear PETSc --<div><br></div><div>This is an "am I using it correctly" question. Probably the API has the current design because of something I am missing.</div><div><br></div><div>First, a quote from the PETSc manual which I fully understand; it works great and gives literate code (to the extent possible...):</div><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><div>f[i][j].omega = ...</div></div></div></blockquote><div><br></div></span><div>Note that here the indexing should be<br></div><div> f[ <b>j</b> ][ <b>i</b> ].omega<br></div><span class=""><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>...</div><div>DMDAVecRestoreArray(DM da,Vec local,&u);</div><div>DMDAVecRestoreArray(DM da,Vec global,&f);</div><div>"""</div><div><br></div><div>Now the three questions:</div><div><br></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>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 class=""><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 class=""><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 class=""><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 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>