<div dir="ltr">Hi Ed,<br><br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On 28 May 2016 at 00:18, 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 --<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></blockquote><div><br></div><div>Ah okay.<br></div><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 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]. </span></div></div></div></blockquote><div><br></div><div>Oh crap, that indexing error is in the manual (multiple times)! <br>Yikes.<br></div><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 class="gmail_quote" style="font-size:16px"><div class="gmail_quote"><span style="color:rgb(0,0,0)">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></blockquote><div><br></div><div>Okay.<br><br></div>VecGetArray() knows nothing about any DM. It only provides access
to the underlying entries in the vector which are PetscScalar's. So the last arg is naturally PetscScalar**.<div><br></div><div><div>DMDAVecGet{Array,ArrayDOF}() exploits the DMDA ijk structure.<br></div>DMDAVecGet{Array,ArrayDOF}() exist solely for the convenience of the user who wants to write an FD code, and wishes to express the discrete operators with multi-dimensional arrays, e.g. which can be indexed like x[j+1][i-1].<br><br></div><div><div>DMDAVecGetArray()
maps entries from a Vec to a users data type, which can be indexed with
the dimension of the DMDA (ijk). Since the dimension of the DMDA can be 1,2,3
and the blocksize (e.g. number of members in your user struct) is defined by the user - the last arg must be void*.<br><br></div><div>DMDAVecGetArrayDOF()
maps entries from a Vec to multi-dimensional array indexed by the
dimension of the DMDA AND the number of fields (defined via
the block size). Since the dimension of the DMDA can be 1,2 or 3, again,
the last arg must be void* unless a separate API is introduced for 1D, 2D and 3D.<br><br></div><div>Why do both exist? Well,
Jed provided one reasons - the block size may be a runtime choice and
thus the definition of the struct cannot be changed at runtime. Another
reason could be the user just doesn't think it is useful to attach names
(i.e. though members in a struct) to their DOFs - hence they want DMDAVecGetArrayDOF(). This could arise if
you used the DMDA to describe a DG discretization. The DOFs would then
just represent coefficients associated with your basis function. Maybe the user just prefers to write out loops.<br></div><div><br></div><div>I see DMDAVec{Get,Restore}XXX as tools to help the user. <br>The user can pick the API they prefer. <br></div><div><br></div><div>I
use the DMDA, but I always use plain old VecGetArray() and obtain the
result in a variable declared as PetscScalar*. I don't bother with
mapping the entries into a struct. I see no advantage to this in terms of code clarity. I prefer not to use
DMDAVecGetArray() and DMDAVecGetArrayDOF() as these methods allocate
additional memory.<br></div><div><br></div>In my opinion, the line you refer to from the manual regarding multi-component PDEs should only applied in the context of usage with the DMDA. Others may disagree.<br><br></div><div>I hope I finally helped answered your question. <br></div><div><br><br></div><div>Cheers,<br></div><div> Dave<br></div><div><br><br></div><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"><span><font color="#888888"><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></font></span></div><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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>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><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><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><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 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></blockquote></div><br></div></div></div></div>