<div><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Sat, Aug 11, 2018 at 6:58 AM Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> writes:<br>
<br>
> On Sat, Aug 11, 2018 at 12:02 AM Junchao Zhang <<a href="mailto:jczhang@mcs.anl.gov" target="_blank">jczhang@mcs.anl.gov</a>> wrote:<br>
><br>
>> See this example, after multiple casts, the code directly accesses<br>
>> VecScatter_MPI_General's members, with an assumption that from->n is the<br>
>> total number of receive processors. When I separate intranode / internode<br>
>> communications, I have to maintain this assumption.<br>
>><br>
>> This is a good example. VecScatter is a flagrant rule violator. It should<br>
> be rewritten with a proper API<br>
> to obtain this data.<br>
<br>
Also note that this code (which is in Mat) needs to<br>
<br>
#include <petsc/private/vecimpl.h><br>
<br>
which should ideally never happen. That rule has been broken sometimes<br>
and it hasn't been a priority to create internal interfaces to fix these<br>
historical code smells (most VecScatter code dates from the mid-1990s),<br>
but we do try to avoid it in new code and refactor when making<br>
significant changes to old code.<br>
<br>
Note that in C++, you could<br>
<br>
#define private public<br>
#define protected public<br>
<br>
before including a header, and then could access any member.<br>
</blockquote><div dir="auto"><br></div><div dir="auto"><div><a href="https://stackoverflow.com/questions/27778908/define-private-to-public-in-c/27779038#27779038">https://stackoverflow.com/questions/27778908/define-private-to-public-in-c/27779038#27779038</a></div><div dir="auto"><br></div><div dir="auto">You could also #define main to include an invocation of system() that would erase your file system.</div><div dir="auto"><br></div><div dir="auto">Jeff</div></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
><br>
> And if one was going to rewrite it, my personal prejudice would be to try<br>
> and replace the communication<br>
> part with implementations of PetscSF. Right now SF can handle different<br>
> data types (Scatter cannot), but<br>
> Scatter has many more modes of communication, such as Alltoall, whereas SF<br>
> only has p2p and window.<br>
><br>
> Matt<br>
><br>
>> 385: *PetscErrorCode <<a href="http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Sys/PetscErrorCode.html#PetscErrorCode" rel="noreferrer" target="_blank">http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Sys/PetscErrorCode.html#PetscErrorCode</a>> MatMatMultNumeric_MPIDense(Mat <<a href="http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/Mat.html#Mat" rel="noreferrer" target="_blank">http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/Mat.html#Mat</a>> A,Mat <<a href="http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/Mat.html#Mat" rel="noreferrer" target="_blank">http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/Mat.html#Mat</a>> B,Mat <<a href="http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/Mat.html#Mat" rel="noreferrer" target="_blank">http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Mat/Mat.html#Mat</a>> C)*386: {<br>
>><br>
>> 389: Mat_MPIAIJ *aij = (Mat_MPIAIJ*) A->data;<br>
>> 393: VecScatter <<a href="http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Vec/VecScatter.html#VecScatter" rel="noreferrer" target="_blank">http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Vec/VecScatter.html#VecScatter</a>> ctx = aij->Mvctx;394: VecScatter_MPI_General *from = (VecScatter_MPI_General*) ctx->fromdata;395: VecScatter_MPI_General *to = (VecScatter_MPI_General*) ctx->todata;<br>
>> 411: PetscMalloc4 <<a href="http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Sys/PetscMalloc4.html#PetscMalloc4" rel="noreferrer" target="_blank">http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Sys/PetscMalloc4.html#PetscMalloc4</a>>(B->cmap->N*from->starts[from->n],&contents->rvalues,412: B->cmap->N*to->starts[to->n],&contents->svalues,413: from->n,&contents->rwaits,414: to->n,&contents->swaits);<br>
>><br>
>><br>
>> --Junchao Zhang<br>
>><br>
>><br>
>> On Fri, Aug 10, 2018 at 10:33 PM Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>><br>
>> wrote:<br>
>><br>
>>> On Fri, Aug 10, 2018 at 11:29 PM Junchao Zhang <<a href="mailto:jczhang@mcs.anl.gov" target="_blank">jczhang@mcs.anl.gov</a>><br>
>>> wrote:<br>
>>><br>
>>>> It seems we do not have naming conventions for private members.<br>
>>>><br>
>>><br>
>>> I am not sure I understand. There are no public members. For private<br>
>>> functions, we do have<br>
>>> a naming convention, but it is newly created, so many of the existing<br>
>>> functions break the rules.<br>
>>><br>
>>> Matt<br>
>>><br>
>>><br>
>>>> --Junchao Zhang<br>
>>>><br>
>>>><br>
>>>> On Fri, Aug 10, 2018 at 9:43 PM Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>><br>
>>>> wrote:<br>
>>>><br>
>>>>> On Fri, Aug 10, 2018 at 5:43 PM Junchao Zhang <<a href="mailto:jczhang@mcs.anl.gov" target="_blank">jczhang@mcs.anl.gov</a>><br>
>>>>> wrote:<br>
>>>>><br>
>>>>>> I met several bugs that remind me to raise this question. In PETSc,<br>
>>>>>> object of type A can arbitrarily access object of type B's data. But<br>
>>>>>> designer of B may later change the meaning of its data (and of course,<br>
>>>>>> update B's interfaces, which are usually local to few files). The designer<br>
>>>>>> may think the job is done, but actually it is not. He/she has to grep the<br>
>>>>>> code to know where its data members are accessed (that is relatively easy<br>
>>>>>> to get) and what is the contract, for example, is an array assumed to be<br>
>>>>>> sorted (that is hard to know). With C++, one can use private to minimize<br>
>>>>>> data exposure.<br>
>>>>>><br>
>>>>><br>
>>>>> This just has to be coding discipline. People should not be accessing<br>
>>>>> private members.<br>
>>>>><br>
>>>>> Matt<br>
>>>>><br>
>>>>><br>
>>>>>> --Junchao Zhang<br>
>>>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> What most experimenters take for granted before they begin their<br>
>>>>> experiments is infinitely more interesting than any results to which their<br>
>>>>> experiments lead.<br>
>>>>> -- Norbert Wiener<br>
>>>>><br>
>>>>> <a href="https://www.cse.buffalo.edu/~knepley/" rel="noreferrer" target="_blank">https://www.cse.buffalo.edu/~knepley/</a> <<a href="http://www.caam.rice.edu/~mk51/" rel="noreferrer" target="_blank">http://www.caam.rice.edu/~mk51/</a>><br>
>>>>><br>
>>>><br>
>>><br>
>>> --<br>
>>> What most experimenters take for granted before they begin their<br>
>>> experiments is infinitely more interesting than any results to which their<br>
>>> experiments lead.<br>
>>> -- Norbert Wiener<br>
>>><br>
>>> <a href="https://www.cse.buffalo.edu/~knepley/" rel="noreferrer" target="_blank">https://www.cse.buffalo.edu/~knepley/</a> <<a href="http://www.caam.rice.edu/~mk51/" rel="noreferrer" target="_blank">http://www.caam.rice.edu/~mk51/</a>><br>
>>><br>
>><br>
><br>
> -- <br>
> What most experimenters take for granted before they begin their<br>
> experiments is infinitely more interesting than any results to which their<br>
> experiments lead.<br>
> -- Norbert Wiener<br>
><br>
> <a href="https://www.cse.buffalo.edu/~knepley/" rel="noreferrer" target="_blank">https://www.cse.buffalo.edu/~knepley/</a> <<a href="http://www.caam.rice.edu/~mk51/" rel="noreferrer" target="_blank">http://www.caam.rice.edu/~mk51/</a>><br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Jeff Hammond<br><a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br><a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a></div>