<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">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><div>Note that here the indexing should be<br></div><div> f[ <b>j</b> ][ <b>i</b> ].omega<br></div><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><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><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><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><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><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><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 class=""><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></div><br></div></div>